Re: Inconsistency in meaning of "user options"

[Lennart Borgman <lennart.borgman.073@student.lu.se>]

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.