[AUCTeX-devel] Can XEmacs do anything to support TeX better?

[Stephen J. Turnbull]

Background for AUCTeX developers:

XEmacs 21.6 seems likely to happen.  I would guess that XEmacs 21.6.0
might be released in late winter or early spring of 2010.  However,
there is no concrete schedule yet.  If interested in news, tune in to
XEmacs Beta: http://lists.xemacs.org/mailman/listinfo/xemacs-beta.
Also available on GMane.  Or you can list the issues on the tracker
for the "xemacs-21.6" module: http://tracker.xemacs.org/XEmacs/its/.

This post is a one-time announcement; if it appears that there is
discussion best done on auctex-devel, I'll be tracking that, but from
my side I plan to discuss changes to XEmacs on XEmacs-Beta.

@XEmacs-Beta: this is a repeat of my earlier post (but with flame-bait
removed and technical content somewhat expanded).  Over the next few
days I'll post similar calls for discussion to a couple of major
projects (Gnus, for sure; suggestions for other relevant projects
welcome).

@XEmacs-Beta: the 'xemacs-21.6' and 'xemacs-21.7' modules now exist in
the tracker (but not yet in Mercurial, unless Mike's been busy while I
wasn't looking); we'll see about triaging existing xemacs-21.5 reports
later.  They are all still considered open, of course.

About XEmacs 21.4:

 > David Kastrup writes:

 > Personally, I think it most important to make a plan for getting
 > rid of 21.4.

Plausible.  But think what you like, it's years away so don't plan on
it.  21.6.0 is going to be pretty ugly (unless somebody like Ben Wing
appears to fix the myriad UI usability issues overnight); people who
value stability or consistency will stay with 21.4, just as people who
value stability stayed with 21.1 for years after even I had to admit
that 21.4 was stable.  We will be supporting 21.4 for quite a while,
including after declaring 21.6 stable.

That's not your problem if you don't want it to be, and developing
AUCTeX for XEmacs 21.6 seems like the more attractive option.  XEmacs
will shoulder the burden of supporting XEmacs 21.4 until we're ready
to declare it obsolete.

About XEmacs 21.6 and AUCTeX and friends:

What we can do, IMO, what I will be aiming at (unless Mike and Jerry
et cie convince me otherwise), is a 21.6.0 based on the current 21.5,
with usable external Unicode support (I think Aidan added the feature
you need to handle TeX UTF-8 error messages, if not I would certainly
consider that), and not crashing or hanging.  Maybe Xft support and
GTK+ (updating our code from GTK+ v1 to GTK+ v2 is probably actually
easier than supporting Xft properly).  Regressions in the myriad
user-invisible or unused features like bignums already in 21.5 will be
fixed, plus maybe adding some leading use cases (e.g., add the needed
internal support for large files so bignums would be in daily use in
some use cases).

I don't see a lot there for AUCTeX and other modern Emacs Lisp apps,
to be honest.  More in the lines of providing a near-term migration
path for Mule-UCS users.  Stabilizing APIs sufficiently for a near-
term stable release really precludes sync'ing stuff like font-lock to
recent Emacs, IMO.  With sufficient support from users, or XEmacs
developers, I'd change my mind, but that's what I consider realistic
right now.  Definitely more features will take more time.

Still, if you have specific feature requests to support stuff you'd
like to see in 21.6 to allow AUCTeX and preview-latex to better support
XEmacs, your best bet is to post them to xemacs-beta, or submit them
on the tracker.  (One or the other is fine, our workflow is in flux so
I can't say which is more useful; we'll take care of synchronizing.)
Now is a better time than any time in the last 3 or 4 years.

I have to admit I'm unlikely to be in a position to implement very
many myself, so such proposals would need support from a credible
source of any needed code and maintenance to have a chance to be
included.  That *could* be a current XEmacs developer, but it doesn't
have to be.  We're happy to hold hands for people who want to
contribute to XEmacs, have some skills already, and are willing to
learn XEmacs internals as needed for their projects while conforming
to the style guidelines.