XEmacs at a crossroads

To all XEmacs supporters and users: For the past decade, work on XEmacs has continued at a low level, and mostly not visible in user-level features. In the meantime, GNU Emacs has implemented almost all XEmacs features, and recently RMS has given the green light to some form of dynamic loading of machine code. At the same time, a number of features (jit-lock and lexical binding seem important) that XEmacs lacks, and would require substantial effort to port, have been implemented. After some discussion on the XEmacs-Review mailing list, we decided to open up a public discussion of the future of the XEmacs Project. Please direct followups to the XEmacs Beta mailing list (xemacs-beta(a)xemacs.org). Reply-To is set for your convenience. The present situation of the core developers who have responded is that the developers who have been the primary contributors of code currently have personal and professional commitments that prevent them from devoting enough time to XEmacs to implement the large features necessary for full compatibility with GNU Emacs for the foreseeable future. Those who have mostly contributed work on infrastructure generally don't have the skills or time to convert to heavy code contributors. The bottom line is that we can not at present promise full GNU Emacs compatibility in the foreseeable future. If you would prefer to use an editor with the most recent features, three core developers have ported personal configurations to GNU Emacs with little difficulty, and say they expect no loss of functionality in using GNU Emacs. For current XEmacs users, converting to GNU Emacs would offer access to a few popular packages not publicly available for XEmacs. I can mention nxhtml, org-mode[1] and magit[2] offhand. I think all the core developers expect many users to stick with XEmacs. Steve Youngs writes: "Everyone who either uses, or hacks on, XEmacs does so for a reason, and we do so by choice. There are probably as many reasons as there are XE users/devs, all I ask is that you don't take away the choice." I think all the core developers feel the same way. The reason this is coming up now is that several developers who have contributed heavily in the past have acknowledged that they *won't* be doing so for the foreseeable future. It's only fair that we let you, our users and supporters, know about that. We all do value XEmacs, its history, the codebase, and you, our community. We are sad that XEmacs has fallen so far out of competition with GNU Emacs, but it's time to admit that is the case, and think about what we want to do now. Several alternative paths have been suggested: 1. Close up shop and release the resources to other projects. 2. Close up shop and move en masse to GNU Emacs development. 3. Fork current GNU Emacs, and gradually recreate an XEmacs- flavored GNU-Emacs-compatible language and editor. 4. Maintain infrastructure as a "caretaker" project, for the benefit of continuing users, and in case somebody wants to pick up the ball. There is no consensus on closing up or on what to do if we did, and therefore options 1 and 2 are off the table. (Individual developers will (and should) do as they want, of course.) Option 3 has its attractions[3], but no commitment from developers with a history of substantial contributions of code. That leaves option 4, or maybe a new "option 5" if somebody has a good suggestion. For those who wish to continue using or developing XEmacs, we have commitments from at least two of the infrastructure contributors to provide minimal support for - mailing lists - tracker - website - source code repositories - package buildbot - binary packages While binary package releases will continue to be provided in "Pre-Releases", there are no plans yet for a full SUMO release. It's quite possible, but there are some resource details (space on the distribution site) to work out. We would like to hear your thoughts. If you have private patches you can contribute to XEmacs 21.5, please let us know about them. They can be integrated. XEmacs 21.4 is very near end-of-life, but Vin Shelton is still maintaining it. We thank you for your support and contributions over the years! With sincere regards from the XEmacs team, Steve XEmacs Beta Release Manager, for the XEmacs Reviewers Footnotes: [1] A couple of developers have private ports of org-mode, which may be made available in the future. [2] magit uses lexical binding, and so is likely to be difficult to port to XEmacs. [3] As well as the potential to upset a lot of people in the GNU Emacs community. _______________________________________________ XEmacs-Announce mailing list XEmacs-Announce(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-announce _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta