outdated url-library: is XEmacs still the next generation of Emacs?

[Stephen J. Turnbull]

Thomas Alexander Gerds writes:

 > a) is xemacs still the next generation of emacs?

No.  It never was, except as an advertising slogan; "emacs" means
RMS's emacs, XEmacs was always intended to become part of the next
generation of emacs, not to replace it, but RMS doesn't want XEmacs's
improvements unless we pay for them twice.

SXEmacs (http://www.sxemacs.org/) might still have ambitions in that
direction.

 > b) is anyone working on a new version of url.el for xemacs?

Not that I know of.  I have a half-baked workspace with a native
implementation of curl bindings, and there is another half-baked
workspace with a foreign function interface (FFI) that comes with a
curl binding.  One or both could be part of an XEmacs 21.5 beta
release by mid-summer, I guess.

It probably wouldn't be that hard to port GNU's version of url.el, if
somebody wants to volunteer time or funding.

 > c) why not migrate to emacs?

Why not, indeed!  Many people have (although Jamie Zawinski still
keeps the faith ;-).  To be honest, Emacs v23 on modern hardware is as
good or better than XEmacs pretty much everywhere it shows.  Most
features we have that they don't are rather specialized (bignums,
Japanese input methods) or are not really exploited (dynamically
loading binary libraries).

XEmacs still has a number of useful features that GNU doesn't.  XEmacs
specifiers offer much finer control of display properties for hacking
faces than GNU does.  Although Customize is of nearly equivalent
power, use of Customize is clumsy, and apparently GNU's frame-local
variables don't work as smoothly as XEmacs's frame locale in
specifiers (IIUC Stefan wants to get rid of frame-locals).  XEmacs has
a slightly better implementation of active regions (zmacs-regions),
some accessibility features (eg, sticky modifier keys), and implements
shifted-motion-extends-region smoothly.  XEmacs has its package
system, which means that if somebody did update url.el, you would have
a prebuilt pre-release available within days, often within hours, and
an official release (usually of the same code, sometimes with
bugfixes) within a couple of months.  XEmacs has native widgets,
specifically the buffer tabs are quite useful.  SXEmacs has even more
such features, including the original of the generic foreign function
interface based on libffi mentioned above and even more number types
(quaternions and octonions, anyone? :-)

On the programming side, we have recently got much improved support
for Common Lisp, including true multiple values (kudos to Aidan Kehoe
who has done almost all of that work).

Some of the features that they have added in imitation are not as well
done yet (eg, images are relatively inefficient, apparently, and I've
mentioned that Stefan wants to get rid of frame-local variables).
XEmacs's event loop apparently still works better on Windows (don't
take that too seriously yet, it's just some scuttlebutt on
emacs-devel; it surprised me to hear it).

My own reason is mostly politics.  I can't bear the idea of working on
(or with) a product whose eminance gris shows such willingness to
impose pain on his users (eg, no DLLs, a policy that is now changing,
I think, but won't be implemented until v24 at the earliest) and
developers (eg, Bazaar DVCS).  Not to mention the gratuitous
proliferation of copyleft licenses, which IMO hurts everybody except
maybe Microsoft.

I also prefer the XEmacs implementations of almost everything.  Easier
to understand (don't listen to David Kastrup who will undoubtedly
claim that no sane person can understand specifiers, or RMS who claims
that the stack of extents gives him a migraine :-), often more robust,
and invariably faster where functionality is comparable.  Even today.

In general, XEmacs still has cleaner design, and in this kind of race
the advantage is normally to number two (they can copy, and they don't
have to do market research to find out what features will be popular).
We have an even bigger advantage: due to legal concerns, the GNU
developers generally avoid looking at XEmacs code, let alone borrowing
it.  We have no such inhibitions.  Bottom line: if we get a couple of
developers with substantial time to work on the project, we will catch
up very quickly.  You may not want to bet on that, of course, unless
you have time to contribute toward getting the features you need
ported, in which case it's a very good bet.


Footnotes: 
[1]  Stability of code base; AFAIK Emacs doesn't crash more now than
before.