Upstream support of XEmacs in AUCTeX

Directed to both XEmacs and AUCTeX developer lists. It has become clear in the last few years that the efforts of AUCTeX developers to support XEmacs are basically a waste of time. According to the XEmacs developer lists, there is no noticeable interest in an uptodate AUCTeX distribution. We have up to now provided an XEmacs package-like tarball (I have been educated that calling it an XEmacs package would be wrong, since an XEmacs package is defined by being built in the XEmacs package tree, not by having the complete structure of an XEmacs package). We have scripts in place for creating this tarball. However, the efforts of XEmacs developers that have tried to integrate AUCTeX into XEmacs (without success so far since 11.55) don't make any use of our work: while it would seem completely reasonable to me to start with the XEmacs package-like tarball that our scripts create and start from this ready-for-XEmacs configured state of the relevant startup files for creating the CVS version of the XEmacs package, it would appear that all approaches focus on duplicating the build procedure into XEmacs rather than taking our work as a starting point. In short: it appears that our own attempts at supporting the XEmacs package system are a waste of time. Nothing from that effort will apparently be used or accepted in any form into downstream as long as no AUCTeX core developer becomes a part of the XEmacs development team and does the work himself. I would thus suggest that we discontinue maintenance of the XEmacs-related parts of AUCTeX. It has been a resource hog, and only a few selected XEmacs users, those that will use our tarball rather than an offical XEmacs package, will ever be able to make use of it, anyway. I would also suggest that we stop investing time to figure out how to make AUCTeX features work on XEmacs. There is little point, for example, for supporting non-MULE builds. There is also little point in bending over backwards in designing operation and interfaces for areas of large incompatibilities, like syntax highlighting and display engine features (images, folding, and so on). I expect that bit rot will mostly happen gradually since we are also held back somewhat by Emacs 21.4 compatibility (though we probably can abandon that soon). So if anybody willing to keep newer versions of AUCTeX running on some version of XEmacs by himself volunteers, it is quite possible that not all too much work will be required downstream. I would not want to remove existing XEmacs compatibility code (except likely for the package compilation which can by now be considered a failed experiment without a significant number of people profiting from it). And apart from the package compilation, I'd recommend we stay open for downstream contributions (if there are any) that make life easier for downstream maintenance. But other than that, I don't see a reasonable return of investment for our efforts to keep AUCTeX running on XEmacs. I don't see us (meaning the current core AUCTeX developers) having the resources to put forward the minimum amount of work demanded by the XEmacs policies that would get AUCTeX into a form accepted for downstream distribution. I have also found that people who really depend on having a working, reliable, versatile and efficient TeX environment often are quite sympathetic to the suggestion of switching their editor to Emacs when they understand the various tradeoffs involved. So I would suggest that we announce the end-of-line for our isolated XEmacs support efforts starting with the next release. Am I overlooking something? -- David Kastrup _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta