XEmacsvs.GNUEmacs

XEmacs vs. GNU Emacs 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 xemacs-beta@xemacs.org and emacs-devel@gnu.org.
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
(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.
User-Visible Editing Features 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.
XEmacs provides support for ToolTalk on systems that have it. 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.]
General Platform Support 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.
Packaged LISP Libraries Many more packages are provided standard with XEmacs than with GNU Emacs 22.
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.
LISP Programming 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 not supported.
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.
Window System Programming Interface 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 or Athena.
Community Participation Starting with XEmacs 20, joining the XEmacs development team is simple. Mail to XEmacs Developers <xemacs-beta@xemacs.org>, and you're in! (If you want to be, of course. You're also welcome to just post development-related questions and bug reports.) As of February 2008, XEmacs has a modern bug tracker. The GNU Emacs development lists were opened up as of the version 21 development cycle, and a bug tracking system is under discussion.
XEmacs's bundled packages and the stable XEmacs 21.4 line are kept in a CVS repository, while starting in December 2007, the mainline development was moved to a Mercurial repository. GNU Emacs continues to use CVS although 3rd parties provide bzr, GNU Arch, Darcs, and git repositories, and a move to bzr is under discussion.
In XEmacs, 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 December 2007.
In XEmacs, 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 writing.
The FSF Point of View Richard Stallman writes:
[indent] 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 legitimate.
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.
[/indent] What Is the Legal Issue? 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 100% legal.
However, copyright is governed by the civil 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 cannot 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 some code copyrighted by another entity into a work such as Emacs puts the copyright of all 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.
What Is the Role of the FSF? 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.
Well, Isn't That Paranoid? 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 credible.
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.
Don't the XEmacs Developers Care? 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 we write will remain free. What we are possibly losing is the ability to force others 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.
Fear of Forking Considered Harmful 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 his direction to merge those features that he wanted, making changes to their code as he 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, judge for yourself.
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 you consider broken, and redistribute the improvements.
And a little competition may be good for you! Without the fork, GNU Emacs 20 might not have added Mule, and GNU Emacs 21 might not 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 versions.
Of course, we all think it is best when all the good code that results can be shared:
[indent] All Emacs developers are free software developers. [/indent] But whether or not it can 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.
Author's Disclaimer 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 about it.
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 still gives Jamie Zawinski an excuse to use a wonderful word like pusillanimous. 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