Re: the role of Custom in XEmacs (setting != saving)
Didier Verna <verna(a)inf.enst.fr> writes:
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.
The same thing holds for custom. It is actually 4 things
1. An enhanced "weak" typing system.
2. A saving system.
3. A setting system.
4. A UI to this setting system.
Parts 1 and 2 work quite well, apart from the face stuff because you
need to decide what to save with more complex settings like faces.
`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.
The big problem is: What do you mean by "setting".
1. The _user_ setting this variable? consciously?
2. _any_ change to the variable.
Custom tries to do 1. "This option ... outside the customize buffer"
means: "It is changed but I am not sure the user did this".
* 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.
That's exactly what the customize properties are:
'saved-value = "value from an init file"
'customized-value = "value from user input during an xemacs session"
* Provide a SINGLE XEmacs generic way of saving stuff if modified.
The custom save variables stuff is fine.
Custom
or any other setting method shouldn't have anything to do with
this.
Custom is not a setting method. It is _also_ a setting method.
* 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.
Indeed. So who cares that the property is called. custom-type is
perfectly allright. There is no reason set-variable shouldn't use it
(and even update 'customized-value too??). One could also think of
implementing a very fancy completing method for the value part of setq
in elisp-modes 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. :-)
I think you just missed what custom is all about. Customize is a
saving and typing method.
As a "reference implementation" has made a newbie friendly setting
method on top of it (cus-edit.el). However it is by no means the only
one, see the XEmacs options menu.
All (or almost all ) the discussions about the face stuff has been
about Customize as a saving method.
Jan