Re: GTK file selector

[David Kastrup]

Jérôme Marant <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> But we are not talking about the user interface here.  We are talking
>> about the release process.  All that is relevant in that regard is:
>
> I'll explain later why I think it is indirectly relevant.

Where?

>>> a package system.
>>
>> And as I said, the overall effect does not seem too convincing to me.
>> Many packages have not even caught up to the state of Emacs-21.  I
>
> I've already been publicly accused of trying to undermine the Emacs
> project when dealing this subject.
> The situtation with Emacs would be different since it is the
> mainline,

And that's the whole point.  There is no automatic "mainline" after a
fork with regard to developer involvement.  And yet Emacs has regained
the "mainline" moniker in the eyes of some.

> so updated package would be painless for developers and users would
> get bugfixes more quickly.

You are presumably talking about a package system like XEmacs' in the
use of Emacs.  It is wishful thinking to assume that its effects on
Emacs would be magically different than on XEmacs.  A package system's
intent is to decrease the number of collisions between an abundance of
workers by organizing them into more independent departments with
separate release policies and timelines.

We don't have an abundance of workers.  Neither does XEmacs.  The
XEmacs package system is, in its current state, just overengineering.
Almost nobody uses anything except the Sumo collections, and it will
likely cause interference with operating system package systems if you
attempt actually using the XEmacs package system.

> I think the problem with XEmacs is mostly due to the fact that
> adapting modes that are written for Emacs is more and more difficult
> as mode writers tend to use newer Emacs features.

But why is XEmacs dependent on adapting modes that are written for
Emacs?  Because people choose Emacs as their first platform.

>> Sure, and your point was?  We don't change Emacs just for fun, but
>> to improve it, for users as well as developers.  And catching-up
>> means passing on those improvements.
>
> OK, I'm going to explain my point.  No offence meant.
>
> For end users -- that is, people who use the text editor as a text
> editor and are not spending time customizing the editor nor editing
> the editor -- (and being myself an end user) there is not anything
> really new to expect from Emacs 22.

Except for better syntax highlighting (enabled by default), better
filling, strikingly better handling of images, better scrolling,
working Unicode support including cut&paste between applications,
basic drag&drop support, automatical support of mouse wheels, working
image support on platforms beyond X11, mouse-induceable temporary
transient-mark-mode (this is a _very_ important improvement for the
average user), CUA-mode, tramp, Leim, a large number of included
documents like the Elisp programming manual and tutorial, a much
improved Gnus, a spreadsheet, a symbolic calculator and so forth and
so on.

Just type C-h C-n.

> But for the average end users, I can say there is not anything worth
> waiting 4+ years.

Beg to differ.

> What I was saying with XEmacs is that they decided at the very
> beginning to prodive UI features that users wants these days, such
> as buffer tabs, rich menu entry avoiding the use of the ugly
> "customize" as much as possible, a gutter, and so on, which is
> just enough for the average end user these days.  So, except from
> the lack of unicode support, there is not much in the land of
> improvement but bugfixes, for a _text editor_.

But there has been room for lots of improvement within Emacs.  The
reason we are getting tense here about the release of Emacs-22 is not
because Emacs-22 would be just the same as Emacs-21.  Maybe you
consider it similar in the core feature set, but core features alone
don't cut it.  You don't get anywhere just by implementing some fancy
feature and then letting it rot away.  It has to get tied into the
average person's work flow.

> The package system could be just fine _iff_ packaged modes did not
> come from the Emacs land.

So why do they come from the Emacs land?  And if the package system is
just something important for dealing with packages coming "from Emacs
land", why would Emacs need one?

> Emacs still does not have the necessary features for competing with
> bare text editors (I'm not talking about displaying images, reading
> mail or chating with irc).

Well, it fares pretty well considering that it is not able to
compete.

> And let's be honest, Emacs is not going to provide any of the nice
> features that Eclipse provides these days.

Well, that certainly would seem to work in both ways.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum