And round and round we go. You complain about the
documentation, I ask for clarification, you complain about
the design, I try to explain the design, you complain about
the documentation, and we go back to step 1. That's exactly
what we've been doing for years. It just isn't helpful
information for me, if I want to provide something that'll
make more sense to you. That may very well be a failing of
mine, but so there.
XEmacs can deal with the packages in a different location
from the rest just fine: that's why `emacs-roots' is a list,
and not a string. Maybe it isn't configurable in the way you
want, but the conceptual machinery is all there. Maybe
that's how we need to attack the problem.
OK, I'm going to inject my two cents in here, although I haven't read all
the latest messages entirely.
But I understand very clearly what Stephen is saying, and I agree with it.
[1] Conceptually there should be two kinds of roots: Core roots, and package
roots.
[2] A core root is a directory under which you find bin/xemacs.exe, info/*,
man/*, etc; or src/xemacs.exe, etc. in a run-from-source configuration.
[3] A package root is a directory under which you find `xemacs-packages',
`mule-packages', etc.
[4] Generally there should be one core root (I can't think of an obvious
case where there should be more than one), but potentially many package
roots.
[5] The core root is determined at runtime by some sort of magic.
[6] The set of package roots is determined at runtime by combining
some standard locations with any package roots specified using
--package-prefix, in the following order, where earlier in the
list means earlier in the load-path:
[1] ~/.xemacs
[2] [maybe] an environment variable EMACSPACKAGEPREFIX
[3] --package-prefix
[4] CORE-ROOT/lib/xemacs-VERSION
[5] CORE-ROOT/lib/xemacs
[Note that parallelism between --prefix, which specifies the core root, and
--package-prefix, which specifies the package roots.]
[7] --package-path and EMACSPACKAGEPATH should be removed, as should the
confusing concepts of "early", "late", and "last", which are
false
generality.
[8] The code should be [a] modified to work as above, [b] documented, since
most of the routines are not documented at all, [c] cleaned of all
unnecessary goop, of which there is quite a lot.
[9] The docs should be rewritten to reflect the above description.