RE: toolbar conventions

["Drew Adams" <drew.adams@oracle.com>]

       In January, some people argued for "preference".  We could use that.
       Or perhaps "setting".  What do people think of those?  Any other
       suggestions?

    "setting" would work.

I was the one who mentioned those two terms, but I did not (and I don't
think anyone else did) really argue that we should adopt them. I simply
pointed them out as common terms.

_If_ we decided that we needed another, more general term to encompass both
options (user variables) and faces, then we might adopt such a term.
However, that would just require us to explain one more name, with little
gain in clarity. Remember the view-mode "quit" vs "leave" vs "exit" vs...
fiasco: if we have multiple, similar terms (e.g. option + preference), we
will be constantly explaining.

Also, both "setting" and "preference" have a connotation of persistence,
because only saved preferences are available in most other apps (where those
terms have been used).

I think "option" and "face" are good terms for what they stand for
currently. "User variable" is clearer than "option", but "option" is clear
enough, IMO. ("User option" is redundant, BTW.) This terminology has worked
well in the past, and would continue to do so. I see no real need for a term
that refers to "option or face" - that expression is clear enough and short
enough.

It is of course the _value_ of a variable or the _values_ of a face's
parameters, not the variable or face, that are truly the settings,
preferences, or options, but I think that that is a distinction we need not
make.

    The simple alternative "option or face" is not
    even _that_ long

I agree. It's a good way to refer to such things.

    and in certain contexts one can even just use option
    and rely on the fact that it is clear from the context that in this
    particular case it applies to faces too.

We should avoid that. We gain nothing by it, and we lose clarity. If we
decide to stick with "option" for a user variable, then we should avoid
employing it in a different sense.

And to repeat what I said before: We should not change the terminology
before this release - we should just make sure that "option" means user
variable everywhere (that is, make only corrections, no sea change). We can
revisit the terminology after or along with any changes we might decide to
make to Customize for the next (23) release.

In particular, as has been discussed, we are pretty much in a box now wrt
the common term "customize" (and "customization" etc.) - we are forced to
restrict its use to apply only to Customize. That's not good, but we have no
choice at this point (for this release).

If we do end up making substantial changes to Customize in a future release
(which I hope), we can then see if we also want to try to revisit the
terminology at that point. Then, in the context of Customize, it might make
sense to speak of "settings" or "preferences" (in place of
"customizations"), since Customize has an implied notion of persistence.