Re: XEmacs at a crossroads

Uwe Brauer writes: I agree that's the way it would look in the Emacs community, and I think that's sad. I was attracted to "free" software because it was about sharing. But then I met Richard (virtually) and discovered that the Free Software Movement was not about writing and sharing code, but rather about preventing "hoarders" from using "our" code. This is very different from open source projects (eg, Python), where people are very pragmatic about alternative implementations, including commercial and closed-source implementations. Sure, there's friction about "contributing back", and about who should take responsibility for bugs in "relabeled" commercial implementations. But basically forking is the order of the day. In fact, that's what Github calls a personal branch: a fork. Not entirely, but more than I'm comfortable with. Emacs has become more friendly to abstraction, but nowhere near as much so as XEmacs. Richard is still reactionary on the subject (he still believes data abstraction is antithetic to "hackability"), and the feeling in Emacs that [Some XEmacs] code was not the best match to the bell curve of available intelligence for application programmers, with too low-level concepts bleeding through to the API. XEmacs has more opaque data types than Emacs, but I found the isolation of low-level _concepts_ sometimes less than convincing. -- David Kastrup, personal communication remains strong, I think. I don't recall any of the Emacs-oriented package maintainers (Michael Albinus, David himself, the JDEE guys, yet another Michael who maintained ediff, ...) pining after XEmacs core concepts. David himself encountered them mostly because of preview-latex, I think. Otherwise, I don't think they "bleed through" very much ... but there was that reputation. I don't know, but I doubt it would be straightforward graphics programming. XEmacs by default uses a collection of widgets developed by the Lucid people, while Emacs uses the platform widgets, although I think the Lucid framework is still in there. XEmacs generally implemented wrapper APIs as needed at the C level, whereas GNU tends to hook directly into the platform features. Eg, their Windows/DOS code is far more divergent from that for POSIX platforms than our is. It might be possible to "theme" the GTK widgets more attractively, though. I'm not sure. Norbert has mentioned space issues on Tux. I'm going to look into that. But that doesn't explain why they can't be mv'ed. I hope that Norbert himself will talk about it briefly. The main issue was personal history on the part of developers. One developer spent a couple of years editing the Scheme standard. Several developers graduated from school and got jobs. One went to medical school. A couple have actually passed away. Ben was always loosely attached to XEmacs; he would work in spurts. I think his activity was often driven by consulting work, but he never limited himself to just one task and was always willing to help others (in his own way). It wasn't easy to recruit Emacs developers at all in the 5-year period 2000-2005. It was a point of dissension between Stefan and myself (he claimed we had more developers than GNU Emacs did). I think the main attraction of GNU Emacs is that it is a GNU project. It has always been considered the mainline, except for a couple of years in the early 90s when Richard was ignoring it in favor of free software activism and Lucid Emacs was obviously leading development. I don't think GNU was ever easier to program -- our C API was easier to adapt to new platforms, and our Lisp more modern with many Common Lisp features anabled by default. At that time our documentation was better for programmers (remember, Lucid contributed a complete rewrite of the manuals, and we had about 50% coverage of the design in the Internals manual, which GNU still doesn't have, although a lot of related material is in their Lisp reference), with the exception of the material on specifiers, which as David Kastrup insisted was way too technical and too little "tutorial" material. Steve Baur and Martin Buchholz did, but they didn't try to hold the rest of us back, and did contribute to the discussion. Python and Linux have a lot more forks than Emacs does. Forking is a sign of health, not of weakness. Ben didn't "leave" in the sense of turning his back on XEmacs. The loss of Kyle Jones, Hrvoje Niksic, Martin Buchholz and Steve Youngs were bigger in that sense, but you know what? Pretty much as soon as Steve started SXEmacs, he returned to a friendly relationship with XEmacs core, and there have been a number of contributions back and forth (more large ones from the SXEmacs side since the fork, but of course they got to start from XEmacs, and one of our big contributions to them is a commitment to support SXEmacs in packages. I guess it balances out -- you'd have to ask Steve or other SXEmacs'ers but we've gotten along well ever since, so that's my impression). _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta