OK, we need to create a design document for all of this, including: PRINCIPLE #1: Whenever you have auto-generated stuff, *CLEARLY* indicate this in comments around the stuff. These comments get searched for, and used to locate the existing generated stuff to replace. Custom currently doesn't do this. PRINCIPLE #2: Currently, lots of functions want to add code to the .emacs. (e.g. I get prompted for my mail address from add-change-log-entry, and then prompted if I want to make this permanent). There needs to be a Lisp API for working with arbitrary code to be added to a user's startup. This API hides all the details of which file to put the fragment in, where in it, how to mark it with magical comments of the right kind so that previous fragments can be replaced, etc. PRINCIPLE #3: *ALL* generated stuff should be loaded before any user-written init stuff. This way the user can override the generated settings. Although in the case of customize, it may work when the custom stuff is at the end of the init file, it surely won't work for arbitrary code fragments (which typically do `setq' or the like). PRINCIPLE #4: As much as possible, generated stuff should be place in separate files from non-generated stuff. Otherwise it's inevitable that some corruption is going to result. PRINCIPLE #5: Packages are encouraged, as much as possible, to work within the customize model and store all their customizations there. However, if they really need to have their own init files, these files should be placed in .xemacs/, given normal names (e.g. saved-abbrevs.el not .abbrevs), and there should be some magic comment at the top of the file that causes it to get automatically loaded while loading a user's init file. (Alternatively, the above-named API could specify a function that lets a package specify that they want such-and-such file loaded from the init file, and have the specifics of this get handled correctly.) OVERARCHING GOAL: The overarching goal is to provide a unified mechanism for packages to store state and setting information about the user and what they were doing when XEmacs exited, so that the same or a similar environment can be automatically set up the next time. In general, we are working more and more towards being a truly GUI app where users' settings are easy to change and get remembered correctly and consistently from one session to the next, rather than requiring nasty hacking in elisp. Hrvoje, do you have any interest in this? How about you, Martin? This seems like it might be up your alley. This stuff has been ad-hocked since kingdom come, and it's high time that we make this work properly so that it could be relied upon, and a lot of things could "just work". Jan Vroonhof wrote: -- Ben In order to save my hands, I am cutting back on my mail. I also write as succinctly as possible -- please don't be offended. If you send me mail, you _will_ get a response, but please be patient, especially for XEmacs-related mail. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding. See also http://www.666.com/ben/typing.html.