Michael Sperber [Mr. Preprocessor] writes:
>>>> "Stephen" == Stephen J Turnbull
<turnbull(a)sk.tsukuba.ac.jp> writes:
Stephen> XEmacs in the middle of building itself should not be
able to find
Stephen> my package hierarchy.)
Sure it should be---that part hasn't changed.
Well, maybe it hasn't changed, but there's something wrong if _at
build time_ core Lisp gets shadowed by stuff in the packages. And
whether it has changed or not, the explicit statement about the
load-path being used by loadup.el in my beta.err is at best extremely
misleading.
IMO, an XEmacs in the process of building should by default trust
nothing outside of the core Lisp directories. There should be a
"more-dumped-lisp.el" file which is either created by a human or by
./configure. All stuff from outside the core that gets dumped should
go into that file. It should contain nothing but explicit loads with
full pathnames, although if human has a lot of such stuff to dump, he
might be lazy and add some stuff to load-path.
After it gets dumped, the load-path should be reported again.
`more-dumped-lisp.el's contents should be reported in Installation.
I don't have time to implement this :(, but that's what I'd do if I did.
Historically, it's specifically for the dumped-lisp stuff.
(BTW:
you can at least delete the EFS dumped-lisp ...)
OK. I'll look at doing the same for vc. With auto-autoloads, dumping
is purely a speed optimization.
Look in dump-paths.el, it's pretty explicit. Are you saying an
earlier version didn't load that file from packages?
Yes. Because it's (a) not supposed to be in packages at all now, and
(b) it never got loaded in 21.1. It's one of the evil Mule non-ISO-
2022-charset support files that got moved out of the core for a while,
then got moved back in.
So, I never built in an environment sufficiently hosed to pick it up
from packages before. Normally the only shadow I permit is vc over
vc-cc. This shadow I didn't notice because on that box I've only
built 21.1, so it didn't get reported.
Vietnamese is one of the few languages that has no ISO-2022 compatible
encodings at all. It is supported by a truly ugly hack in 21.2, which
probably doesn't matter any more. I intend to let viet*.el die of
obsolescence when we get decent Unicode support, unless somebody more
aggressive than I decides to euthanize it sooner.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."