Re: GTK file selector

[David Kastrup <dak@gnu.org>]

Jérôme Marant <jmarant@free.fr> writes:

> David Kastrup <dak@gnu.org> writes:
>
>>> I think it could be fixed by making bugfix releases as I already
>>> proposed many times (I also proposed to add myself as manpower for
>>> such a purpose).  So far, supporting the current released version
>>> is not wanted, as far as I understood.
>>
>> We have already too little manpower to support the coming release.
>
> Really? There are more than one hundred committers, according to the
> Emacs page at Savannah.

Most of the work is done by very few people.  Committers are basically
just people comfortable with CVS, who have signed the necessary
assignments and are expected not to do anything really bad too often.
However, that does not mean that you can rely on them doing useful
stuff all too frequently.

>>> Also, I wonder if the modular design -- separating core and
>>> modules -- makes it easier to release often.
>>
>> One has to be aware that in the case of XEmacs, this is snake oil.
>> XEmacs' code base, while frequently released, has not yet even
>> caught up to Emacs-21.0 in core areas.  The packages, while
>> frequently released, are often in a state of disarray and various
>> levels of outdatedness.  XEmacs-21.5 is quite unstable.  And so on.
>> There is the occasional package that is kept more up to date in
>> that manner, but the overall effect is not consistently convincing
>> to me.
>
> 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:

> 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
actually had quite a bit of fallout with the XEmacs developers over
integrating AUCTeX as a package into XEmacs.

> I'd even say that there are enough features for most end users.

But we are not talking about "features", but usability, both for users
and programmers.  Whenever I have had contact with XEmacs, lot of the
stuff was unusable to me.  Documentation and stuff of the features
tends to be so bad that it is hard to programmatically interface to
it.  Those features just don't get used.

As an example: when working with preview-latex, it was found that
images displayed from a binary file format were garbled when dired was
loaded.  This was analyzed and reported by a programmer in our project
who subsequently went silent.  Several years later, nobody had
bothered fixing the stuff.  I don't think it is fixed even now.

Now I think you will agree that displaying images are sort of a
feature for which XEmacs was renowned (this does not concern the
normal icons and toolbars who are read from a non-binary image
format), and dired is pretty basic.

And yet, nobody apparently used this functionality for years and
years.  A lot of the stuff in XEmacs is like that: implemented, and
left unused because it has, maybe because of the roughness of APIs and
documentation, not been tied into any application in frequent use.

And the package system partly is a way not to feel bad about material
in various states of disarray.  How many people actually use the
package system?  It actually is likely to interfere with the package
systems of operating system distributions if you actually use it.

XEmacs has always had a much larger overlap between developers and
users.  In contrast, Emacs has for a long time had a pretty closed
inner circle.  As a result, Emacs development and maintainance has
turned out to care a lot more for users who neither are nor want to be
developers.

Of course, not releasing any of the work for such a long time is not a
good thing for the end user.  But it does not look to me like a
package system would lead to a better situation.

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

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

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum