Re: Loading startup changes load-path?
[Taking up an old thread about the handling of the search paths during
build of XEmacs.]
>>>> Michael Sperber <sperber(a)deinprogramm.de>
writes:
Mats Lidell <matsl(a)xemacs.org> writes:
>>>>>> Michael Sperber
<sperber(a)deinprogramm.de> writes:
>>
>>> It is intentional, to some degree: A long time ago, people screamed
>>> bloody murder at me when the startup paths didn't give configure'd
>>> paths precedence over those determined at run time. startup.el is just
>>> the first file that knows about those paths. So there's no good
>>> solution here that will make everybody happy, I'm afraid.
>>
>> But this happens while building the dump. What ever happens when you
>> start your xemacs is another thing I think. Couldn't this behavior be
>> controlled some how so that when building the dump we don't do this?
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.
Could we have two different modes? The idea being that it could be
easier to check a state and do something different and leave the old
code untouched.
One mode would be the legacy one that does all the bells and whistles
to be smart to figure out where the user has his elisp files just as
it is done today.
The other mode would during build time just use el-files in the
sources.
Couldn't just startup.el look for this state and behave differently? I
mean we could still dump the startup code that does this test so it is
not a catch-22 thing or am I missing something here?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta