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

Reiner> But even the versions in "pre-release" are outdated. Gnus Reiner> 5.10.8 has been released on 2006-04-11. We will release 5.10.10 Reiner> soon. Emacs 22.2 already contains the code corresponding to Reiner> this version. ... Reiner> I don't know which versions are in the stable XEmacs packages. The stable gnus package is 5.10.8 plus a patch. The pre-release version is the stable version plus an additional two patches. ("pre-release" and "stable" are with respect to XEmacs; they don't necessarily refer to the upstream release level.) As for it being outdated, well, hey, 5.10.8 is the latest stable release, isn't it? When 5.10.10 is released, I'll start work to update the XEmacs package. mike _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Reiner Steib writes: I call that support, given that we're hardly doing any more at the moment. We are very grateful for the efforts you do make, and you respond very quickly when XEmacs developers or users have questions or problems. Keeping up-to-date is a non-goal for the core developers. That's one point of the package system, to off-load that onto user-maintainers. In the case of Gnus, that is Mike Kupfer, who is taking his time but definitely not abandoning the packages. In the case of AUCTeX, that is Uwe Brauer with help from Mats Lidell, who have been active recently, but are stuck because we need to make changes to the core to support what they're doing. Also, I will point out to you that in a recent survey (pre-Emacs-22.1) of a large financial firm getting over 200 responses from Emacs-using developers, over half were using obsolete versions of XEmacs or Emacs. What version of Gnus is in Emacs 21? Will the version of Gnus ever change in the lifetime of Emacs 22? How much hope do you have that Emacs 23 will be released in less than 5 years, and how many versions of Gnus will be released in that time? AUCTeX is a special case; the AUCTeX project maintainer objects to the XEmacs package system in principle (although he, and the project, has always been good about supporting XEmacs users of AUCTeX). Unless that changes, or somebody with good knowledge of both projects decides to take over maintainership, that will make working on AUCTeX harder than it could be. The latter could be happening, since Mats Lidell has joined the Review Board. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Reiner Steib <reinersteib+gmane(a)imap.cc&gt; writes: Well, 22.2 has already been released. 22.3 does not sound like being all too far off, either. Oh puleeze! The _only_ party that is _objecting_ to AUCTeX trying to support XEmacs are the XEmacs core team. They don't accept our package in distribution. They demand that we have to scrap our own package build and directory structure and adapt the XEmacs style of installing packages (never mind that this is much less versatile) and that we become active XEmacs developers with CVS access to the package archive and do all of the integration work into the XEmacs package system in order to be _allowed_ to distribute AUCTeX with XEmacs. I am not interested in doing all that extra work in order to artificially arrive at the status quo we already have, a working XEmacs package. I've repeatedly given plenty of help and advice to anybody who believed this to be a worthwhile task. So I am guilty of not investing every amount of work that the XEmacs cabal is _demanding_ so that they don't need to adapt their "quality control" policies to reality. And if I don't do all that work they want done from me in order to save themselves having to either think or code, they will badmouth me on the developer list and berate me for my "unwillingness to support" XEmacs or similar idiocies and clamor over my "objections". I repeat: the only objections about XEmacs support I ever made were to AUCTeX developers who wanted to drop XEmacs support. At some point of time I might give in and no longer object against this stupid uphill battle. Not yet. Sure: I don't volunteer my time to spend as the XEmacs team feels fit to demand. I am not interested in XEmacs myself. I will help people get off the ground where I can, those who _are_ interested in XEmacs and willing to support it with more than just flaming. Few remain seemingly. But that's not my problem. As long as there is anybody willing to do the work, he gets all what can reasonably be expected from me and then some. I have invested a lot of developer time for XEmacs. I have myself alone spent at least three man-months for preview-latex integration into XEmacs, and at least a month for getting the build structure and internal package structure for XEmacs right. What I get in return is ostracization of the package we produce and tirades on the XEmacs list what a bad person I am for objecting to supporting XEmacs and similar crap. I don't think I ever encountered _any_ project where I received so much bad vibration and abuse and obstruction at every turn for so much invested work. We are literally supporting AUCTeX on XEmacs in opposition and in spite of the XEmacs team rather than because of or with it. And people just refuse to get it into their heads that I am not the one blocking the inclusion of the existing AUCTeX package for XEmacs into the package system. We went all the nine yards to support XEmacs. But somebody will have to go all the nine yards again, in the manner prescribed by the XEmacs ruling council in order to arrive at _exactly_ the same place. This is silly, but that is not my problem. I won't stop anybody else from doing that, and he gets my advice and goodwill and help. I am not myself doing the same work in the "superior" XEmacs way (that has not for years found somebody able to actually produce a working XEmacs package). But I am also not standing in anybody else's way. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mats Lidell <matsl(a)xemacs.org&gt; writes: Let's not forget that this has taken _XEmacs_ developers two years. So it seems complicated enough, and I am not at all convinced that no change of directory structure would be needed. Certainly not something that a simple Emacs developer could guess at. Heck, Nix (a rather solid XEmacs hacker) punted with the preview-latex build structure already. I mean, it is nice that something is happening after all, but it is clearly lunatic to claim that it somehow has been my fault for not seeing how simple everything is under XEmacs and solving this with a limp shake of a wrist. -- David Kastrup _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Fine. Remember that. But they don't call you "objecting in principle" to Debian if you have no developers willing to provide and maintain the complete Debian support. Oh, that's all fine. Except that Debian does not constantly abuse and sabotage and blame upstream developers who have no interest of their own in Debian. It is producing _broken_ tarballs of specified format apparently. Unfortunately, that is bunk since the XEmacs package repositories are not platform-specific. Which means that the packages have to be designed to build and run _independently_ of the build system. Apparently because somebody would have to work on it. And you have repeatedly stated that you don't see sufficient user interest in a working XEmacs package of AUCTeX to warrant working on it. No, it isn't. XEmacs packaging of AUCTeX requires expert work, as witnessed by the events of the last years. The "integration work" is not possible for an outsider to do with the existing documentation. Not in a reasonable timeframe. I can't waste my sparse developer time on fixing the broken package build system of XEmacs (which can't even be _used_ without CVS access: there are no tarballs or anything). I have neither time nor inclination to accept it. I respect the people who decide to waste their time fighting XEmacs policies and documentation and integration and code. And I'll support their endeavours. But I am not doing the work myself. If nobody else is interested in a working XEmacs, it will certainly not be me who leaves last and switches off the lights. Though it sometimes feels like I am pretty close already. And if you'd accept that you are (and nobody else is) responsible for reaching your goals. But the effort is not mine to make. -- David Kastrup _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: After apt-get install emacs21 xemacs21 auctex the version of AUCTeX for Emacs is newer than that for XEmacs. And of course, the stable Emacs version is Emacs 22, anyway. No, XEmacs' policy is that there is no support to start with... Anyway, I find your spinning remarkable: AUCTeX is still supported for Emacs 21 (meaning versions of Emacs that are more than 5 years old). There is no support for XEmacs versions of that age. Your musings are out of touch with reality. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

David Kastrup writes: Well, that's because you don't understand the role of the package maintainers. Some of them do keep their packages very up-to-date. The AUCTeX package maintainer, on the other hand, has to deal with you, who have publicly called him incompetent. Can't be, it is true. You claim that a package system that requires package maintainers to commit to a particular repository is unsustainable. How is that not an objection in principle? It is a tarball, not a package. Package sources live in XEmacs CVS. This is required because Emacs's facilities for loading modules do not make it possible to determine dependencies reliably without trying it. Hm? Who are these XEmacs developers and where is this information you've provided? That's not the same thing as providing an XEmacs package. It does require additional work to provide an XEmacs package, which you refuse to do. That's unfortunate for the users, but it is your right. Then stop doing that, David. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Well, the "better support" seemingly implies non-working Gtk+ and MacOSX ports. Emacs has rather well-working ports with native widgets on those (as well as on Windows). XEmacs, in contrast, tends to look the same everywhere. Namely out of place. Mostly in a state several years behind. It is sort of amusing that you cite AUCTeX: the AUCTeX developers have for years provided an up to date working XEmacs package which won't get accepted into distribution by XEmacs, citing "quality control" politics. With the consequence that functionally defective versions that are several years old are then "included" in the XEmacs distribution. Users have to use the package system to deinstall the outdated stuff, then manually reinstall uptodate packages. Citing this as an advantage feels like a somewhat strange world view to me. Also bug reports in core functionality negatively affecting external packages tend to have a turnaround time of days to weeks in Emacs, months to years in XEmacs. As far as I can tell Aquamacs is not really a fork, but rather a branch. It does not diverge much from the Emacs trunk, but more or less is a patch set on top of it. I can't vouch for the SXEmacs/XEmacs relation. Could be similar. This paragraph seems factually wrong on so many fronts that I don't really know where to start. That must be why Emacs is quite more reliable and robust than XEmacs. Well, that's what started GNU: ignoring the existing state of the art for political reasons, and starting with something new and/or inferior that was conscientously acceptable. Whether this sort of jump-starting bzr will actually get it up to speed remains to be seen. When there are no reliable records about who did what... I am collecting assignments for AUCTeX, a comparatively small package. There are probably still about 40 prospective outstanding authors where it is not always clear what, if any, of the current code was contributed by them. I have my doubts that we will get sufficient coverage in a sane amount of time. And so on. One problem was that there was not just "Lucid" code: Lucid solicited external contributions which it did neither ask assignments for, nor keep complete records of. I think that most of the extent code might actually have been available. However, the stance of Lucid was that the code should be taken as-is, no further documentation would be provided and no work invested to make it understandable to anybody else. There are a _lot_ of parts of XEmacs where nobody is around anymore who could sensibly work on them. I think that the Email communications presented by Jamie Zawinski provide quite a more balanced view than your interpretations. So I would refer to them. Of course they are historic. It is cruft when it is not maintained. There is no point in keeping code around for which nobody has an idea whether it might or might not work on XEmacs. In particular, if the last working code is maintained in the Sumo tree of XEmacs anyway. I doubt Stefan (_one_ of the maintainers) would vote for keeping code around that nobody knows how to keep working. Probably. I think it would be better to just refer people to your sources. That's what Zawinski did, by reproducing large parts of the communication. And it tells a much more diverse truth than what he (or you) manages to see. That's why it's a good idea to peruse the records and form a view for oneself. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On Saturday, April 5, 2008 at 02:27:41, Stephen Turnbull wrote: [...] So you say, they did no testing and just decided to use bzr, too bad I like those threads where projects were discussing and testing which DVS to use after cvs/svn. Have performance issues with bzr been the reason why the XEmacs developers have chosen hg? Didier said it was only discussed on the internal mailing list. Robert. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen J. Turnbull wrote: So, it was indeed on xemacs-review＠, right ? -- 5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/ Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85 94276 Le Kremlin-Bicêtre, France Fax.+33 (0)1 53 14 59 22 didier(a)xemacs.org _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen J. Turnbull wrote: Yup, just a bit about git vs. hg under the thread "SCM move planning" I think. -- 5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/ Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85 94276 Le Kremlin-Bicêtre, France Fax.+33 (0)1 53 14 59 22 didier(a)xemacs.org _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

William Xu writes: It's a separately maintained branch that will not be merged in the foreseeable future but is continuously updated with both syncs to the original and new features of its own. If that's not a fork, what do you want to call it? As I wrote, Aquamacs is a friendly fork. But redundant effort is still involved, and the communities are still split. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

David Kastrup writes: Yes, but in this case I discussed it directly with Stefan and David. I won't claim their sanction for the word "fork", but they clearly agree that it's friendly. Of course neither is happy that the combination of Apple's IP and FSF policy make a merge impossible, but neither is anywhere close to advocating a change of FSF policy. And of course we can advocate to Apple as much as we like but that won't affect anything. Seems friendly enough to me. David claims tens of thousands of downloads at each release. I don't see those users posting to emacs-devel. I would expect a couple dozen based our our experience with Choi's Carbon port of XEmacs. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

David Kastrup writes: Huh? If Mac OS X were free software, the merger would be difficult (because of UI guideline issues) but not impossible. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

David Kastrup writes: David Reitter explains it here: http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00785.html and Stefan Monnier confirmed that David's reasoning conforms to Emacs policy in a private conversation later. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

David Kastrup writes: Um, no. According to Stefan and Richard, GNU Emacs refuses to accept such features even if the author is happy to contribute them. What is so hard to understand about "IP == proprietary"? Well, yes, indeed. That's why they[1] call it a "fork". Footnotes: [1] Eg, Dan Nicolaescu, same thread. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

David Kastrup writes: FYI, David, English is not a programming language, it is a natural language. In natural languages, communication is expected to be a *cooperative* effort, with speakers making reasonable attempts to be accurate, and listeners making reasonable attempts to resolve inaccuracies. Obviously, your expectations and mine do not match. I don't care which of us is being unreasonable, let's just end this thread here. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta