xemacs vs emacs

[David Kastrup]

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

> Visajo writes:
>
>  > I am writing to ask whether statement from book about xemacs is true.
>  > Recently I have read "Linux Programmers Toolbox" and quote from it:
>  > "Xemacs was a fork of Emacs, but now it seems these two programs have
>  > merged into one big happy executable"
>
> That is wrong.  Technically speaking, Emacs has acquired many of the
> features pioneered by Lucid Emacs (later renamed XEmacs), but there
> are still many differences.  XEmacs continues to have better support
> for modern features such as GUI widgets for buttons and tab controls,
> and for dynamic shared objects.

Well, the "better support" seemingly implies non-working Gtk+ and MacOSX
ports.  Emacs has rather well-working ports with native widgets on those
(as well as on Windows).  XEmacs, in contrast, tends to look the same
everywhere.  Namely out of place.

> The Emacs project is generally more active, and XEmacs currently lags
> by several years in several programmer-oriented applications
> maintained by GNU Emacs, such as comint and gdb support.  However,
> most third-party projects such as Gnus, CEDET, and AUCTeX continue to
> support XEmacs, and XEmacs includes more libraries in its package
> distribution than GNU Emacs does in its monolithic distribution.

Mostly in a state several years behind.  It is sort of amusing that you
cite AUCTeX: the AUCTeX developers have for years provided an up to date
working XEmacs package which won't get accepted into distribution by
XEmacs, citing "quality control" politics.  With the consequence that
functionally defective versions that are several years old are then
"included" in the XEmacs distribution.  Users have to use the package
system to deinstall the outdated stuff, then manually reinstall uptodate
packages.

Citing this as an advantage feels like a somewhat strange world view to
me.

Also bug reports in core functionality negatively affecting external
packages tend to have a turnaround time of days to weeks in Emacs,
months to years in XEmacs.

> In fact, at the present time there at least 4 active forks (GNU Emacs,
> XEmacs, SXEmacs, and Aquamacs).  It is unlikely that there will be any
> merges in the near to medium term.

As far as I can tell Aquamacs is not really a fork, but rather a branch.
It does not diverge much from the Emacs trunk, but more or less is a
patch set on top of it.

I can't vouch for the SXEmacs/XEmacs relation.  Could be similar.

> If GNUstep becomes a reasonable desktop platform, it is possible that
> Aquamacs will merge into GNU Emacs (David Reitter, the author, hopes
> so), but at present Emacs vetos the merge on the grounds that Aquamacs
> provides only features that are usable on a proprietary platform (the
> Mac OS X GUI).  In some sense you could say that Aquamacs is a
> "friendly" fork.

This paragraph seems factually wrong on so many fronts that I don't
really know where to start.

> GNU Emacs, XEmacs, and SXEmacs are unlikely to merge ever, because
> their goals are different.  All decisions about GNU Emacs are made for
> political reasons of advancing the cause of free software, even if
> they are detrimental to Emacs itself.

That must be why Emacs is quite more reliable and robust than XEmacs.

> (Of course in most cases, better editor == good for free software, but
> there are many cases of conflict, and they are always resolved
> politically.  The example of DSOs has already been mentioned, while
> the recent decision to use bzr for the future version control system
> of Emacs was made by a person who is totally ignorant of distributed
> version control (Stallman) and in the face of extremely serious
> performance problems.)

Well, that's what started GNU: ignoring the existing state of the art
for political reasons, and starting with something new and/or inferior
that was conscientously acceptable.

Whether this sort of jump-starting bzr will actually get it up to speed
remains to be seen.

> This means that GNU Emacs would have to contact authors to get the
> assignments they want, which is a larger burden than it sounds; in any
> case, Stallman claims it is prohibitively large and that XEmacs code
> is simply unusable in Emacs for legal reasons.[1]

When there are no reliable records about who did what...  I am
collecting assignments for AUCTeX, a comparatively small package.  There
are probably still about 40 prospective outstanding authors where it is
not always clear what, if any, of the current code was contributed by
them.  I have my doubts that we will get sufficient coverage in a sane
amount of time.

> That history shows that at the original fork, all Lucid Emacs code was
> assigned to the FSF[2] and that Lucid did not want long-term control
> of the mainline.

And so on.  One problem was that there was not just "Lucid" code: Lucid
solicited external contributions which it did neither ask assignments
for, nor keep complete records of.

I think that most of the extent code might actually have been available.
However, the stance of Lucid was that the code should be taken as-is, no
further documentation would be provided and no work invested to make it
understandable to anybody else.

There are a _lot_ of parts of XEmacs where nobody is around anymore who
could sensibly work on them.

I think that the Email communications presented by Jamie Zawinski
provide quite a more balanced view than your interpretations.  So I
would refer to them.

Of course they are historic.

> Until recently, Emacs policy tended to encourage removing XEmacs
> compatibility code from 3rd-party libraries it assimilated (from the
> point of view of Emacs it is useless cruft).

It is cruft when it is not maintained.  There is no point in keeping
code around for which nobody has an idea whether it might or might not
work on XEmacs.  In particular, if the last working code is maintained
in the Sumo tree of XEmacs anyway.

> Today it is explicitly OK to keep it, but AFAIK there is no policy
> against removing it.  (I believe this has changed, de facto, with
> Stefan Monnier's appointment as Emacs maintainer.  Stefan has always
> cooperated with XEmacs, going out of his way to provide us with advice
> on similar problems that had already been solved by Emacs, and he has
> done some syncing of XEmacs interfaces to Emacs in the past.)

I doubt Stefan (_one_ of the maintainers) would vote for keeping code
around that nobody knows how to keep working.

> Well, I've presented the truth as I see it.

Probably.  I think it would be better to just refer people to your
sources.  That's what Zawinski did, by reproducing large parts of the
communication.  And it tells a much more diverse truth than what he (or
you) manages to see.

> You would get a very different point of view from Stallman, and yet
> others from other past or current participants in development of
> Emacsen.

That's why it's a good idea to peruse the records and form a view for
oneself.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum