XEmacs vs. GNU Emacs
Stephen Turnbull <email@example.com>
<h1>XEmacs vs. GNU Emacs</h1>
Much of this page was written over a decade ago, by somebody
other than the current editor, possibly Ben Wing. The previous
major revision occurred on January 1, 2001, by me. GNU Emacs
has improved a fair amount, but the irreconcilable differences
between the projects continue, with no resolution in sight. I
have little interest in learning enough technical details about
GNU Emacs 22 to accurately revise it, so you should take
everything in square brackets with a grain of salt. -- stephen,
February 19, 2008
There are currently irreconcilable differences in the views about
technical, programming, design and organizational matters between
Richard Stallman (RMS) and the XEmacs development team which provide
little hope for a merge to take place in the short-term future.
If you have a comment regarding a merge, it is a good idea to
avoid posting to the newsgroups, because of the very heated
flamewars that often result. Mail your questions to <a
and <a href="mailto:firstname.lastname@example.org">email@example.com</a>.
Many people have noticed the great difference in focus between the
two "Viewpoints" presented here, and also have expressed confusion
about the legal issues RMS focuses on. The final sections
present some explanation and interpretation regarding these FAQs.
Technical Differences between XEmacs and GNU Emacs<br />
(the XEmacs Point of View)
This section is now quite dated. Much of it refers to GNU Emacs
19 and XEmacs 20. However, many of the differences described persist in
the most recent versions of both Emacsen in some form.
<h3>User-Visible Editing Features</h3>
As of GNU Emacs 22, XEmacs's GUI features (images, variable pitch
fonts, widgets) are reported by some GNU Emacs users to be more
efficient and usable than GNU Emacs's.
<!-- #### Is this obsolete? --> XEmacs provides support for
ToolTalk on systems that have it. <!-- #### Possibly I should
drop mention of DnD? --> Experimental support for drag-and-drop
protocols is provided from XEmacs 21. [Not available in GNU Emacs
21. Status in GNU Emacs 22 unknown.]
XEmacs has a built-in toolbar. Four toolbars can actually be
configured simultaneously: top, bottom, left, and right toolbars.
[A single toolbar was added to GNU Emacs 21.]
<h3>General Platform Support</h3>
Starting with XEmacs 21.4, if your platform supports dynamically
loadable modules, so does XEmacs. RMS continues to refuse to
allow this facility in GNU Emacs, because it makes it easier to
distribute modules in violation of the GPL.
If you're running on a machine with audio hardware, you can
specify sound files for XEmacs to play instead of the default X
beep. See the documentation of the function load-sound-file and
the variable sound-alist. XEmacs also supports the network sound
protocols NAS and EsounD. [Not available in GNU Emacs 22.]
XEmacs 21 supports database protocols with LISP bindings,
currently including Berkeley DB, LDAP, and PostgreSQL (from 21.4).
[Not available in GNU Emacs 22.]
XEmacs 21 supports the Canna, Wnn, and SJ3 Japanese input
method servers directly, as well as through the X Input Method
(XIM) protocol. GNU Emacs 22 supports only the XIM protocol,
although there are now pure Lisp implementations of Canna and Wnn.
Both Emacsen support the Quail family of input methods
(implemented in LISP) for many languages.
As of XEmacs 21.4, although XEmacs supports preloaded Lisp using
"unexec", it is considered obsolete. XEmacs 21.4 uses a much more
portable technique to "dump" and "preload" Lisp. GNU Emacs 22
still uses unexec.
XEmacs 21 supports multiple frames on TTYs. GNU Emacs is
scheduled to get that feature in version 23.
<h3>Packaged LISP Libraries</h3>
Many more packages are provided standard with XEmacs than with GNU
XEmacs 21 supports an integrated package management system which
uses EFS to download, then automatically install prebuilt LISP
libraries. This allows XEmacs users much more straightforward
access to the "latest and greatest" version of any given library.
From XEmacs 20 on, characters are a separate type. Characters can
be converted to integers (and many integers can be converted to
characters), but characters are not integers. GNU Emacs 19,
XEmacs 19, Mule 2.3 (an extensive patch to GNU Emacs 18.55 and
19.x), and GNU Emacs 20--22 (incorporating Mule 3 and later Mule 4)
represent them as integers. [GNU Emacs 23 may get a character type.]
From XEmacs 20 on, the buffer is treated as an array of
characters, and the representation of buffer text is not exposed
to LISP. The GNU Emacs 20--22 functions like buffer-as-multibyte are
In XEmacs, events are first-class objects. GNU Emacs 19
represents them as integers, which obscures the differences
between a key gesture and the ancient ASCII code used to represent
a particular overlapping subset of them.
In XEmacs, keymaps are first-class opaque objects. GNU Emacs 19
represents them as complicated combinations of association lists
and vectors. If you use the advertised functional interface to
manipulation of keymaps, the same code will work in XEmacs, GNU
Emacs 18, and GNU Emacs 19; if your code depends on the underlying
implementation of keymaps, it will not.
XEmacs uses "extents" to represent all non-textual aspects of
buffers; GNU Emacs 19 uses two distinct objects, "text properties"
and "overlays", which divide up the functionality between them.
Extents are a superset of the union of the functionality of the
two GNU Emacs data types. The full GNU Emacs 19 interface to text
properties and overlays is supported in XEmacs (with extents being
the underlying representation).
Extents can be made to be copied into strings, and then restored,
by kill and yank. Thus, one can specify this behavior on either
"extents" or "text properties", whereas in GNU Emacs 19 text
properties always have this behavior and overlays never do.
<h3>Window System Programming Interface</h3>
XEmacs supports Motif applications, generic Xt (e.g. Athena)
applications, and raw Xlib applications. An XEmacs variant which
supports GTK+ is available (integration as an option in the XEmacs
mainline is planned for XEmacs 22), although code to take
advantage of the support is as yet scarce. XEmacs does not
support raw Xlib. GNU Emacs 22 supports Xlib, GTK+, and MS
Windows, with 3rd party or experimental support for Carbon and
Cocoa on the Mac.
XEmacs provides an interface called the "native widget API" for
adding new kinds of widgets (currently including progress bars, tab
controls, and buttons) which can be attached to extents using the
image API. GNU Emacs does not.
As a compile-time option, an XEmacs frame can be placed within an
"external client widget" managed by another application. This
allows an application to use an XEmacs frame as its text pane
rather than the standard Text widget that is provided with Motif
Starting with XEmacs 20, joining the XEmacs development team is
simple. Mail to <a href="mailto:firstname.lastname@example.org">XEmacs
Developers <email@example.com></a>, and you're in! (If
you <em>want</em> to be, of course. You're also welcome to just
post development-related questions and bug reports.) As of
February 2008, XEmacs has a
<a href="http://tracker.xemacs.org/">modern bug tracker</a>.
The GNU Emacs development lists were opened up as of the version
21 development cycle, and a bug tracking system is under discussion.
The XEmacs source code is managed using <a
whereas the GNU Emacs source code is managed using Bazaar.
development and maintenance of Lisp libraries is separated from
the core editor development at a fairly low level. This provides
better modularization and a better division of responsibility
between external library maintainers and the XEmacs core
development team. Even for packages the size of Gnus, XEmacs
users normally have access to a pre-built version within a few
weeks of a major release, and minor updates often within days.
RMS once again vetoed provision of a package system for Emacs in
CVS commit authority is broadly dispersed. Recognized maintainers
of LISP libraries who are willing to maintain XEmacs packaged
versions automatically qualify for CVS accounts for their
packages. Something similar is true for GNU Emacs at the time of
<h2>The FSF Point of View</h2>
<p><a href="mailto:firstname.lastname@example.org">Richard Stallman</a> writes:</p>
XEmacs is GNU software because it's a modified version of a GNU
program. And it is GNU software because the FSF is the
copyright holder for most of it, and therefore the legal
responsibility for protecting its free status falls on us
whether we want it or not. This is why the term "GNU XEmacs" is
But in another sense it is not GNU software, because we can't
use XEmacs in the GNU system: using it would mean paying a price
in terms of our ability to enforce the GPL. Some of the people
who have worked on XEmacs have not provided, and have not asked
other contributors to provide, the legal papers to help us
enforce the GPL. I have managed to get legal papers for some
parts myself, but most of the XEmacs developers have not helped
me get them.
XEmacs was possible because free software means that anyone can
change it and distribute a modified version. I have no regrets
about establishing this freedom for Emacs. Everyone should have
the freedom to change any program, and this is not limited to
changes that the original author likes.
Many people have taken advantage of the freedom to change GNU
Emacs, over the last decade. Most of them were willing to
cooperate on integrating their changes into Emacs. XEmacs arose
as a separate forked version because some of the
developers--starting with Zawinski--were unwilling to do that.
People should have the freedom to decide what to work on,
including the freedom to compete with the GNU project, but it's
a shame when they make that choice. The whole community loses
when someone chooses competition rather than cooperation.
But this is worse than competition--it is unfair competition.
The XEmacs developers can and do copy code they like from Emacs.
If I could copy the code I like from XEmacs in the same way, at
least the rivalry would be fair. But I can't do that, because
substantial parts of XEmacs don't have legal papers, or don't
have known authors.
As long as we cannot use XEmacs in the GNU system, the GNU
project has to make sure that Emacs is not left behind. In
other words, we have to behave like rivals too, even though we
wish there were no rivalry. When XEmacs developers try to
persuade people to use, test, fix and enhance XEmacs instead of
Emacs, the GNU project can't sit still; we need them to use,
test, fix and enhance Emacs instead.
There is good code in XEmacs, which I'd be happy to have in a
merged Emacs any day. But I cannot copy it out of XEmacs myself
because of the uncertain authorship and/or lack of legal papers.
This problem could probably be resolved, at least for large
parts of XEmacs, with substantial help from the authors of that
code. Otherwise, the GNU project has to write or find
replacements for it.
I invite people who like Emacs, and want the best possible
version of Emacs to be available for use in the GNU system, to
help in one way or the other.
<!-- #### This really isn't source for the RMS quote. Obsolete?
Does anyone know where that came from? If not, this can go.
<p><strong>Sources:</strong> <a href="http://www.xemacs.org/FAQ/">FAQ</a>
item 1.0.5, and XEmacs 21.0 NEWS file
<h2>What Is the Legal Issue?</h2>
There is no difference in the nature of the copyrights or licenses
of the two projects. Copyright is defined by law and
international treaty, and is automatically awarded to the author
as soon as a work is published. Both projects use the GNU General
Public License to protect their work while providing it freely to
the community. (GNU Emacs moved to GPL version 3 almost as soon
as it was available; XEmacs is moving in that direction as well.
Of course since XEmacs is licensed under "GPL version 2 or later,"
individuals who wish to redistribute XEmacs under version 3 can do
so. Thus this is not a real difference.)
XEmacs has no choice, because much of its code is copyrighted by
the Free Software Foundation, and is only available to XEmacs
under the GPL. Under that license, redistribution is only
possible under the GPL. The GNU Project uses the GPL as a matter
of principle. (XEmacs developers generally subscribe to a similar
principle, of course.) It is the same GPL, so sharing code is
However, copyright is governed by the <em>civil</em> code, not the
criminal code. This means that the government takes no interest
in violations of copyright as such. It only undertakes to provide
law courts where the copyright can be enforced. It is the
responsibility of the copyright holder to sue to prevent
violations and receive damages for past violations. The
government <em>cannot</em> act on the complaints of third parties.
The FSF has received legal advice that a copyright holder in a
jointly-authored work is in a weak position to enforce its
copyright unless all coauthors participate in the legal action.
Evidently the FSF would be considered a third party with respect
to non-assigned code, weakening its ability to defend the whole
work. (Author's note: You'd have to ask a lawyer why that might
be so. I am not an expert, but lawyers I have asked informally
agree that this theory is plausible, although it has not been
tested in court. It may also be more or less applicable in
jurisdictions other than the U.S.)
Based on this advice, RMS has concluded that incorporating
<em>some</em> code copyrighted by another entity into a work such
as Emacs puts the copyright of <em>all</em> of the work at risk of
being unenforceable in court in the case of a violation. He has
judged that this risk is unacceptably large. Therefore he insists
that the whole copyright of any software that included in the GNU
system be assigned to the FSF, with few exceptions.
<h3>What Is the Role of the FSF?</h3>
RMS believes that copyright in software itself is immoral.
Copyleft is a device to undermine the whole idea. He has little
empathy for people who wish to retain copyright---after all, he
has given up his own. This is the fundamental idea behind the FSF
(as opposed to the GNU Project, which actually develops software).
It is a holding company for all the software copyrights that
shouldn't even exist in the first place. According to the legal
argument above, such a trust is necessary to defend the GPL. It is
the GPL that prevents proprietary firms from misappropriating the
software at the same time as it prevents the holding company (the
FSF) from being a monopoly.
<h2>Well, Isn't That Paranoid?</h2>
Many developers think so, but it seems that no one who holds a
different theory has retained a lawyer to check the precedents.
The FSF has done so, so its position must be considered most
Also, it is important to remember that RMS and the FSF are not (in
this context) acting as software developers. Rather, they
perceive themselves as guardians of a social movement. Their
responsibility is not to any one application or project, but to
the whole GNU system. For that reason as well, a conservative
approach can be justified.
<h3>Don't the XEmacs Developers Care?</h3>
Of course we do. But even if we haven't consulted a lawyer, we
have the right to judge the risks to our own product. Most of us
consider it low. Furthermore, many XEmacs developers take a
different approach to the free software movement itself, and so
will differ from GNU/FSF policy. The code <em>we</em> write will
remain free. What we are possibly losing is the ability to
<em>force others</em> to make their modifications free. This is
central to the GNU Project because it is a social movement. To
many developers as individuals, it is not so crucial.
This also shows why the "Viewpoints" are so different in style.
XEmacs developers consider their project from a technical point of
view, and prefer it for technical reasons. They see their
contributions to the free software movement as stemming from their
development and publication of code. Richard Stallman, and the FSF,
consider their primary role to be more politically and socially
oriented. Thus social and legal issues come to the fore.
<h2>Fear of Forking Considered Harmful</h2>
Few XEmacs developers consider having multiple implementations of
some features a bad thing. The original Lucid fork arose, as RMS
writes, because the Lucid developers (primarily Jamie Zawinski)
would not "cooperate" in merging the Lucid code into the GNU
mainline. What RMS does not mention is that in his vision of
"cooperation" the Lucid developers would be working under
<em>his</em> direction to merge those features that <em>he</em>
wanted, making changes to <em>their</em> code as <em>he</em>
directed. This is obvious, when you think about it. Of course he
was the head of the GNU Emacs project, and would reserve the right
to make final decisions. Nor is it surprising that the Lucid
developers refused. They had egos, of course. But ... well, you
can, and should,
<a href="http://www.jwz.org/doc/lemacs.html">judge for yourself</a>.
But there were also those "irreconcilable technical differences."
Both Lucid Emacs and GNU Emacs 19 were excellent editors, but in
their different ways. The Lucid developers honestly considered
GNU Emacs 19, and the merge as outlined by RMS, to be broken in
some important ways. He, just as honestly, considered many of the
changes the Lucid developers demanded to be broken, or at best to
be fixing what wasn't broken. A fork was inevitable. That's one
thing free software is for: the right to fix what <em>you</em>
consider broken, and redistribute the improvements.
And a little competition may be good for you! Without the fork,
GNU Emacs 20 <em>might</em> not have added Mule, and GNU Emacs 21
might <em>not</em> have the GUI redisplay. Who knows when GNU
Emacs will get a library packaging system? All of these features
were successfully pioneered by Lucid Emacs or XEmacs. They were
implemented at times when RMS considered them broken, irrelevant,
or low priority. Conversely, not only is XEmacs based on GNU
Emacs, but part of the development effort includes regular
synchronization of features and implementations with the mainline
Of course, we all think it is best when all the good code that
results can be shared:
All Emacs developers are free software developers.
But whether or not it <em>can</em> be shared is a matter of point
of view. And the question is quite extraneous to the development
process itself. "How much does the legal system hinder you in
effectively protecting your copyright when you cooperate with
someone unwilling to give up their copyright?" Maybe you don't
need to care.
I disagree strongly with the FSF position in many respects. In
fact it is my personal opinion that in interactions with XEmacs
developers RMS has been more interested in recruiting them to do
work he wants done on Emacs, than in acquiring XEmacs code with
far less effort than it would take to develop it from scratch.
However, I have tried to present the facts of the legal issue as
accurately and objectively as possible, and have some hope I
succeeded. The interpretation of why XEmacs developers as a group
do not worry about this legal issue is my own. The most I can say
is nobody on the XEmacs developer's mailing list has complained
Statements about what Richard Stallman believes, judges,
concludes, and so on should be taken with a grain of salt. I am
not so foolish as to pretend to speak for him. Rather, I have
found certain conjectures useful for establishing a coherent
interpretation of his actions and statements, and have taken the
liberty of making them available to you. The NO WARRANTY section
of the GPL definitely applies to them, though!
I just wanna say that I am proud that this page <em>still</em> gives
<a href="http://www.jwz.org/">Jamie Zawinski</a> an
excuse to use a <em>wonderful</em> word like
There are plenty of venues where you can read endless flames on
these issues. With little effort, you can probably find some of
mine. This isn't one. So big deal.
Stephen J. Turnbull <email@example.com>
<!-- Keep this comment at the end of the file
sgml-parent-document:("../template.html" "html" "body" "table" "tr" "td")