Re: Inconsistency in meaning of "user options"

[Lennart Borgman]

Drew Adams wrote:

>    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.
>  
Why do we then have to distinguish between variables and faces? Does not 
option comprise both? If it does then I think option is a good term to 
use here.

> - If we chose to reserve "user option" for user-settable variables (those
> that have `*' as doc-string first char or are defined with defcustom), 
>  
Do I misremember, was not those going to be converted to defcustoms, or?

> 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.
>  
That would maybe be good. Perhaps could we use these terms?:

1) user options
2) custom options (to be distinguished from "Custom options" ;-)

I guess the meaning here is obvious, but just in case: 1 - those can not 
be set with Custom, 2 - those can be set with custom.