GNU Emacs and XEmacs Schism (2001)


By Ben Wing, 2001?

Many people look at the split between GNU Emacs and XEmacs and are convinced that the XEmacs team is being needlessly divisive and just needs to cooperate a bit with RMS, and the two versions of Emacs will merge. In fact there have been six to seven major attempts at merging, each running hundreds of messages long and all of them coming from the XEmacs side. All have failed because they have eventually come to the same conclusion, which is that RMS has no real interest in cooperation at all. If you work with him, you have to do it his way — “my way or the highway”. Specifically:

1. RMS insists on having legal papers signed for every bit of code that goes into GNU Emacs. RMS's lawyers have told him that every contribution over ten lines long requires legal papers. These papers cannot be filled out over to the web but must be done so in person and mailed to the FSF. Obviously this by itself has a tendency to inhibit contributions because of the hassle factor. Furthermore, many people (and especially organizations) are either hesitant to or refuse to sign legal papers, for reasons mentioned below. Because of these reasons, XEmacs has never enforced legal signed papers for the code in it. Such papers are not a part of the GPL and are not required by any projects other than those of the FSF (e.g. Linux does not require such papers). Since we do not know exactly who is the author of every bit of code that has been contributed to XEmacs in the last nine years, we would essentially have to rewrite large sections of the code. The situation however, is worse than that because many of the large copyright holders of XEmacs (for example Sun Microsystems) refuse to sign legal papers. Although they have not stated their reasons, there are quite a number of reasons not to sign legal papers:

2. RMS does not like abstract data structures. Abstract data structures are the foundation of XEmacs and most other modern programming projects. In my opinion, is difficult to impossible to write maintainable and expandable code without using abstract data structures. In merging talks with RMS he has said we can have any abstract data structures we want in a merged version but must allow direct access to the implementation as well, which defeats the primary purpose of having abstract data structures.

3. RMS is very unwilling to compromise when it comes to divergent implementations of the same functionality, which is very common between XEmacs and GNU Emacs. Rather than taking the better interface on technical grounds, RMS insists that both interfaces must be implemented in C at the same level (rather than implementing one in C and the other on top if it), so that code that uses either interface is just as fast. This means that the resulting merged Emacs would be filled with a lot of very complicated code to simultaneously support two divergent interfaces, and would be difficult to maintain in this state.

4. RMS's idea of compromise and cooperation is almost purely political rather than technical. The XEmacs maintainers would like to have issues resolved by examining them technically and deciding what makes the most sense from a technical prospective. RMS however, wants to proceed on a tit for tat kind of basis, which is to say, “If we support this feature of yours, we also get to support this other feature of mine.” The result of such a process is typically a big mess, because there is no overarching design but instead a great deal of incompatible things hodgepodged together.

If only some of the above differences were firmly held by RMS, and if he were willing to compromise effectively on the others and to demonstrate willingness to work with us on the issues that he is less willing to compromise on, we might go ahead with the merge despite misgivings. However RMS has shown no real interest at all in compromising. He has never stated how all of the redundant work that would be required to support his preconditions would get done. It's unlikely that he would do it all and it's certainly not clear that the XEmacs project would be willing to do it all, given that it is a tremendous amount of extra work and the XEmacs project is already strapped for coding resources. (Not to mention the inherent difficulty in convincing people to redo existing work for primarily political reasons.) In general the free software community is quite strapped as a whole for coding resources; duplicative efforts amount to very little positively and have a lot of negative effects in that they take away what few resources we do have from projects that would actually be useful.

RMS however, does not seem to be bothered by this. He is more interested in sticking firm to his principles, though the heavens may fall down, than in working forward to create genuinely useful software. It is abundantly clear that RMS has no real interest in unity except if it happens to be on his own terms and allows him ultimate control over the result. He would rather see nothing happen at all than something that is not exactly according to his principles. The fact that few if any people share his principles is meaningless to him.

Ben Wing

Notes from Xah Lee

This article, was orginially at as of ~2005, but is gone as of . The content is retrived from on .

The article is probably written in . Because's first archived content of the URL is dated .

Ben Wing ([ ] 2015-11-11) was one of the main developer of XEmacs, after Jamie W Zawinski. However, Ben Wing got severe Repetitive Strain Injury, and eventually left programing field. For more detail about this, see: Famous Emacs People With Hand Injuries.

XEmacs came from Lucid Inc. Richard P. Gabriel founded Lucid Inc in 1984, and the comany eventually developed Lucid Emacs as a C++ IDE as its main commercial product. Richard Gabriel hired Jamie W Zawinski (aka jwz), and jwz is the lead developer of Lucid Emacs. When Lucid folded in 1994, Lucid Emacs is renamed XEmacs. Richard Gabriel wrote a book named Patterns Of Software, published 1996, which accounts some XEmacs vs GNU Emacs history. I wrote a review in 1998, see: Book Review: Patterns of Software.

See also:

After reading them carefully, you'll see that what's called “EMACS” (Editor MACroS), starting with TECMAC and TMACS, are really different software with different implementations, by different people, on different operating systems, for about 4 or more years starting in 1976. When reading about these, you need to put your mind on what computers are like at those times. Typically, a monochrome text terminal, with screen size of 80 by 24 characters!

The typical “editor” at the time operates by modes. That is, you type the command to delete a word, then another command to update the screen to see the word deleted. This is where vi's operation method originated, and also why these emacs editors call themselves as “real-time”, and “DISPLAY” editor, meaning what you typed is updated in real time and in a display, a forerunner concept similar to “what you see is what you get” (WYSIWYG) and graphical user interface (GUI).

One of the popular terminal, the DEC VT100, introduced in 1978. The screen size is 80 columns by 24 lines.

I'm guessing that Richard Stallman's GNU Emacs didn't become the main emacs till mid 1980s, Then, XEmacs become widely popular and competitor to GNU Emacs in the 1990s.

All these are before my time. I started using a computer only in 1990. I started to use emacs in 1998 and quickly switched to XEmacs as my choice. See: My Experience of GNU Emacs vs XEmacs (2007). But since ~2005, XEmacs has fallen due to many reasons.

Why Did XEmacs Faded

It'd be too much to write on why, but here's a summary of what i think: due to the onset of Internet/Web popularity in the mid 1990s together with Apache, Perl, Linux, and the whole Open Source movement. Richard Stallman, starting in ~1998, is often interviewed by mainstream media, with regular lecture invitations around the world. He is constantly in the limelight. When it comes to a editor, His GNU Emacs naturally benefits from this attention than its competitor XEmacs. (he often resent software that isn't his own, either because they are not completely “free” by his ideal, problem he sees in licensing, or simply not his. e.g. BSD unixes, KDE, Linux, XEmacs.) So gradually, GNU Emacs gets more developers, got Unicode support, largely caught up with XEmacs by early 2000s. XEmacs, long de-coupled with a commercial sponsor, is without a meaningful goal or leaderhip, just gradually languished.

It is unfortunate, since XEmacs really is ahead of emacs in many technical ways. XEmacs's current semi-dead status is well relfected from its website Pages there haven't been updated for 5 or 10 years. Its current maintainer, Stephen Turnbull, is a regular participant on GNU Emacs dev forum.

Here's a detailed document on Multics Emacs, written by Bernard S Greenberg, around the same time GNU Emacs of Richard Stallman was written. It gives a clear idea what text editing was like in the late 1970s, and the context for the birth of Real Time Display Editor. Bernard Greenberg is one of the lispers at the time, who is a founder of Symbolics.

[Multics Emacs: The History, Design and Implementation By Bernard S Greenberg. At , accessed on 2010-06-28 ]

Another founder of Symbolics, Dan Weinreb (1959 to 2012), has also written a article related to history at the time. Dan is also the author of another emacs at the time, called EINE (EINE Is Not Emacs), which is the first emacs written in Lisp Machine Lisp, and runs on Lisp machine. (EINE and ZWEI)

[Rebuttal to Stallman's Story About The Formation of Symbolics and LMI By Daniel Weinreb. At (local copy History of LISP, Emacs, Symbolics (Daniel Weinreb Rebut Richard Stallman) )]

[see Lisp Programer Daniel Weinreb Died (1959 to 2012)]