Mats Lidell writes:
>>>>> Michael Sperber <sperber(a)deinprogramm.de>
writes:
> It could be done. My point is that, at least once upon a time, there
> were people who didn't do it to be the way you want it to be. They do
> have a point in that the already complicated behavior gets more
> complicated when it's different at dump time.
I must be missing something. Why would you ever want to dump anything
else than what is in the lisp folder that you just have compiled?
That's not the point. The point is that XEmacs has a very complicated
startup that involves finding various resources that live all over the
place in a traditional FHS-like structure. This is very much
nontrivial because the Lisp engine needs to be bootstrapped before we
can call Lisp. Then we restart everything using Lisp, with a rather
complex algorithm for finding Lisp libraries that needs to be backward
compatible with systems whose file system structure was set in 1985,
as well as a large number of file system structures that were popular
in between.
Just loading what is in the build tree doesn't sound like
complicating
things to me?
It's yet another decision that doubles the complexity of what can
happen at XEmacs initialization. It means that you can build XEmacs,
and the first run of xemacs will look for resources in entirely
different places from where temacs looked. Implementation would not
be hard, I've been thinking about it. How it will affect debugging
and user support is not fun to think about, I assure you.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta