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

Stephen> This is news to me. :-( Stephen> I think as described here it's bad design, too. The packages are Stephen> intended to be a separate module from the core. Running core in-place Stephen> should find the core lisp under core, but the packages must be located Stephen> by other criteria. Note that packages _cannot_ run in-place, they Stephen> must be installed. Installing packages into an in-place core seems Stephen> more than a bit weird to me. Stephen> I've been bitten many times by having symlinks to the packages in my Stephen> core directory, I don't want that. And that is just installing-by- Stephen> alias, anyway. Stephen> It also seems inconsistent with features like the --package-path Stephen> configure flag and the EMACSPACKAGEPATH environment variable. Stephen> Finally, I have very little time to work on the packages. Nor do I Stephen> want to have non-canonical packages (ie with local mods) in the Stephen> environment where I test XEmacs 21.4. I imagine there are a lot of Stephen> testers who feel the same way, they use the packages as is but they Stephen> like to try the latest and greatest core code. This is an important Stephen> specification for in-place XEmacs, IMHO. If an in-place XEmacs does Stephen> not normally find my installed packages, then as far as I'm concerned, Stephen> it doesn't "just work", I may as well install it. Please people, before you make sweeping judgements like this, it would be nice if you could calm down and review the issue at hand ... ... which is whether a vanilla-configured XEmacs *without* any special indication where the packages should snarf them under /usr/local. There is no correct answer to this question, as we've had bug reports from environments where this is precisely the *wrong* thing to do. If you want to pick up an installed package hierarchy that doesn't live in a fully populated XEmacs root hierarchy (which is what Michael is trying to do), I think it's it's entirely reasonable to expect an explicit hint on where the packages are, that is, either via the --package-path configure option or via the EMACSPACKAGEPATH environment variable. The reason why the scenario Michael describes used to work and doesn't work now is that XEmacs used to diagnose the "XEmacs root hierarchy" property of a directory via a different criterion. In Michael's case, it did so *wrongly* because there wasn't an XEmacs root hierarchy there, just the packages. The criterion changed at your (Stephen's, that is) suggestion, and justly so. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla