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

|--==> "SJT" == Stephen J Turnbull <stephen(a)xemacs.org&gt; writes: SJT> I think as described here it's bad design, too. The packages are SJT> intended to be a separate module from the core. Running core in-place SJT> should find the core lisp under core, but the packages must be located SJT> by other criteria. Note that packages _cannot_ run in-place, they SJT> must be installed. Installing packages into an in-place core seems SJT> more than a bit weird to me. Especially when you consider that packages don't get installed into a normally installed core anyway. SJT> I've been bitten many times by having symlinks to the packages in my SJT> core directory, I don't want that. And that is just installing-by- SJT> alias, anyway. Yep, you may as well just set XEMACS_STAGING and MULE_STAGING to the normal package path '/usr/local/lib/xemacs/[xemacs|mule]-packages/' SJT> It also seems inconsistent with features like the --package-path SJT> configure flag and the EMACSPACKAGEPATH environment variable. Agree. SJT> Finally, I have very little time to work on the packages. Nor do I SJT> want to have non-canonical packages (ie with local mods) in the SJT> environment where I test XEmacs 21.4. I imagine there are a lot of SJT> testers who feel the same way, they use the packages as is but they SJT> like to try the latest and greatest core code. This is an important SJT> specification for in-place XEmacs, IMHO. If an in-place XEmacs does SJT> not normally find my installed packages, then as far as I'm concerned, SJT> it doesn't "just work", I may as well install it. I have a nice little script that uninstalls an old XEmacs and then 'make install' on the new one. I'm very happy that I don't have to worry about the packages at all when I do this. -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|