RE: Inconsistency in meaning of "user options"

[Drew Adams]

    Sometimes we use the term "user options" to mean
    "customizable variable" or "variable meant for the user to set".
    But sometimes we use it to mean "any settings you can customize",
    which includes faces as well.

    I think we should make this consistent.  There is more than
    one way to do it; all of them will take work.
    The question is, which one is better?

We discussed this a while back, but I agree that it would be good to come to
a conclusion. Are you proposing that we discuss and decide this _now_, and
make the necessary changes before the 22.1 release?

If so, here are a few thoughts:

 - "Option" means choice. All user settings involve choice, so they are all
user options in this general sense. Another term for this is "user setting"
or simply "setting". "Option" is usually better than setting to indicate
something that can be changed at runtime.

 - If we chose to reserve "user option" for user-settable variables (those
that have `*' as doc-string first char or are defined with defcustom), then
we would have the least amount of work to do. This is because that is what
"user option" has meant, historically (with perhaps a few more recent
exceptions). In that case, since all faces are customizable, the terminology
would be: 1) "user option or face" (all), 2) "customizable user option"
(defcustom), 3) "user option" (which includes #2), and 4) "face".

 - If we decide to start from scratch, then the terms might be 1) "user
option" (all), 2) "customizable user variable", 3) "user variable" (which
includes #2), and 4) "face".

 - One problem with the previous choice is that it might not always be clear
that "user option" includes faces, especially given our legacy terminology.
If we want to be sure people understand that faces are included, we could
say "user variable or face". In that case, the only difference between the
two would be "option" vs "variable".

 - There is also the need to refer to non-user variables (all faces are
user-settable). "Internal variable" is one possibility, but some such
variables are not so internal. I would prefer "non-user variable" for this.

 - When there is a need to distinguish customizable from non-customizable
user variables (or options), those terms are sufficient: "customizable" vs
"non-customizable".


On another subject, I think it's unfortunate that the terms "customize" and
"customizable" have been appropriated for a particular kind of customization
(using Custom buffers) - especially in an editor (++) that is all about
customization (not Customization). It makes communicating about
customization much more complex and confusing. It would be a lot better if
Customize were called Foobar or Whatever.

<Heresy>
 If we rework Customize substantially for Emacs 23 (which I
 hope we do), how about renaming Customize something else?
</Heresy>

Of course, if we intend to do that, we should not decide now upon terms like
"customizable" (whateverable?).

Nested cans of worm-eating worms...