Re: auctex/CHANGES

David> So you essentially say that starting with AUCTeX 11.81, it David> is not possible at all to create an XEmacs packaging of David> AUCTeX. Small wonder then that Uwe did not succeed in David> doing so. Not in a couple of makefile variables and targets using the current infrastructure. I'm pretty sure it could be done using a tedious and fragile rearrangement of AUCTeX's code and data, but that's not at all desirable. I then got a bad case of real life before I decided whether to try special-casing AUCTeX or whether to try to find a general solution for several important "large, self-contained" packages (but other than AUCTeX the necessary options are in place and set up). In the long run I want to permit what I call "opaque" packages, which would have a standard place to register their entry points, namely $PKGROOT/opaque-packages/$PACKAGE/auto-autoloads.{el,elc}, which would be reserved for XEmacs package use. (A bit impolite, but I don't see how else to do it.) Otherwise the package could set itself up any way it likes under that subdirectory. It could register its datadir and infodir directly in auto-autoloads or through an install-me function called from the init file, for example. Packages which would "like" this arrangement a lot include JDE and Emacsspeak, and I believe, AUCTeX. It shouldn't be that hard to do, except for the packager-oriented documentation, and functions to do the kind of consistency checks we now do in our "mandatory" structure. Both of those are likely to be tedious, and I don't understand the run-time initialization process for packages well enough yet. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.