[AUCTeX-devel] Upstream support of XEmacs in AUCTeX

[David Kastrup]

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