Re: XEmacs at a crossroads
>> "Stephen" == Stephen J Turnbull
<stephen(a)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.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta