Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Google   

Nikolai Bezroukov. Portraits of Open Source Pioneers

For readers with high sensitivity to grammar errors access to this page is explicitly prohibited :-)

Prev Up Contents Next

The Short History of the Development of Emacs and XEmacs

I am not big fun of GNU Emacs (see my editors page) and that's why I can probably be a more or less objective observer ;-). As for editors I prefer THE and VIM as editors and TCL or REXX as a macro languages.

Emacs is probably the oldest editor in wide usage (may be IBM's Xedit is the only competitor), a dinosaur from the long forgotten era of Tops-20 and  PDP-10 computers. It began his life as an extension of TECO, an editor for very innovative Tops-20 OS on PDP-10.  Paradoxically TECO is also related to vi -- the editor that have philosophy completely opposite to Emacs and vastly more popular in Unix world. Ian F. Darwin and Geoffrey Collyer wrote in the excellent paper about the history of early Unix tools (A History of UNIX before Berkeley UNIX® Evolution, 1975-1984):

The original standard UNIX line-mode text editor ed has a lineage longer than many of us do. As early as 1969, the first assembly-language version of ed was in place. Although later rewritten in C, the editor is fundamentally the same program as used then. As Kernighan and Plauger wrote in 1976,

The earliest traceable version of the editor presented here is TECO, written for the first PDP-1 timesharing system at MIT. It was subsequently implemented on the SDS-940 as the ``quick editor'' QED by L. P. Deutsch and B. W. Lampson; see ``An online editor,'', CACM December, 1967[Deut1967a]. K. L. Thompson adapted QED for CTSS on the IBM 7090 at MIT, and later D. M. Ritchie wrote a version for the GE-635 (now HIS-6070) at Bell Labs.

The latest version is ed, a simplified form of QED for the PDP-11, written by Ritchie and Thompson. Our editor closely resembles ed, at least in outward appearance. [Software Tools, page 217]

This is not to say that ed is the same as the TECO found on some DEC computers. For one thing, TECO is character-oriented while ed is line-oriented. It seems rather a case of ``common ancestry.''

During the 1970's, the editor went through countless revisions. Nearly every university had its own modified versions of ed and qed; some had several modified versions. Jay Michlin of Bell Labs wrote (in IBM assembler) a QED for IBM's mainframe TSO; this was released to Universities in the mid-70's. This was, in fact, one of my (Darwin) earlier exposures to the UNIX philosophy; around 1975, I heard about a ``spiffy new editor'' for TSO (the IBM mainframe Time Sharing Option), so ordered and installed it on the TSO system at the University of Toronto. And, of course, ed would visit Berkeley and, while there, mutate into ex and vi.

Did this wide variety of editor versions lead to massive confusion? Not really. For although most of the editors added new commands and features, they seldom deleted them. The result was that you could - and this is still true - learn a basic set of ed commands and special characters usable on every version.

Today the Seventh Edition, 4.xBSD and System III/V versions of ed are all sufficiently similar that one can move freely amongst them with only minor inconvenience. The manual pages for every current version of ed are all recognizably derived from the Sixth Edition document. System III/V extends the `u' (undo) command, but most of the other commands are constant. If you've used ed, you've used an editor with a long history, and probably a long future.

Here is how wikipedia describes Emacs history. Please note that it was not Stallman but Guy Steele who in 1996 began the effort of unifying the macro sets written by the users (the initial version of Emacs was essentially a collection of macros for TECO):

Emacs began at the Artificial Intelligence Laboratory at MIT. Prior to its introduction, TECO was the default text editor in ITS, the operating system on the AI Lab's PDP-6 and PDP-10 computers.

Unlike modern text editors, TECO abstracted the task of typing from editing, so that modifying a document at times required writing a series of instructions in the TECO command language. This behavior is similar to the program ed, which is still in use.

Carl Mikkelsen, one of the hackers at the MIT AI Lab, added a display-editing mode to TECO, which allowed the screen display to be updated each time the user entered a keystroke. This more-intuitive behavior, which is used by most modern text editors, had been pioneered by the "E" editor written at the Stanford AI Lab. In 1974, Richard Stallman, another hacker, added a macro feature to the TECO display-editing mode. This allowed the user to define keystrokes which would perform multiple TECO commands.

The users at the AI Lab soon accumulated a large collection of custom macros. In 1976, Guy Steele began an effort to unify the many divergent macro sets. The project was completed by Stallman, who also wrote facilities for extension and self-documentation. The resulting program was called EMACS (all caps). Though built on TECO, its behavior was different enough to be considered a text editor in its own right.

In 1978, Bernie Greenberg wrote Multics Emacs at Honeywell's Cambridge Information Systems Lab. This was a major achievement: the editor was written in MacLisp, a dialect of the LISP programming language. User-supplied extensions were also written in Lisp. That was the first real Emacs with Lisp as an extension language, as we know it today. Gosling Emacs, the first Emacs to run on Unix, was written by James Gosling in 1981. It was written in C, with MockLisp, a small dialect of Lisp, as an extension language.

I would like to stress that the first version of EMACS that uses Lisp as an macro language was originated not by Stallman, but by Bernie Greenberg (see Multics Emacs History Design Implementation). Also  GNU Emacs itself was largely based on Gosling Emacs by James Gosling (of Java fame). Actually Gosling Emacs indirectly gave birth to GPL as it was RMS reaction to commercializing of Gosling Emacs.  Here is Jamie Zawinski timeline for Emacs development: 

1976    EMACS
        by Richard Stallman
        ran on ITS and TWENEX (Tops-20)
        written in TECO and PDP 10 assembly.

1978    Multics Emacs
        by Bernie Greenberg
        written in MacLisp;
        first version to use Lisp as
        an extension language.

                               EINE (EINE Is Not EMACS)
                               by Dan Weinreb and Mike McMahon
                               for MIT Lisp Machine
                                   |
                                   |
1979                           ZWEI (ZWEI Was EINE Initially)
                               by Dan Weinreb and Mike McMahon
                               (later known as ZMACS)

1981                                           Gosling Emacs
                                               by James Gosling
                                               written in C; with
                                               "Mocklisp" as ext. lang.
                             ______________________/
                            /
                           /
1984?                     /             Hemlock
                         /              by Rob MacLachlan et al
                        /               written in Spice Lisp
                       /                (CMU Common Lisp)
1985  GNU Emacs 15.34 (early 85)
      by Richard Stallman
             |
             |
      GNU Emacs 16.56 (15-jul-85)
      (Gosling code expunged
       for copyright reasons)
             |
             |
      GNU Emacs 16.60 (19-sep-85)
      (contained first patches from
      the net, including preliminary
      SYSV support)
             |
             |
      GNU Emacs 17.36 (20-dec-85)
      (included TeX manual; first
      version that worked on SYSV
      out of the box)
             |
             |
1986  GNU Emacs 18.24 beta (2-oct-86)
             |
1987  GNU Emacs 18.41 (22-mar-87)
             |
      GNU Emacs 18.45 (2-jun-87)
             |
      GNU Emacs 18.49 (18-sep-87)
             |
1988  GNU Emacs 18.50 (13-feb-88)
             |
      GNU Emacs 18.51 (7-may-88)
             |
      GNU Emacs 18.52 (1-sep-88)
             |
1989  GNU Emacs 18.53 (24-feb-89)                           Epoch (1989?)
             |                                              by Simon Kaplan,
             |                                              Chris Love, et al
             |                                                        |
      GNU Emacs 18.54 (26-apr-89)                                     |
             |                                                        |
      GNU Emacs 18.55 (23-aug-89)                                     |
             |   \    \                                               |
             |    \    \____________________________________________  |
             |     \                                                \ |
1990         |      \                                     Epoch 3.2 (11-dec-90)
             |       \                                                |
             |        \____ (sporadic work on                         |
             |               GNU Emacs 19 begins)                     |
             |                     |                                  |
             |                     |                      Epoch 4.0 (27-aug-90)
             |                     |                                  |
1991  GNU Emacs 18.57 (??-jan-91)  |                                  |
             |                     |                                  |
      GNU Emacs 18.58 (??-???-91)  |                                  |
             |                     |___________                       |
             |                     |           \                      |
1992         |                     |   Lucid Emacs 19.0 (??-apr-92)   |
             |                     |   by Jamie Zawinski et al        |
             |                     |      |                           |
             |                     |   Lucid Emacs 19.1 (4-jun-92)    |
             |                     |      |                           |
      GNU Emacs 18.59 (31-oct-92)  |   Lucid Emacs 19.2 (19-jun-92)   |
             |                     |      |                           |
             |                    /    Lucid Emacs 19.3 (9-sep-92)    |
             |                   /        |                           |
             |                  /      Lucid Emacs 19.4 (21-jan-93)   |
             |   ______________/          |                           |
             |  /                      Lucid Emacs 19.6 (9-apr-93)    |
             | /                          |                           |
1993  GNU Emacs 19.7 beta (22-may-93)     |                          /|
      first public v19 beta               |                         / |
             |                            |                        /  |
      GNU Emacs 19.8 beta (27-may-93)     |                       /   |
             |        \                   |                      /    |
             |         \________________  |  ___________________/     |
             |                          \ | /                         |
             |                         Lucid Emacs 19.8 (6-sep-93)    |
             |                         (Epoch merger, preliminary     |
             |                          I18N support)                 |
             |                            |                           |
      GNU Emacs 19.22 beta (28-nov-93)    |                           |
             |                            |                           |
1994         |                         Lucid Emacs 19.9 (12-may-94)  /
             |                         (scrollbars, Athena)         /
             |                            |                        /
      GNU Emacs 19.23 beta (17-may-94)    |                       /
             |            \               |                      /
             |             \____________  |  ___________________/
             |                          \ | /
             |                         Lucid Emacs 19.10 (27-may-94)
             |                         last JWZ release
             |                            |
      GNU Emacs 19.24 beta (16-may-94)    |
             |                            |
             |                         XEmacs 19.11 (13-sep-94)
             |                         Lucid Emacs -> XEmacs renaming.
             |                         now maintained by Chuck Thompson
             |                         and Ben Wing.
             |                            |
      GNU Emacs 19.27 beta (14-sep-94)    |
             |                            |
      GNU Emacs 19.28 (1-nov-94)          |
      first official v19 release          |
             |                            |
1995         |                         XEmacs 19.12 (23-jun-95)
             |                         (tty support)    \
      GNU Emacs 19.29 (21-jun-95)         |              \
             |                            |        (work on 20.x begins)
      GNU Emacs 19.30 (24-nov-95)         |               :
             |           \                |               :
             |            \_____________  |
             |                          \ |
             |                         XEmacs 19.13 (1-sep-95)
1996  GNU Emacs 19.31 (25-may-96)         |
             |                         XEmacs 19.14 (23-jun-96)
      GNU Emacs 19.34 (21-aug-96)         |                   \
1997         |                         XEmacs 20.0 (9-feb-97)  \
             |                         now maintained by        \
             |                         Steve Baur                |
             |                            |           XEmacs 19.15 (26-mar-97)
             |                            |                      |
             |                         XEmacs 20.1 (15-apr-97)   |
             |                            |                      |
             |                         XEmacs 20.2 (16-may-97)   |
      GNU Emacs 20.1 (17-sep-97)          |                      |
             |                            |                      |
      GNU Emacs 20.2 (20-sep-97)          |                      |
             |                            |           XEmacs 19.16 (31-oct-97)
             |                            |
             |                         XEmacs 20.3 (21-nov-97)
             |                            |
1998         |                         XEmacs 20.4 (28-feb-98)
             |
      GNU Emacs 20.3 (19-aug-98)

In 1992 XEmacs emerged as a GUI-based alternative to Emacs. This was one of the first forks of GNU products, and the  GNU Emacs saga vividly had shown that free/open software development is not without problems and contradictions. Here is one very telling letter that raise the question of RMS supersized ego and its effect on GNU project:

Message-ID:   <9206230437.AA02757@inferno.lucid>
Date: Mon, 22 Jun 92 21:37:51 PDT
From: rpg@lucid.com (Richard P. Gabriel)
To: help-lucid-emacs@lucid.com, epoch@cs.uiuc.edu
Cc: rms@gnu.ai.mit.edu, dansmith@autodesk.com, ebubra@ebu.ericsson.se
Subject: Epoch and EMACS merger

I read RMS's message with sadness. Over the past two years I have tried very hard to figure out a way to work with FSF on Emacs, and for a lot of that time I thought we were working together, but apparently I failed. For those of you who wish to read about that effort, you can read the postscript to this note, which outlines Lucid's involvement - a sort-of history of the events.

We still want to work with FSF and have our contributions become part of FSF Emacs, and we are eager to hear suggestions on how to proceed.

-rpg-

P.S. RMS's letter paints an unflattering and unfair picture of Lucid's involvement with Emacs, and in particular on the motives and efforts of our hackers.

The Free Software Foundation is a remarkable organization - for many years I have supported it personally (and still do), and my company supports it, its goals, and its products. This support is in terms of time, effort, and dollars.

RMS says:

However, the people who wrote the Lucid version didn't try to to make the changes usable for us. They charged ahead without discussing the design with me or with the main Emacs maintainer. They reimplemented things we had already done. I asked them to do some work making parts usable for us, but they said no.

This is not how we at Lucid remember events, although it may be a difference without a distinction. I'll recount the events as I recall them and let the reader supply the characterization.

Lucid set a course 4 years ago to develop a C/C++ programming environment, using Emacs as a key component. We needed a small number of specific things:

My goals with respect to FSF were these:

For the first two years we prototyped the functionality we needed in an X-widget-based text editor and in Epoch.

By the Summer of 1990, Emacs 19 appeared to be right around the corner, so we entered discussions with the person at FSF whom we were led to believe was the official Emacs 19 coder - Joe Arceneaux. It appeared that our goals and FSF's were in line, and so he proposed that we pay him a consulting fee to speed up Emacs 19 development plus get our changes in. We agreed, wrote a contract, and volunteered manpower to help.

The contract period started October 1990, was to last approximately 9 months. We were to pay him approximately $50k. He was paid on milestones, on which he appeared to deliver. In addition, we provided him office space and his own Sparcstation at Lucid. (At the conclusion of this period, it appeared that Joe Arceneaux was no longer the official Emacs 19 coder.)

In the Spring of 1991 it became apparent that the effort was going badly - Emacs 19 as a text editor was slow, and full of bugs. The only people at Lucid who dared use it were Arceneaux and myself. Moreover, Emacs 19 performed hideously in the new areas outlined above. Its behavior was especially bad with respect to active regions -- even worse than our seat-of-the-pants prototype in Epoch.

Nevertheless, we persevered: We re-arranged our Emacs team and priorities to work more closely with Arceneaux, and we were confident the arrangement could work. To be safe, I put 4 of our best hackers on it with Arceneaux. By Summer of last year we became aware that RMS had hired /appointed Jim Blandy as the official Emacs 19 person.

At that time, one of our hackers went out to Cambridge to talk RMS about how to proceed, and it appeared we reached a reasonable working arrangement. But, as time went on we determined that the FSF code for Emacs 19 was too unwieldy, bug-ridden, and convoluted to work with, so we started rewriting parts of it.

In addition to not listening to any design ideas we had, RMS's policy was to require us to provide source diffs and to explain every changed line. Because our efforts towards release were mounting, and we were re-writing massive amounts of the system, source diffs didn't make sense, but RMS and Blandy were unwilling or unable to work at a higher level. I traveled to Cambridge to work things out, and my team had numerous phone conversations with RMS.

One area that was completely rewritten was the implementation of active regions. Various attempts were made to discuss the design with RMS, including a 2 hour telephone conversation from one of my hackers, but he was completely unwilling to consider another point of view. At first, he apparently didn't understand the differences between attaching active regions to text and attaching fonts to text, and when he finally did, he was so wedded to his design for putting fonts in the text that he wanted us to implement BOTH his design for fonts and ours for other active region support.

Our hacker wanted RMS to cooperate to the extent that we would first implement our version to support all of these features, and see how well it worked, but he wouldn't even agree to that. It is worth noting that with the original FSF version, in spite of some rather elaborate tree-balancing code and other hackery for precomputing display characteristics, Emacs redisplay spent more than 40% of its time in the active regions code. In our much simpler version it spends significantly less than 1% of the redisplay time in the corresponding code, even for buffers with a few thousand active regions. (This isn't to say that the original design couldn't be made to work, but several man-months of effort had gone into their original version, and it took less than 2 man-months to implement and debug the code that we shipped with our version. Finally, our version is approximately 1/2 the number of lines of the original, it is more general, and it uses less memory.)

Early last Fall, after spending approximately $70k on Arceneaux, we let his contract expire, but we did put a leased 38.4 kb digital line and an X terminal in Arceneaux's apartment in San Francisco (35 miles away from Lucid), so he could continue to work on Emacs 19 for FSF with Lucid support.

When we learned last Summer that FSF had established an Emacs steering committee, and no one from my organization was put on that, or even informed of its existence, we came to the conclusion that the FSF had no interest in working with us, and we stopped trying. The punch line of RMS' statement is true -- we wouldn't do things they way he wanted. But we didn't ``charge ahead'' without talking to FSF. While we did reimplement some things that they had already done, the things we reimplemented were completely broken. It's true that in the end our work has been unusable by the FSF, but that seems to us to have more to do with their willingness to use it than with anything else.

RMS concludes:

The result is that not much of the code in Lucid's version will ever appear in the FSF's version. Some of the features are worth having, but need to be reimplemented. If you'd like this to happen sooner, one way is to volunteer to do some of the work.

I have trouble imagining how anyone could have worked with with them on this. We may have failed in this attempt, but we have a history of trying, and we have succeeded in other areas.

In addition to working on Emacs, and contributing to Cygnus initial implementations of some new features for gdb, such as a malloc that supports multiple heaps, code to save the internal gdb ``symbol table'' state for a given executable file, and a various C++ debugging features, (as well as paying $100K to have these features officially incorporated into gdb), during the past year we dedicated approximately 1 person-year, spread over 3 people, to producing a new Emacs manual. In addition we have spent a lot of time trying to figure out how to work amicably with FSF.

We have also supported FSF and RMS by selecting several FSF components for our product, an endorsement of their quality and usefulness. Since 1987 Lucid has regularly contributed code (and occasionally money) to FSF. Lucid paid over $200k to support FSF products over the last 2 years. We contributed over 8 hacker-years to improve FSF products.

I personally am a member of LPF (not related to FSF, but related to RMS). I travel about debating various people in RMS's name, and I have actively supported RMS in various private ways. I couldn't figure out how to work with FSF and RMS even though I had years to do it, hundreds of thousands of dollars to spend, and 8 man-years to volunteer. What would you have done differently?

We offer a free Emacs 19 to anyone who wants it, under exactly the same conditions as the FSF, providing commercial support to our paying customers (all improvements arising out of this support become part of the free version as well, of course), as well as answering questions and incorporating changes received from users on the net, and we will continue to develop it. We will rewrite the redisplay code, and we will very probably do work to internationalize Emacs. We also are using scarce documentation resources on the Emacs manual (copyright still held jointly with RMS). However, unlike the FSF, we will also listen to ideas from other people. For one thing, if someone implements an improved version of a feature, we aren't arrogant or inflexible enough to refuse to consider using it. The hackers that worked on our version are concerned about doing a good job for the sake of Emacs, not just for the sake of our company or their egos.

By this time I've ceased expecting that we will work closely with FSF on Emacs, but we would still like to do so. As far as we can tell, the reason that FSF won't use any of our work is that they aren't interested in working *with* us (rather they want us to work *for* them, doing precisely what they tell us to do the way they say to do it, and on their own schedule). Perhaps they assume that our designs and implementations are substandard, but as far as I know they have never really looked at what we have done.

The code of Emacs was forked into XEmacs because of  the delays of the release of version 19.  That was the first demonstration of the important fact that GPL by itself does not protect the product from the fork, only the speed of development and the qualification of the principal author does. As soon as RMS became distracted and speed of development suffered as a result Emacs was forked.

GPL by itself does not protect the product from the fork,
only the speed of development and the qualification of the principal author does.  

This is one fork which is likely to stay, but since packages and macros are interchangeable between the two editors, this isn't too much of a problem. In his paper the Lemacs-FSF Emacs schism Jamie Zawinski described events as following:

In 1991, I was working at Lucid Inc., and our newest product, Energize, was an integrated development environment for C and C++ on Unix. The design of this development environment involved very tight integration between the various tools: compilers, linkers, debuggers, graphers, and editors. So of course we needed a powerful editor to tie the whole thing together, and it was obvious to all of us that there was only one editor that would do: Emacs.

At the time, the current version of GNU Emacs from the FSF was Emacs 18. There was another version of GNU Emacs called Epoch, that had been developed at NCSA, which was a set of patches to Emacs 18 that gave it much better GUI support (Emacs 18 was very much a tty program, with GUI support crudely grafted on as an afterthought.)

For the last few years, Emacs 19 had been due to be released ``real soon now,'' and was expected to integrate the various features of Epoch in a cleaner way. The Epoch maintainers themselves saw Epoch as an interim measure, awaiting the release of Emacs 19.

So, at Lucid we didn't want to tie ourselves to Emacs 18 or on Epoch, because those code bases were considered obsolete by their maintainers. We wanted to use Emacs 19 with our product: the idea was that our product would operate with the off-the-shelf version of Emacs 19, which most people would already have pre-installed on their system anyway. That way, Energize would make use, to some extent, of tools you already had and were already using.

The only problem was, Emacs 19 wasn't done yet. So, we decided we could help solve that problem, by providing money and resources to get Emacs 19 finished.

Even though Energize was a proprietary, commercial product, all of our work on Emacs (and on GCC and GDB) was released under the GPL. We even assigned the copyright on all of our work back to the FSF, because we had no proprietary interest in Emacs per se: it was just a tool that we wanted to use, and we wanted it to work well, and that was best achieved by making our modifications to it be as freely available as possible. (This was one of the earliest, if not the earliest, example of a commercial product being built to a significant extent out of open source software.)

Well, our attempts to help the FSF complete their Emacs 19 project were pretty much a disaster, and we reached the point where we just couldn't wait any longer: we needed to ship our product to customers, and our product needed to have an editor in it. So we bundled up our work on GNU Emacs 19, called it Lucid Emacs, and released it to the world.

This incident has become famous as one of the most significant ``forks'' in a free software code base.

When Lucid went out of business in 1994, and I came to Netscape, I passed the torch for the maintenance of Lucid Emacs to Chuck Thompson (at NCSA) and Ben Wing (at Sun), who renamed it from ``Lucid Emacs'' to ``XEmacs.''

To this day, XEmacs is as popular as FSFmacs, because it still provides features and a design that many people find superior to the FSF's version.

I attribute Lucid Emacs's success to two things, primarily:

Other things that helped Lucid Emacs's success, but were probably less important than the above:

The following messages, from the Lucid Emacs mailing lists in 1992 and 1993, comprise the bulk (if not the entirety) of the public discussions between the Lucid and FSF camps on why the split happened and why a merger never did.

The current XEmacs maintainers have a much more pusillanimous summary of this history on their XEmacs versus GNU Emacs page.

Besides Richard Stallman and Jamie Zawinski there were several other important players in this story. Jamie Zawinski mentioned the following people:

It's interesting to reproduce RMS (quite totalitarian) point of view as it looks like this is one of the first instance of "strict" GPL interpretation (note the stance of FSF as the supreme guardian and enforcement power behind all GPLed software) as a subtle underling force of the fork. The accusation of "unfair competition" is pretty symptomatic here (see below) and  actually is quite hypocritical. In the letter reproduced below  RMS managed completely forget about role that GPL played for BSD-licensed software and complain about exactly the same thing that his beloved GPL license used to do with BSD-licensed code:

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't, 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.

Does not this letter remind the style of  Bush administration ?  This hair splitting about legal papers and "my way or highway" attitude ("unilateralism" as it called in politics) was pretty typical feature of FSF. Unfortunately for Stallman but fortunately for the rest of programming world it soon ended as Linux kernel in in the works and will send this idea into early retirement. XEmacs emphasis was (and is ) on more modern graphical user interface support and has an active development community. It runs on Windows 95 and NT, Linux and nearly every other version of Unix in existence. XEmacs is supported by such important players as Sun Microsystems, University of Illinois,  ETL/Electrotechnical Laboratory, Amdahl Corporation, BeOpen, and others, as well by several talented individual developers. In their history file the developers stated:

An alternative to GNU Emacs, XEmacs was originally based on an early alpha version of FSF's version 19, and has diverged quite a bit since then. XEmacs was known as Lucid Emacs through version 19.10. Almost all features of GNU Emacs are supported in XEmacs. The maintainers of XEmacs actively track changes to GNU Emacs while also working to add new features.

Here is how XEmacs site interpreted the main aspects of the split:

XEmacs vs. GNU Emacs

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 bug-gnu-emacs@prep.ai.mit.edu.

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, the differences described persist in the most recent versions of both Emacsen in some form.

User-Visible Editing Features

In XEmacs, images of arbitrary size can be embedded in a buffer. (Soon available in GNU Emacs 21.)

In XEmacs, variable width fonts work. (Soon available in GNU Emacs 21.)

The height of a line is the height of the tallest font on that line, instead of all lines having the same height. (Soon available in GNU Emacs 21.)

XEmacs provides support for ToolTalk on systems that have it. Experimental support for drag-and-drop protocols is provided from XEmacs 21.

XEmacs can ask questions using popup dialog boxes. Any command executed from a menu will ask yes/no questions with dialog boxes, while commands executed via the keyboard will use the minibuffer.

XEmacs has a built-in toolbar. Four toolbars can actually be configured simultaneously: top, bottom, left, and right toolbars.

XEmacs has vertical and horizontal scrollbars. Unlike in GNU Emacs 19 (which provides a primitive form of vertical scrollbar), these are true toolkit scrollbars. A look-alike Motif scrollbar is provided for those who don't have Motif. (Even for those who do, the look-alike may be preferable as it is faster.)

General Platform Support

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.

XEmacs 21 supports database protocols with LISP bindings, currently including Berkeley DB, LDAP, and PostgreSQL (21.2 only).

XEmacs 20 and 21 support the Canna, Wnn, and SJ3 Japanese input method servers directly, as well as through the X Input Method (XIM) protocol. GNU Emacs 20 supports only the XIM protocol. Both Emacsen support the Quail family of input methods (implemented in LISP) for many languages.

Packaged LISP Libraries

Many more packages are provided standard with XEmacs than with GNU Emacs 19 or 20.

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 (incorporating Mule 3 and later Mule 4) represent them as integers.

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 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 uses the MIT "Xt" toolkit instead of raw Xlib calls, which makes it be a more well-behaved X citizen (and also improves portability). A result of this is that it is possible to include other Xt "Widgets" in the XEmacs window. Also, XEmacs understands the standard Xt command-line arguments.

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.

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.) The GNU Emacs development team and internal mailing lists are still by invitation only.

The "bleeding edge" of mainline XEmacs development is available by anonymous CVS as are some subsidiary branches (check out the xemacs-gtk module for the latest in GUI features!)

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.

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.

Prev Up Contents Next

Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Standard disclaimer:

Created May 1, 1996; Last modified: August 27, 2008