xemacs vs emacs

Visajo writes: That is wrong. Technically speaking, Emacs has acquired many of the features pioneered by Lucid Emacs (later renamed XEmacs), but there are still many differences. XEmacs continues to have better support for modern features such as GUI widgets for buttons and tab controls, and for dynamic shared objects. (I believe that Emacs will *never* get DSOs, as Richard Stallman is strongly opposed to allowing them in Emacs.) The Emacs project is generally more active, and XEmacs currently lags by several years in several programmer-oriented applications maintained by GNU Emacs, such as comint and gdb support. However, most third-party projects such as Gnus, CEDET, and AUCTeX continue to support XEmacs, and XEmacs includes more libraries in its package distribution than GNU Emacs does in its monolithic distribution. In fact, at the present time there at least 4 active forks (GNU Emacs, XEmacs, SXEmacs, and Aquamacs). It is unlikely that there will be any merges in the near to medium term. If GNUstep becomes a reasonable desktop platform, it is possible that Aquamacs will merge into GNU Emacs (David Reitter, the author, hopes so), but at present Emacs vetos the merge on the grounds that Aquamacs provides only features that are usable on a proprietary platform (the Mac OS X GUI). In some sense you could say that Aquamacs is a "friendly" fork. GNU Emacs, XEmacs, and SXEmacs are unlikely to merge ever, because their goals are different. All decisions about GNU Emacs are made for political reasons of advancing the cause of free software, even if they are detrimental to Emacs itself. (Of course in most cases, better editor == good for free software, but there are many cases of conflict, and they are always resolved politically. The example of DSOs has already been mentioned, while the recent decision to use bzr for the future version control system of Emacs was made by a person who is totally ignorant of distributed version control (Stallman) and in the face of extremely serious performance problems.) XEmacs and SXEmacs are simply interested in building good editors. Legal strategies also differ. GNU Emacs considers it essential to have ownership of all code vested in a single entity, while XEmacs and SXEmacs simply demand license compatibility. This means that GNU Emacs would have to contact authors to get the assignments they want, which is a larger burden than it sounds; in any case, Stallman claims it is prohibitively large and that XEmacs code is simply unusable in Emacs for legal reasons.[1] Interestingly enough, Mark Shuttleworth (founder of Thawte and Ubuntu) recently suggested to me that Emacs and XEmacs should share a (distributed) version control repository. Historically this would have been impossible for political reasons, but today it's an interesting idea (in fact Emacs has been imported into XEmacs CVS as a vendor branch, but this was never used much). XEmacs and SXEmacs will not merge because of diverging goals for platform support. XEmacs believes in supporting the tired, poor Windows users longing to be free, while SXEmacs has thinks that Windows support is just too painful, and has removed all code related to Windows. SXEmacs also basically requires GCC 4.x for some features such as the FFI, which XEmacs is unwilling to do at the moment. Note that SXEmacs is also a "friendly" fork of XEmacs. I imagine that Steve Youngs will happily admit that personality issues were important in the fork, but that they were generally incited by deep-rooted differences between his goals and those of the XEmacs developers. In fact today there is substantial cooperation between these two projects, most obviously in the shared maintenance of the unbundled Lisp packages, but also in sharing bug fixes where the code has not diverged, and Steve Youngs remains on the XEmacs Review Board (the cabal of senior maintainers of XEmacs). I know that Stallman has published a piece called the "Origin of XEmacs" blaming XEmacs for the failure to cooperate. You can find it at the URL http://www.stallman.org/articles/xemacs.origin. This is very painful for me to read, because it is quite clear that equal blame rests with Stallman himself. In any case, if you read Stallman's essay, you should also read the words that he wrote at the time of the fork, presented in http://www.jwz.org/doc/lemacs.html, along with various other players' viewpoints. That history shows that at the original fork, all Lucid Emacs code was assigned to the FSF[2] and that Lucid did not want long-term control of the mainline. Lucid *did* want the features essential to its business plan would be merged immediately and without much change, they *were* pretty arrogant about the quality of their code, and they *were* unyielding about their priorities. However, they were willing to contribute in other ways as long as their business goals were met, and both Lucid as a company and individual employees had a history of doing so (both in code/docs and financially to the FSF). Furthermore, over the years since the fork individual XEmacs developers have made many contributions directly to Emacs, often at substantial cost in reworking code to RMS's specifications, not to mention indirect contributions by their work on projects like Gnus. There has been no lack of cooperation from the XEmacs side over the years. There was even a two-year effort by the XEmacs maintainer to encourage FSF assignments of contributions to XEmacs, but that ended when Stallman called it useless. OTOH Stallman clearly wanted Lucid to work as his unpaid servants, doing the work that he himself had avoided for several years, not the work that they needed for their business. There is no doubt in my mind that Stallman's definition of cooperation is "do it my way". He never showed any willingness to cooperate himself, by allowing others to do the work they needed done, and then build on that. For example, in the Lucid case, Stallman argued that Lucid Emacs was based on Xt, which he considered too "heavyweight" to impose on users with smaller machines or heavily loaded multiuser hosts. This may be true, but it is very attractive to consider a quick merge (2-3 months to release) of the Lucid code *en bloc*, followed by work in the Lucid framework to add an Xlib-only port of the GUI. It is plausible that Stallman could have negotiated a commitment from Lucid that they would devote programmer time over the next year to that Xlib port. If so, there would have been a release of the most of the features Stallman wanted far earlier than actually happened. In the meantime, Emacs 18.59 would have been a perfectly acceptable platform for users who didn't want the overhead of Xt---especially considering that the fork left them with no other choice, anyway. That would have been true cooperation: Stallman postponing his goal of an Emacs 19 with Xlib support, and Lucid contributing the efforts of probably the very best Emacs programmers of the day (with the possible exception of Stallman himself---but he was out of practice). This was implicit in Lucid's proposals (they didn't actually promise to help with Stallman's goals, but they did outline that path of development). But it was not to be; Stallman considered that to be capitulation to Lucid, and he forced the fork rather than reduce priority of any of his technical goals below those of Lucid. (Of course, since Lucid's business goal was to leave maintenance of Emacs in GNU's hands, there was no fear of compromise of software freedom.) GNU Emacs's record on cooperation was dismal for the first decade of the fork. There was no effort to maintain compatibility with interfaces introduced by XEmacs. Rather, from the very beginning incompatibilities were introduced. XEmacs's developer channels have always been public (this was not true of Lucid, but the Lucid developers were certainly open to discussion with anyone), while anyone with XEmacs connections but no large contributions to GNU Emacs was deliberately blackballed from Emacs developer and beta tester channels until about 1999. This included official GNU maintainers such as Hrvoje Niksic, author of wget. Until recently, Emacs policy tended to encourage removing XEmacs compatibility code from 3rd-party libraries it assimilated (from the point of view of Emacs it is useless cruft). Today it is explicitly OK to keep it, but AFAIK there is no policy against removing it. (I believe this has changed, de facto, with Stefan Monnier's appointment as Emacs maintainer. Stefan has always cooperated with XEmacs, going out of his way to provide us with advice on similar problems that had already been solved by Emacs, and he has done some syncing of XEmacs interfaces to Emacs in the past.) SXEmacs has its own home page at http://www.sxemacs.org/, but last I looked there wasn't much history there. I suspect Steve would say, "The history was painful, the features are fun. Let's focus on the fun!" Aquamacs has a home page which you can reach via http://aquamacs.sourceforge.net/. I don't think it has much historical content, either. Well, I've presented the truth as I see it. You would get a very different point of view from Stallman, and yet others from other past or current participants in development of Emacsen. Footnotes: [1] Amusingly enough, in a meeting of MULE developers in Tsukuba Japan, Ken Handa removed all the pens for the whiteboard to prevent any XEmacs developers from writing code that he would then be unable to use in the integration of MULE into GNU Emacs. [2] This was not true of the Lucid Widget library, but I don't know how much of that was ever used in Emacs. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta