Inconsistency in meaning of "user options"

Inconsistency in meaning of "user options"

[Richard M. Stallman]

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?

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...

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.

RE: Inconsistency in meaning of "user options"

[Drew Adams]

    > - "Option" means choice.

    Why do we then have to distinguish between variables and faces?

Because faces didn't exist when the term was coined for Emacs.

    Does not option comprise both? If it does then I think option
    is a good term to use here.

Yes, that's what I said in the second alternative I proposed ("starting from
scratch").

    > - 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?

Even if that were decided, it would not affect existing external libraries.
The terminology we adopt should (also) address the case of non-customizable
user variables. They exist; they will continue to exist in the future,
unless we neuter `*'. Personally, I see nothing wrong with them, except that
their existence adds more confusion to the Customize/customize mix.

    > 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.

No, the meaning is not obvious, at least in American English. Something that
is "custom" (e.g. a "custom motorcycle") is something that _has been_
customized. The term to use for customizable is "customizable", not
"custom".

It's also not clear to me what you gain by changing "Custom" to "custom", if
your meaning of "custom" is "Custom" (can be set with Custom). My point was
precisely to find some term that is different from "custom", to avoid
confusion.

Re: Inconsistency in meaning of "user options"

[Lennart Borgman]

Drew Adams wrote:

>    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.
>
>No, the meaning is not obvious, at least in American English. Something that
>is "custom" (e.g. a "custom motorcycle") is something that _has been_
>customized. The term to use for customizable is "customizable", not
>"custom".
>  
>
Oh thanks, it is a bit hard with a foreign language. I would expect an 
option that had been changed to be called "customized" perhaps, but not 
"custom".

easy-customizable option, e-customizable option? (it is more a joke...), 
custom-customizable option - too long, custom-enabled option, 
custom-setable option, defcustom option - we actually use this sometimes 
and I like it. But can the normal user understand that term? 
custom-enabled seems better to me then, but I do not know what that 
alludes to for you native english speakers.

>It's also not clear to me what you gain by changing "Custom" to "custom", if
>your meaning of "custom" is "Custom" (can be set with Custom). My point was
>precisely to find some term that is different from "custom", to avoid
>confusion.
>
It was just a joke. I suppose "Custom option" would mean one of those 
that you use to change the behaviour of Custom with.

RE: Inconsistency in meaning of "user options"

[Drew Adams]

    > Something that
    > is "custom" (e.g. a "custom motorcycle") is something that _has been_
    > customized. The term to use for customizable is "customizable", not
    > "custom".

    Oh thanks, it is a bit hard with a foreign language. I would expect an
    option that had been changed to be called "customized" perhaps, but not
    "custom".

"Customized" is correct; so is "custom". "Custom" is often used
colloquially, especially for hobby things (cars, bikes...).

    I suppose "Custom option" would mean one of those
    that you use to change the behaviour of Custom with.

I've been looking for those options! So much to change...

Re: Inconsistency in meaning of "user options"

[Richard M. Stallman]

    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?

Yes.  These are problems in changes that I've made since Emacs 21,
and we should fix them before it goes out.

Re: Inconsistency in meaning of "user options"

[Richard M. Stallman]

    >No, the meaning is not obvious, at least in American English. Something that
    >is "custom" (e.g. a "custom motorcycle") is something that _has been_
    >customized. The term to use for customizable is "customizable", not
    >"custom".
    >  
    >
    Oh thanks, it is a bit hard with a foreign language. I would expect an 
    option that had been changed to be called "customized" perhaps, but not 
    "custom".

"Custom" as an adjective means "specialized for one party".  The
motorcycle may have been made to your own specifications; if so, it is
a custom motorcycle, but it was not customized.  It was custom-made.

To "customize" an existing thing means to "change it to be special for
one party".  Thus, we speak about "customizing Emacs".

To say a thing is "customized" means that it "has been changed to be
special for one party."

To say a thing is "customizable" means it can be changed to be special
for one party.