Jens> Sorry if this is a faq or plain stupid, but I simply seem to Jens> be unable to get an xemacs-21 beta working... I'm not all that surprised; the install process is in flux, big-time right now, especially with respect to packages. Jens> After a long time I want to again work a bit with xemacs, Jens> and so I decided to get a new package enabled xemacs-21. I Jens> downloadded the cvs xemacs-20 and xemacs-packages. OK. You don't need to get the source if you would rather just install the binaries. In fact, it is not possible to build a Mule XEmacs at present without an installed mule-base package AFAIK. Jens> I first compiled xemacs and installed, then went on tho the Jens> packages and also compiled these... but where am I supposed Jens> to install them? Do I simply link the whole structure under Jens> (prefix)/lib/xemacs/packages? That's the default path for Jens> packes if I read the docs right... The current default is for ${prefix}/lib/xemacs/packages to contain the lisp/, info/, and etc/ directories for packages. You can also put your package source in there in an appropriate directory. However, you really need to install the packages; it may someday be possible to use the packages from their source directories, but it is not at present. So keep the sources and installed lisp separate. In particular having the built sources in ${prefix}/lib/xemacs/packages/sources/xemacs-base/*.{el,elc} will lose, with or without something like a link ${prefix}/lib/xemacs/packages/lisp -> sources. (A link ${prefix}/lib/xemacs/packages/lisp -> ${somewhere}/sources will also lose.) Jens> But do I have to redump XEmacs? No. That's the whole point of packages ;-) Jens> How will it know about the packages? The following may not completely accurately reflect the latest betas, but it will give you a flavor of the idea. (Chipsy: How'd I do?) Currently XEmacs is built to look in three places: in the package hierarchy(ies) configured with `--package-path', in a fall-back installed packages hierarchy (${prefix}/lib/xemacs/packages), and in a sibling of the directory containing the executable (${bindir}/../packages), in that order. Shadowing is done by _hierarchies_, so that if the configured hierarchy is found (at run-time), XEmacs will completely ignore the other hierarchies, even if they contain Lisp libraries that the configured hierarchy does not. At run-time, the load path has several components. The first is expanded from the Lisp variable `early-packages'. This normally consists of "~/.xemacs", and each directory in this list should have the normal complement of subdirectories {lisp,info,etc}. Next come the (now-deprecated; you must use the appropriate option to configure to get this) site-lisp directory. Third comes the normal package hierarchy, expanded from a the Lisp variable `late-packages'. Fourth comes any hierarchy that must come after the late-packages, expanded from `last-packages'. Normally this is NIL. The only current application I know of is Colin Rafferty's use of 20.4 packages with 21.0. Finally, the core Lisp (most of which is dumped into XEmacs) is added. Adrian Aichner <aichner(a)ecf.teradyne.com&gt; writes: Jens> I did :-( The syntax of the package-path option has changed; the description is ./configure is clear and definitive. I can't figure out a failure mode that fits your description of what you did, but maybe you can.... Run XEmacs and see what the values of `early-packages,' `late-packages', `last-packages,' and `load-path' are.