Re: [AUCTeX-devel] Re: Upstream support of XEmacs in AUCTeX

[David Kastrup]

Uwe Brauer <address@hidden> writes:

>    > So I don't see that upstream dropping all support for building
>    > XEmacs packages should affect your work.  Unless I misunderstand
>    > the situation, our XEmacs package support never has been used in
>    > the XEmacs package system, anyway.
>
>    > Am I overlooking something?
>
> Well it seems that I misunderstood your announcement. On one hand I
> appreciate all your efforts of even providing a xemacs pkg and I can
> perfectly understand that you are frustrated that it did not make it
> way into the official xemacs pkg system.  Unfortunately Xemacs does
> not support 3rd party pkg the same way debian dpkg or RH rpm does. I
> raised that subject form time to time but it seems to be a very hard
> problem and I myself have not enough lisp knowledge of even dreaming
> to provide such a functionality.

Basically it seems like a waste of time to recreate the AUCTeX build
process when one can just let the build process run and check the
results in.  In that manner, supporting AUCTeX is not a bit more
complicated than supporting any Lisp-only package.

But it looks like people are intent on doing it the hard way.  Of course
this has the advantage that we don't need to take XEmacs into account
anymore and can remove the respective code.

> However you also write in your mail
>
>    David> I would thus suggest that we discontinue maintenance of the
>    David> XEmacs-related parts of AUCTeX.  It has been a resource hog,
>    David> and only a few selected XEmacs users, those that will use
>    David> our tarball rather than an offical XEmacs package, will ever
>    David> be able to make use of it, anyway.
>
>    David> I would also suggest that we stop investing time to figure
>    David> out how to make AUCTeX features work on XEmacs.  There is
>    David> little point, for example, for supporting non-MULE builds.
>    David> There is also little point in bending over backwards in
>    David> designing operation and interfaces for areas of large
>    David> incompatibilities, like syntax highlighting and display
>    David> engine features (images, folding, and so on).
>
> That sounds to me that you are going to drop support of Xemacs all
> together and again it seems for the lack of active coders.

For the lack of dedicated coders.  Any work supporting XEmacs at the
moment detracts resources from supporting AUCTeX on Emacs.  And even
though with Emacs we have an active, supportive, responsive and thriving
developer community and a solid code base, making AUCTeX keep pace with
what it could and should do is hard.

> It seems to me that there are two possiblites:
>
>     -  you add some new functionality but that code will not work in
>        xemacs 
>
>     -  you add code that may break the usability of auctex for xemacs
>        all together. 
>
> It is the second possibility which worries me a lot but all I can
> offer would be some testing (may be a person with knowledge and
> interest is reading this and would like to play a more active role in
> the Xemacs part of auctex). I hope that for the moment you are not
> really considering to break the usability of auctex for Xemacs users.

We don't want features that are in a state of stasis or bit rot mainly
because of the complexity from XEmacs compatibility.  The LaTeX toolbar
is in that state, and that's mostly my fault because I asked its author
for it.  The multibyte and error parsing support for preview-latex is
close.  The compatibility stuff for font lock code is complicating
things, and still font lock does not work satisfactorily: XEmacs is
unusable on large files and much less accurate.

I am considering dropping Emacs 21 compatibility soon because the Emacs
22 provisions are just a better environment for development.  XEmacs has
not even left the Emacs 20.4 (or so) era consistently.

XEmacs compatibility is crippling AUCTeX development for all of its
users.  And the XEmacs user base is just too small to warrant that.  If
those that actually use XEmacs are not willing or able to get the stuff
to run on XEmacs, because XEmacs is too different or broken or most
likely because nobody really cares enough, then that's just that.

I'd rather have AUCTeX go forward Emacs-only than not at all.

-- 
David Kastrup