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

[Uwe Brauer]

   > Unless I misunderstand, the patch that is going to be checked into the
   > XEmacs package system does not make any use of the build infrastructure
   > for XEmacs that the AUCTeX upstream has created, but rather tries to
   > incrementally change the previously existing package framework (which is
   > the main reason that the workload for you has been quite difficult if I
   > understand correctly).


This is correct.


   > 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.

So in short if you decide to drop this sort of support that is perfectly
understandable (though sad), and you are right it should be our turn to
provide such a pkg. 

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 our
   David> tarball rather than an offical XEmacs package, will ever be
   David> able to make use of it, anyway.

   David> I would also suggest that we stop investing time to figure out
   David> how to make AUCTeX features work on XEmacs.  There is little
   David> point, for example, for supporting non-MULE builds.  There is
   David> also little point in bending over backwards in designing
   David> operation and interfaces for areas of large incompatibilities,
   David> like syntax highlighting and display engine features (images,
   David> 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.

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.

Uwe Brauer