Re: find-paths.el and run-in-place

>>>>> "Michael Sperber [Mr. Preprocessor]" <sperber(a)informatik.uni-tuebingen.de&gt; >> many environments and ways I never envisioned. It certainly >> was part of my intention that, if you run in-place, you run This is news to me. :-( >> *everything* in-place, and I feel qualified to say that your >> being able to run in this split setup is mere accident. I think as described here it's bad design, too. The packages are intended to be a separate module from the core. Running core in-place should find the core lisp under core, but the packages must be located by other criteria. Note that packages _cannot_ run in-place, they must be installed. Installing packages into an in-place core seems more than a bit weird to me. I've been bitten many times by having symlinks to the packages in my core directory, I don't want that. And that is just installing-by- alias, anyway. It also seems inconsistent with features like the --package-path configure flag and the EMACSPACKAGEPATH environment variable. Finally, I have very little time to work on the packages. Nor do I want to have non-canonical packages (ie with local mods) in the environment where I test XEmacs 21.4. I imagine there are a lot of testers who feel the same way, they use the packages as is but they like to try the latest and greatest core code. This is an important specification for in-place XEmacs, IMHO. If an in-place XEmacs does not normally find my installed packages, then as far as I'm concerned, it doesn't "just work", I may as well install it. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.