In an installed XEmacs, modules are installed in a single directory, which is architecture-specific, of course. In run-in-place, however, built modules just live under "modules", and normally in subdirectories for each modules. The find-paths.el and setup-paths.el mechanisms don't seem to be able to handle either of these differences (setup-paths doesn't recurse into subdirectories when looking for modules, and find-paths assumes that the architecture string will be part of the directory name in an architecture-specific directory, AFAICS). (But then, how does an in-place XEmacs find lib-src? I'm confused.) As a sort of contrapositive to the startup.el hoses load-path thread, this means that a module can be loaded into an XEmacs that isn't configured for it. Mike, I think Aidan's right. There is no reason other than somebody's unwillingness to set an environment variable for looking outside the source tree for core code in a run-in-place XEmacs. Package lisp will live in the package tree, and modules built outside of the source tree will live in site-modules. If you really know what you're doing, you can set environment variables to point to previous builds for the same version and architecture, but it's just too risky to do that by default. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta