Ralf> In XEmacs 21.5 the variable names for package hierarchies Ralf> were changed from {early,late,last}-packages to Ralf> {early,late,last}-package-hierarchies. The source file (lisp/packages.el) is explicitly labelled "internal" (in the keywords) and the commentary discusses how it has to work in a bare temacs. Mike Sperber would be definitive on this, but I would say that stuff is very internal, and any code that relies on interfaces in that file is taking a risk. Ralf> AUCTeX looks for the old variable names in its build Ralf> procedure and fails when being configured with XEmacs 21.5 Ralf> due to the change of names. Why are you doing this? Maybe we need to "export" those interfaces. (Maybe we need a modern LISP or Scheme.... :-( ) -- 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.

Ralf> AUCTeX looks for the old variable names in its build Ralf> procedure and fails when being configured with XEmacs 21.5 Ralf> due to the change of names. David> In order to find a good place to install a package into. Those variables are not designed for that and such use is likely to cause trouble on occasion, because they can be affected by environment variables (specifically EMACSPACKAGEPATH). FWIW, my personal recommendation is "don't do that; it is the admin's responsibility". I gather you think it is a good idea, though, so be prepared for bugs where (1) the admin uses an XEmacs with a different build-time setting of --package-path or --package-prefix from ordinary users, or sets EMACSPACKAGEPATH differently from everybody else, or (2) the user has a personal build of XEmacs or EMACSPACKAGEPATH setting that differs from from admin's. These bugs need not result in failure to find AUCTeX; they may also manifest in any way that occurs when there are multiple AUCTeXs on `load--path', if that turns out to be the case. -- 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.

On Mon, 2006-01-30 at 08:21 +1000, Steve Youngs wrote: It's not that simple, depending of course on exactly what one wants to support. For example, many distributions patch the above to $prefix/share/xemacs/[...].

* Ville Skyttä <scop(a)xemacs.org&gt; writes: This might be a little kludgey, but there's always `config-value'... ,----[ C-h f config-value RET ] | `config-value' is a compiled Lisp function | -- loaded from "config" | (config-value CONFIG-SYMBOL) | | Documentation: | Return the value of the configuration parameter CONFIG_SYMBOL. `---- See `config-value-file' for the symbols you can look up. -- |---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---| | I am Dyslexic of Borg. | | Fusistance is retile. Your arse will be laminated. | |------------------------------------&lt;steve(a)sxemacs.org&gt;---|

Ralf> But isn't using {early,late,last}-packages more robust than Ralf> using `config-value'? No, as you've already found out. Ralf> By using {early,late,last}-packages we can rely on XEmacs to Ralf> sort out (non-)existent directories and don't have to fiddle Ralf> with those manually. It's not a good idea to rely on internals; we reserve the right to break those interfaces. It's true that the functionality will continue to be present in some form, but exactly what is unspecified, as long as anybody who changes it makes sure everything in core still works correctly. I don't have a good solution for you. One of the reasons that we're revising these APIs is specifically to move toward a world in which XEmacs knows where its components are all the time. I'm paraphrasing Mike Sperber who's done most of the work on this. Note, those aren't his words and this isn't consensus policy; I'm just trying to clarify what's happening as I understand it, so you can understand too. -- 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.

Ralf Angeli <angeli(a)iwi.uni-sb.de&gt; writes: By definition, all the "paths" in the system are wrong for auto-determining where to install, because they're, well, paths, not directories. At best, they make good choices to display in a menu for the user to select. In any case, given the present infrastructure, I believe the user does have to make an explicit decision about where to install. (I'm sorry changing those names broke what you're doing in AUCTeX---I did grep through the entire package hierarchy for any possible clients, and at the time, nobody was using it.) -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla