The recent thread on custom settings vs. X resource vs. etc gave me the feeling that it might be time for a real discussion on what we actually want to do, and how we envision doing it. My current impression is that things are more or less mixed up in our minds because what's immediately visible is not conceptual problems, but bugs or technical stuff that doesn't work the way we expect it to work. The whole idea that I'd like to develop here could be summarized in 5 words: _setting is not like saving_. Let's look back a bit at History: 1/ We have a .emacs file. This file is read at startup and contains stuff that you would otherwise type and eval in the scratch buffer for instance. Things that you want to keep for all emacs sessions, you put them in. Fine. Putting stuff in .emacs is a form of "saving", since you don't retype everything every time. 2/ Now, obviously, this raises the idea of an "xemacs environment", the general behavior you'd like to have in all emacs sessions. Hence the options menu. However, what the original options menu was doing is not as obvious as it seems. It actually had a double role: a way to set _AND_ save variables, and I think this is very important to keep this in mind. Not only it was _saving_ for you code that you would otherwise have had in .emacs, but it was also giving you an easy way to _set_ the variables without having to write a single line of Elisp. 3/ After this, several problems arise: - some variables can't be set with a just a toggle button in a menu. - what do we consider part of the "xemacs environment" ? we can't possibly add an options menu item each time Joe Hacker writes an interesting package and wish to give the user an easy way to set some variable. And Custom was born. What's incredibly nice with custom (and the underlying widget lib) is that you have information on the /type/ of the variable you set, which means that you could potentially set *any* variable only with the mouse and leave with a (sort of) empty .emacs. At least, this is the ultimate situation you could reach. But .... Custom comes with its own and hermetic way of _saving_ the variables too. :-( 4/ Aside from this, there are the X resources. XEmacs is deeply integrated in the toolkits so why not use them for everything ? They have an impact on the value of Lisp variables. Yet another set AND save method. Incomplete this time, since if you're running in tty only, they're useless. However, you'd be tempted to set a face foreground using X because it's easy: you've already written some kind of `*foreground' somewhere in a .Xresources file, you (think) know how it works. Then, you've got this brand new color xterm and fuck, the face is white. OKay I'll just add a line in .emacs, or even better, I'll customize the face. And the mess begins. Users can't be blamed for this kind of thing. We've provided them with so many ways to set, edit, view save stuff at the same time, each way not fully functioning, ignoring the others, wanting to act as a stand-alone. IMHO, the major problem we're facing is that we didn't succeed in properly making the conceptual difference between _setting_ and _saving_ (or `remembering' if you prefer). For instance, the one thing I hate is custom saying "This option has been changed outside the customize buffer". Hell I don't care! Sometimes I'll find quicker to `set-variable' the option, or `eval-region' a piece of code or whatever. And now the value couldn't be saved anymore, unless I open a custom buffer? Those are *different* issues. To be a bit more concrete, here's a first brainstorm at the things we should think about. This assume that we make the distinction between setting and saving. * What can/should be something `savable' in XEmacs and the packages. This is already pretty well figured out. * How can we specify that such or such variable is `savable'. Currently, regardless of any redundancy like the one introduced by defcustom and friends, the star at the beginning of the doc strings does it more or less. * How can we figure out when and how a variable has been modified (different from the default value in its declaration). Maybe properties saying "value from an init file", "value from X resources", "value from user input during an xemacs session" etc. * Provide a SINGLE XEmacs generic way of saving stuff if modified. Custom or any other setting method shouldn't have anything to do with this. * If we have a powerfull setting method like Custom which needs type information, very well. But this information shouldn't be regarded as a 'custom-type. It's really the 'type of the variable. We can imagine that `set-variable' could also use this information for completion purpose or whatever. I repeat, _it has nothing to do with the method for setting_. It's a global information, potentially usefull for different things. * If one setting method is not able to position correctly one variable, let's try fixing this or just prevent setting with this method. With a single saving process, this shouldn't have dramatic consequences. * How can we detect, and warn about settings that are conflicting with each other (like an X resources on something that is also twiddled in inint.el) * etc etc etc. I hope I'm not so far in the blue sky there, and I'd like very much to see the discussion oriented this way. Thanks for reading so far :-) If you've just scrolled the buffer, you're a cheater. :-) -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19