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