I wrote:
> It's clear I did the wrong thing in conditionalizing the
saves.
> For variables that are settable by command line option, the
> saves/restores should be unconditional, and the conditional
> initialization should be moved to the declaration.
>>>> "Gunnar" == Gunnar Evermann
<ge204(a)eng.cam.ac.uk> writes:
Gunnar> Wouldn't it be easier to move the command line parsing for
Gunnar> the relvant variable after the loading of the dump file?
Gunnar> This would be more like the initialisation in a
Gunnar> traditional dumped xemacs.
Most command line parsing is either done that way or doesn't involve
Lisp variables.
The problem with these variables is that they could theoretically
affect the dump process. noninteractive (-batch) is definitely used
in the dump process; that had better get unstomped. I could imagine
somebody wanting to dump packages and make sure they weren't shadowed
by development versions in ~/.xemacs or debug paths in the dump process.
It's probably easier to just protect the variables rather than figure
out whether we want to support these things or document how they're
not supported.
Also, they can't just be moved around; they have to be moved en bloc
or the sort order changed. That's not a reason not to do it, just
something we have to remember to deal with.
Gunnar> Also I think the save&restore changes the semantics as
Gunnar> changes to the variables made in the lisp executed before
Gunnar> dumping are unconditionally tossed.
If it does, it changes them to what users expect, and what is
documented.
I think this pretty much covers everything? Patch forthcoming (maybe
two days) unless somebody else wants to take it.
--
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."