Re: FYI: "Emacs and XEmacs" on the Emacs Wiki

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; 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 <URL:http://www.jwz.org/doc/lemacs.html>;. 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. Message-ID: <9303042002.AA06720(a)thalidomide.lucid.com&gt; Date: Thu, 4 Mar 93 12:02:02 PST From: Jamie Zawinski <jwz(a)lucid.com&gt; 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 RMS wrote: 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 our time. 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 and exclude. 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. -- Jamie