Re: GTK file selector

[Jérôme Marant]

David Kastrup <address@hidden> writes:

>> I'm not promoting anything but IMHO XEmacs did it right from the
>> very beginning by focusing on what users expect the most from, that
>> is user interface:
>
> 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.

>> 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,
so updated package would be painless for developers and users would
get bugfixes more quickly.
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.

> actually had quite a bit of fallout with the XEmacs developers over
> integrating AUCTeX as a package into XEmacs.

Quite loudly ;-)

[...]

>> The only necessary improvement I can see is related to Unicode
>> support (which Emacs is doing quite right).
>
> Which is partly because people involved with it are actively using it.
> With XEmacs, there is currently Ben Wing working in the background on
> stuff that will at one time emerge while everybody is waiting with
> bated breath, and it will not magically solve all problems.
>
> The link between engineering and actual use in the real world is in my
> opinion what is the strongest ailment of XEmacs.  And I don't think
> the package system is much of a help there.  And getting more frequent
> releases which still don't work well does not cut it, either.

I think the unicode support is out of the scope of the package system.
It is a core feature which requires a major release update.

>> Catching-up with Emacs is only necessary because Emacs APIs do
>> change, are enriched, and mode authors who mostly use Emacs update
>> their software accordly.
>
> 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.  I used to fire it up many times
while working on emacs-snapshot, and did my usual work (coding in C,
Perl, Python, Make, Shell and so on) and I did not feel it was
different from Emacs 21.3, which provides just fine all what I need
these days.  Of course, there is the GTK interface for the eye-candy
(to the detriment of performance) and better unicode support for
non-European countries.  But for the average end users, I can say
there is not anything worth waiting 4+ years.

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_.
The package system could be just fine _iff_ packaged modes did not
come from the Emacs land.

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).

And let's be honest, Emacs is not going to provide any of the nice
features that Eclipse provides these days.  And Eclipse is free, runs
with a free Java Platform, is extensible, and so on.  Furthermore,
there is no more performance argument against Java since Eclipse
compiled with GCJ is pretty fast (congratulations to CGJ and GNU
Classpath people!).

-- 
Jérôme Marant