Re: [comp.emacs.xemacs] AUCTeX 11.84 released

Thorsten Bonow writes: If you're a heavy AUCTeX user, switching to GNU Emacs makes a lot of sense. It's going to support AUCTeX better, for a variety of reasons, but the killer reason is that nobody in the core of AUCTeX development uses XEmacs except to test and diagnose bugs in AUCTeX. That is very unlikely to change in the near to medium term. There is also necessarily going to be a lag, which will vary from a few days (pre-release) to couple of weeks (public release) to several months (SUMO release), between an upstream release and the release of an XEmacs package for it. Because of that lag, I just don't think it's reasonable to hope for the XEmacs package system to stay current with all of the packages in it. For packages maintained by XEmacs users, sure, it's often trivial because they'll use XEmacs CVS as the repository. But for 3rd-party packages, the XEmacs version should be considered a convenience for users new to the package, or with basic needs. (Eg, I personally don't use any of the features of AUCTeX introduced since version 9.) To take a hint from the Python jargon, we do include batteries, but not high-power alkaline ones. What I think should be done for projects like AUCTeX and ESS and even VM is to make it possible to easily get packages built by upstream from the upstream site (or another 3rd party site, for that matter). Then people who just use XEmacs packages can try the package, which might be fairly old, and if they decide they want the latest and greatest, they will have the *convenient* option to update from a 3rd party site. Much of the infrastructure for multiple download sites is there, but it's not very convenient, and for VM, ESS, and AUCTeX at least the URLs are well-known and should be queryable from our package infrastructure. The other aspect that needs improvement is bug reporting. We need to set up a generic bug reporter so issues with packages with substantial lags in release compared to upstream are *very* easy to report to XEmacs, and relatively painful to report to upstream, and the opposite should be the case for third-party distributions of packages (including upstream). Whether that would help you stay with XEmacs is up to you. But those are two areas I've been thinking about improving here. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta