xemacs vs emacs

[Stephen J. Turnbull]

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.  (I believe that Emacs will *never*
get DSOs, as Richard Stallman is strongly opposed to allowing them in
Emacs.)  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.

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

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.  (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.)  XEmacs and
SXEmacs are simply interested in building good editors.  Legal
strategies also differ.  GNU Emacs considers it essential to have
ownership of all code vested in a single entity, while XEmacs and
SXEmacs simply demand license compatibility.  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]

Interestingly enough, Mark Shuttleworth (founder of Thawte and Ubuntu)
recently suggested to me that Emacs and XEmacs should share a
(distributed) version control repository.  Historically this would
have been impossible for political reasons, but today it's an
interesting idea (in fact Emacs has been imported into XEmacs CVS as a
vendor branch, but this was never used much).

XEmacs and SXEmacs will not merge because of diverging goals for
platform support.  XEmacs believes in supporting the tired, poor
Windows users longing to be free, while SXEmacs has thinks that
Windows support is just too painful, and has removed all code related
to Windows.  SXEmacs also basically requires GCC 4.x for some features
such as the FFI, which XEmacs is unwilling to do at the moment.

Note that SXEmacs is also a "friendly" fork of XEmacs.  I imagine that
Steve Youngs will happily admit that personality issues were important
in the fork, but that they were generally incited by deep-rooted
differences between his goals and those of the XEmacs developers.  In
fact today there is substantial cooperation between these two
projects, most obviously in the shared maintenance of the unbundled
Lisp packages, but also in sharing bug fixes where the code has not
diverged, and Steve Youngs remains on the XEmacs Review Board (the
cabal of senior maintainers of XEmacs).

I know that Stallman has published a piece called the "Origin of
XEmacs" blaming XEmacs for the failure to cooperate.  You can find it
at the URL http://www.stallman.org/articles/xemacs.origin.  This is
very painful for me to read, because it is quite clear that equal
blame rests with Stallman himself.  In any case, if you read
Stallman's essay, you should also read the words that he wrote at the
time of the fork, presented in http://www.jwz.org/doc/lemacs.html,
along with various other players' viewpoints.

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.  Lucid *did* want the features essential to its business
plan would be merged immediately and without much change, they *were*
pretty arrogant about the quality of their code, and they *were*
unyielding about their priorities.  However, they were willing to
contribute in other ways as long as their business goals were met, and
both Lucid as a company and individual employees had a history of
doing so (both in code/docs and financially to the FSF).  Furthermore,
over the years since the fork individual XEmacs developers have made
many contributions directly to Emacs, often at substantial cost in
reworking code to RMS's specifications, not to mention indirect
contributions by their work on projects like Gnus.  There has been no
lack of cooperation from the XEmacs side over the years.  There was
even a two-year effort by the XEmacs maintainer to encourage FSF
assignments of contributions to XEmacs, but that ended when Stallman
called it useless.

OTOH Stallman clearly wanted Lucid to work as his unpaid servants,
doing the work that he himself had avoided for several years, not the
work that they needed for their business.  There is no doubt in my
mind that Stallman's definition of cooperation is "do it my way".  He
never showed any willingness to cooperate himself, by allowing others
to do the work they needed done, and then build on that.  For example,
in the Lucid case, Stallman argued that Lucid Emacs was based on Xt,
which he considered too "heavyweight" to impose on users with smaller
machines or heavily loaded multiuser hosts.  This may be true, but it
is very attractive to consider a quick merge (2-3 months to release)
of the Lucid code *en bloc*, followed by work in the Lucid framework
to add an Xlib-only port of the GUI.  It is plausible that Stallman
could have negotiated a commitment from Lucid that they would devote
programmer time over the next year to that Xlib port.  If so, there
would have been a release of the most of the features Stallman wanted
far earlier than actually happened.  In the meantime, Emacs 18.59
would have been a perfectly acceptable platform for users who didn't
want the overhead of Xt---especially considering that the fork left
them with no other choice, anyway.  That would have been true
cooperation: Stallman postponing his goal of an Emacs 19 with Xlib
support, and Lucid contributing the efforts of probably the very best
Emacs programmers of the day (with the possible exception of Stallman
himself---but he was out of practice).  This was implicit in Lucid's
proposals (they didn't actually promise to help with Stallman's goals,
but they did outline that path of development).

But it was not to be; Stallman considered that to be capitulation to
Lucid, and he forced the fork rather than reduce priority of any of
his technical goals below those of Lucid.  (Of course, since Lucid's
business goal was to leave maintenance of Emacs in GNU's hands, there
was no fear of compromise of software freedom.)

GNU Emacs's record on cooperation was dismal for the first decade of
the fork.  There was no effort to maintain compatibility with
interfaces introduced by XEmacs.  Rather, from the very beginning
incompatibilities were introduced.  XEmacs's developer channels have
always been public (this was not true of Lucid, but the Lucid
developers were certainly open to discussion with anyone), while
anyone with XEmacs connections but no large contributions to GNU Emacs
was deliberately blackballed from Emacs developer and beta tester
channels until about 1999.  This included official GNU maintainers
such as Hrvoje Niksic, author of wget.  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).  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.)

SXEmacs has its own home page at http://www.sxemacs.org/, but last I
looked there wasn't much history there.  I suspect Steve would say,
"The history was painful, the features are fun.  Let's focus on the
fun!"

Aquamacs has a home page which you can reach via
http://aquamacs.sourceforge.net/.  I don't think it has much
historical content, either.

 > I would like to know the truth, what this "difference" is all about.

Well, I've presented the truth as I see it.  You would get a very
different point of view from Stallman, and yet others from other past
or current participants in development of Emacsen.

Footnotes: 
[1]  Amusingly enough, in a meeting of MULE developers in Tsukuba
Japan, Ken Handa removed all the pens for the whiteboard to prevent
any XEmacs developers from writing code that he would then be unable
to use in the integration of MULE into GNU Emacs.

[2]  This was not true of the Lucid Widget library, but I don't know
how much of that was ever used in Emacs.