Re: Nuking unexec

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; wrote: While a separate dump file is preferable, from a disk space standpoint (perhaps, compressing it, too?), a private binary is fine. Disk space is cheap. ;-) You just have to make sure that the private binary can tell where the XEmacs installation is. [ Well, if you're on a multi-user system, then there may be issues ... ;-) ] Well, while a private binary isn't optimal, it's a perfectly usable solution. Given that this is -- at least initially, until we have more experience with it -- something of an "advanced feature", we probably don't need a nice interface. Here are some wild ideas, to which I've given virtually no thought ;-): * Plan A: Press a button, and the current state of the running XEmacs gets dumped (just like a real, old-fashioned lisp workspace ;-). All of it. At this point, the user can rename ~/.xemacs/init.el and try running the newly-dumped XEmacs (the normal loading of init.el and custom.el will still continue). [ I can't help but wonder if a lot of additional work is required for this. I haven't looked, but can the existing pdump code handle dumping an XEmacs with an active GUI? ] * Plan B: The user runs XEmacs in batch mode (just like today), but the contents of init.el (by default) is included in the dump. A different file other than init.el can be optionally specified. [ Virtually all of the code needed to do this should already exist. The only issue that comes to mind is if the user has added interactive code to his init.el (i.e., code that prompts him for something at startup). ] Yup. -- Darryl Okahata darrylo(a)soco.agilent.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day.