I didn't mean to start a war and perhaps we should just let the topic
I just felt that not enough people wrote to explain why they preferred
XEmacs compared to GNU Emacs. For instance, and I will add this to the
article, I really don't like looking at fonts that are not
anti-aliased. Actually, I hate to, and I avoid it if I can. So, GNU
Emacs is a non-starter for me.
on 02/21/2009 10:05 AM David Kastrup said the following:
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> Vladimir G. Ivanovic writes:
> > This may be old news, but just I stumbled upon this:
> > http://www.emacswiki.org/emacs-en/EmacsAndXEmacs
> Seems mostly true, except for the damned lie about "failed attempt at
> an aggressive take-over". The funny thing is that Jamie never wanted
> to be Emacs maintainer, and neither did anybody else at Lucid.
Jamie has excerpts from the mailing lists at
;. It is my personal opinion
that you need a solid pack of blinders in view of the following message
(and others in its ilk) to call RMS' version a "damned lie". It was
quite clearly spelled out that Lucid would only do merge work if they
were in complete control of the resulting Emacs. And it never really
was an option that the merge work could be done by people outside the
Zawinski/Wing circle: code and documentation quality was not sufficient
for outsider work. Heck, not even the current XEmacs maintainers get
along all too well managing that code.
So yes, the options were either let the Lucid people take over control
of Emacs development, or not get a merge because of unavailable
sustainable technical expertise. Jamie spells this out quite
explicitly, and Richard took his pick.
In my opinion, prudently even when putting aside political issues and
only considering the technical ones: it would have put Emacs development
at the mercy of those few understanding the code, and that actually has
turned out to be a bottleneck for XEmacs these days.
I recommend to anybody interested in the story to read the other mails
Jamie puts up. It is a story of incurable differences, not one of
heroes and liars, as you choose to see it.
Date: Thu, 4 Mar 93 12:02:02 PST
From: Jamie Zawinski <jwz(a)lucid.com>
To: rms(a)gnu.ai.mit.edu (Richard Stallman)
Cc: help-gnu-emacs(a)gnu.ai.mit.edu, rpg(a)lucid.com
Subject: Re: About a merged Emacs
But this sounds like a statement that Lucid is not willing to do any of the work
necessary to produce a merged version.
This is not the case; we are willing to help work towards a merge. We are not willing to
do it ourselves unless you say that we get to be the final arbiter of what goes in.
Without that, we do not, at this time, have any confidence that we won't be wasting
The facts speak for themselves: we have tried very hard to work with the FSF. We have
spent hundreds of thousands of dollars and several man-years on it. Clearly we have not
done so successfully, regardless of where the fault for the failure lies, but we did try,
that is undeniable.
We don't think it's too much to ask for you to make the first move as a show of
faith. We've been burned before. We'd like to see some commitment from your side
before committing any more money or resources to this endeavor.
At the same time, Lucid sounds very exigent regarding what features we should include
Whether you include or exclude them from your version of emacs is your decision. But
these are features we need, and if they are not in your version of emacs, then your
version of emacs will simply not be adequate for our purposes.
A couple of specific points are disturbing in another way: they seem to insist that
we remove some of the features of GNU Emacs 19--such as, its unification of menus with
keymaps, and its use of standard Lisp data types rather than creating new opaque types.
You call them features, we call them bugs. We have contractual obligations to maintain
the version of emacs that we distribute, and the design of the data structures used has a
great bearing on how difficult that is.
Is there any chance you could accept a compromise? Such as support for the interfaces
that you now use, as well as the ones we prefer?
Yes, compromise is always possible.
Vladimir G. Ivanovic
XEmacs-Beta mailing list