emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GTK file selector


From: Aidan Kehoe
Subject: Re: GTK file selector
Date: Sat, 17 Dec 2005 23:21:27 +0100

My perception is that XEmacs’ main problems are manpower and GNU
compatibility, GNU Emacs’ main problem is management. GNU Emacs doesn’t lack
manpower or mailing list activity compared to say, Perl or GCC. That said --

 Ar an seachtú lá déag de mí na Nollaig, scríobh David Kastrup: 

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

Your falling out out was an artifact of the details of our package system,
not of having a package system in itself. Our package system is too
centralised, and oriented towards XEmacs committers to easily accommodate
what you wanted to do. The package system does work better than the
monolithic alternative, users do see finished code quicker. 

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

Yup. We lack manpower. I should be writing code and documentation now, not
this mail. But I’m not making a living from XEmacs, I’m doing what I do in
my spare time, so a certain amount of indulging whims is reasonable.

 > 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 maybe because anything implemented using the XEmacs-specific APIs will
never run on GNU Emacs, so coders tend to put off writing code to use a
feature until that feature makes it into GNU Emacs, at which point XEmacs
provides a compatibility API--the reverse is never true. Eminently rational
behaviour.

[...]

-- 
I AM IN JAIL AND ALLOWED SEND ONLY ONE CABLE SINCE WAS ARRESTED WHILE
MEASURING FIFTEEN FOOT WALL OUTSIDE PALACE AND HAVE JUST FINISHED COUNTING
THIRTY EIGHT THOUSAND FIVE HUNDERED TWENTY TWO NAMES WHOS WHO IN MIDEAST.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]