auctex/CHANGES

[Stephen J. Turnbull]

>>>>> "David" == David Kastrup <dak at gnu.org> writes:

    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.