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. _______________________________________________ auctex-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/auctex-devel
