Didier Verna <verna(a)inf.enst.fr> writes:
 information with what we have now ? For instance, it might be
 interesting to have more details on the origin of the saved value: 
My themes stuff has to do that anyway. There isn't a real reason you
could consider, f.e., your Xresources as a special king of "theme". We can
discuss this in Tsukuba. 
 user init file (I consider it to be a saving), user option file, X
 resource ... or even 'variable-type. It implicitely states that it
 is for custom, and hides the fact that any other package or variable
 modification method could use it. 
Ok. You have a point there. I think this can be solved with a little
marketing :-). 
 Personaly, I'm not very much for set-variable acting like custom.
 It's important to have a method for setting a variable that you KNOW
 you won't want to save. However, custom is missing a set-variable
 equivalent, that wouldn't need to display a heavy graphical
 interface. 
Indeed. However that's simply because nobody has written it yet. A
first implementation could be a trivial cut&paste job from set-variable.
 Footnotes: 
 [1]  It's completely off-topic, but in France, there's a debate on
 feminization of several words describing professions for instance.
 Historically, some professions were reserved for men which explains why
 nowadays we lack many feminin equivalents. 
This is solved in Holland (in job advertisements etc) by appending a
(v/m) to the name, for female/male. So have. "We are looking for a
painter(f/m)". It works good enough for the discussion to have more or 
less died down. However you can not use that solution since it comes
from Holland :-).
The problem is really worse with "secretary" as there the male and
female forms mean two different professions nowadays!
secretaresse (female form) = typing, answering telephone etc..
  As in "I'll ask my secretary to make an appointment.
sectretaris (male form) = Managing assistant
  As in "Secretary of State".
So now you can have a male secretaresse for a female secretaris!
Jan