XEmacs at a crossroads

[Uwe Brauer]

>>> "Stephen" == Stephen J Turnbull <stephen at xemacs.org> writes:

   > To all XEmacs supporters and users:
   > For the past decade, work on XEmacs has continued at a low level, and
   > mostly not visible in user-level features.

Dear Stephen and all the other core developers,

First of all I want to thank you, the core developers, especially Aidan, Mats
and, before he left, Steve Youngs for all their contributions in general
and for their personal contributions to my problems in particular.

You Stephen (T) played an important role in keeping the project alive
(and maybe Xemacs would have reached that crossroad much earlier) in the
last decade. Your willingness to answer all but the silliest question,
your kindness (where others sometimes were blunt) helped a lot. Also you
were a sole voice in GNU emacs dev. Thank you!

I have been using Xemacs since 1992 and it is sad that it has come to
this point.

   > In the meantime, GNU Emacs has implemented almost all XEmacs
   > features,

Right: take my favourite example x-symbol, which was released around
1997. It took GNU Emacs almost 20 years to implement a similar
functionality (pretty-symbol-mode), which is a bit uglier but may be
more efficient implemented, since it uses overlays.

   >  and recently RMS has given the green light to some form
   > of dynamic loading of machine code. At the same time, a number of
   > features (jit-lock and lexical binding seem important) that XEmacs
   > lacks, and would require substantial effort to port, have been
   > implemented.


   > for XEmacs.  I can mention nxhtml, org-mode[1] and magit[2] offhand.

I think it is also fair to add, that even the packages which are *not*
incompatible with Xemacs, such as gnus and especially auctex, provide
*less* features in  Xemacs than they do in GNU emacs.

   > We are sad that XEmacs has fallen so far out of competition with
   > GNU Emacs, but it's time to admit that is the case, and think about
   > what we want to do now.

Sadly true.[1]

   > Several alternative paths
   > have been suggested:

   >     1.  Close up shop and release the resources to other projects.
   >     2.  Close up shop and move en masse to GNU Emacs development.
   >     3.  Fork current GNU Emacs, and gradually recreate an XEmacs-
   >         flavored GNU-Emacs-compatible language and editor.
   >     4.  Maintain infrastructure as a "caretaker" project, for the
   >         benefit of continuing users, and in case somebody wants to
   >         pick up the ball.

   > Option 3 has its attractions[3], but no commitment from developers
   > with a history of substantial contributions of code.

Well I think it made much sense 20 years ago to fork GNU Emacs, since it
lacked X support. But today, in my opinion, it would look as a «cheap»
robbery. And wasn't the «data-abtraction» concept one core conflict? So
that would be given up?

Since switching to GNU emacs a couple of weeks ago, I am asking myself
what makes Xemacs different from GNU Emacs (besides lisp syntax
differences, and some UTF8 coding issues)? Well for me the menus/widgets
GNU Emacs provides are still very ugly compared to Xemacs. Could those
be ported to GNU emacs? What do others think what is the main difference
in functionality between both, what would you do differently?

   > That leaves option 4, or maybe a
   > While binary package releases will continue to be provided in
   > "Pre-Releases", there are no plans yet for a full SUMO release.  It's

I am still willing to maintain the auctex package, but I ask: why can't
it be moved to the official release? For the average user to dig out
actualized packages from the pre--release directory is cumbersome at
least.


Regards

Uwe Brauer 

Footnotes: 
[1]  Although it might be a fascinating question for software
     historians. How could a technical superior software lose so
     much of its advantages?
     Was it that GNU Emacs was easier to program, was its documentation
     better?
     Was it that the some core Xemacs developer considered Xemacs 21.4
     already as mature?
     Was it that some of the core developers forked
     21.4 for their one projects?
     For me one turning point was when Ben Wing left.