bug#23085: 24.5; `customized-changed-options`

bug#23085: 24.5; `customized-changed-options`

[Drew Adams]

This name should not be an alias for `customize-changed'.  The doc
string for that command says clearly that it "includes new user options
and faces, and new customization groups, as well as older options and
faces".  It is NOT about only options.  And the doc string combined with
the unfortunate name is quite confusing.

On the other hand, there should be separate commands that do the same
thing as `customize-changed' but for ONLY options and ONLY faces.

IOW, we SHOULD have a `customize-changed-options' and a
customize-changed-faces', but the former should NOT be an alias for
`customize-changed'.



In GNU Emacs 24.5.1 (i686-pc-mingw32)
 of 2015-04-11 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/usr --host=i686-pc-mingw32'

bug#23085: 24.5; `customized-changed-options`

[John Wiegley]

>>>>> Drew Adams <drew.adams@oracle.com> writes:

> This name should not be an alias for `customize-changed'. The doc string for
> that command says clearly that it "includes new user options and faces, and
> new customization groups, as well as older options and faces". It is NOT
> about only options. And the doc string combined with the unfortunate name is
> quite confusing.

> On the other hand, there should be separate commands that do the same thing
> as `customize-changed' but for ONLY options and ONLY faces.

> IOW, we SHOULD have a `customize-changed-options' and a
> customize-changed-faces', but the former should NOT be an alias for
> `customize-changed'.

I agree, Drew.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

bug#23085: 24.5; `customized-changed-options`

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

> This name should not be an alias for `customize-changed'.  The doc
> string for that command says clearly that it "includes new user options
> and faces, and new customization groups, as well as older options and
> faces".  It is NOT about only options.  And the doc string combined with
> the unfortunate name is quite confusing.
>
> On the other hand, there should be separate commands that do the same
> thing as `customize-changed' but for ONLY options and ONLY faces.
>
> IOW, we SHOULD have a `customize-changed-options' and a
> customize-changed-faces', but the former should NOT be an alias for
> `customize-changed'.

The alias was introduced here:

commit bba50f8a9e697263139b19872ee0cc8f0e46b317
Author:     Richard M. Stallman <rms@gnu.org>
AuthorDate: Fri Dec 23 01:34:27 2005 +0000

    (customize-changed-options-previous-release): Prev release is 21.1.
    (customize-changed-options): Doc fix.
    (customize-changed): New alias.

And the doc string for customize-changed-options was changed to reflect
what it does, i.e., what you'd expect `customize-changed' to do.

This is kinda backwards, so I've now flipped this, and made
`customize-changed-options' an obsolete alias.  We could consider adding
a new `customize-changed-options' command that just list user options,
but it doesn't really seem that useful.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#23085: 24.5; `customized-changed-options`

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 07 Feb 2021 15:07:54 +0100
> Cc: 23085@debbugs.gnu.org
> 
>     (customize-changed-options-previous-release): Prev release is 21.1.
>     (customize-changed-options): Doc fix.
>     (customize-changed): New alias.
> 
> And the doc string for customize-changed-options was changed to reflect
> what it does, i.e., what you'd expect `customize-changed' to do.
> 
> This is kinda backwards, so I've now flipped this, and made
> `customize-changed-options' an obsolete alias.

I'm not sure this change is for the better: no one said that "options"
should be interpreted narrowly as referring only to variables; and
"customize-changed" is simply bad English and doesn't help
understanding what it is about.  So I think Richard was right with
that change.

bug#23085: [External] : Re: bug#23085: 24.5; `customized-changed-options`

[Drew Adams]

> no one said that "options"
> should be interpreted narrowly as referring only to variables; and
> "customize-changed" is simply bad English and doesn't help
> understanding what it is about.  So I think Richard was right with
> that change.

* What does `M-x customize-option' do?
* What does `M-x apropos-user-option' do?

Such commands are an important way in which
Emacs talks about itself and communicates with
users.

I can, however, agree that Emacs is somewhat
inconsistent wrt terminology about user settings.
I think the inconsistency has been brought in
over time, in one or both directions.

The greatest inconsistency is that the Emacs
manual glossary entry for "User Option" says that
it is a face or a variable.

There was at least one general discussion about
such terminology in emacs-devel a number of years
back (I don't have a reference, sorry).  In that
discussion I argued that we should have both:

1. A term for all such user settings.  I proposed
"preference" or even "setting".

2. A term for just user variables, custom variables,
or what is most commonly called "option" by Emacs.

A face setting is just as optional as an "option"
setting - on that I agree.  "Option" isn't the best
possible term for a customizable variable (but at
least it's short, unlike "customizable variable").

Something like "user variable" is also ambiguous.
A name that refers to Customize in some way helps,
but it can be longer than what we often want to use.

I'd favor more consistent use of terminology,
and a reconsideration of "option" is possible in
that context.  But we need a term for #2, as well as
#1, and we don't really have either consistently.

And then there's the weight of history, and the
existence of commands etc. whose names use such
terms.  If there's a real attempt to fix the
terminology inconsistency in the help and doc,
then it might be easier to not also need to change
command, other function, and variable names to
reflect such a terminology fix/change.
__

There are yet other kinds of user settings, which
could be considered in this context, including:

1. frame parameters
2. property values on symbols (e.g. command
   symbols)
___

As far as this bug goes, I think that, unless we
really do make the terminology consistent
throughout, this bug should be fixed as requested.
If we do then, at some point, update and harmonize
the terminology then there might be multiple such
names to change.  At least this bug fix aligns
this name with the rest of Customize (commands
such as `customize-option'etc.).

bug#23085: 24.5; `customized-changed-options`

[Basil L. Contovounesios]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Sun, 07 Feb 2021 15:07:54 +0100
>> Cc: 23085@debbugs.gnu.org
>> 
>>     (customize-changed-options-previous-release): Prev release is 21.1.
>>     (customize-changed-options): Doc fix.
>>     (customize-changed): New alias.
>> 
>> And the doc string for customize-changed-options was changed to reflect
>> what it does, i.e., what you'd expect `customize-changed' to do.
>> 
>> This is kinda backwards, so I've now flipped this, and made
>> `customize-changed-options' an obsolete alias.
>
> I'm not sure this change is for the better: no one said that "options"
> should be interpreted narrowly as referring only to variables; and
> "customize-changed" is simply bad English and doesn't help
> understanding what it is about.  So I think Richard was right with
> that change.

I agree, but mostly just wanted to say that if customize-changed-options
is renamed, then its occurrences in code, docstrings, and the manual
should be updated, and the rename should probably be called out in NEWS.

Thanks,

-- 
Basil

bug#23085: 24.5; `customized-changed-options`

[Lars Ingebrigtsen]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> I agree, but mostly just wanted to say that if customize-changed-options
> is renamed, then its occurrences in code, docstrings, and the manual
> should be updated, and the rename should probably be called out in NEWS.

Definitely; I plumb forgot.  (But Eli seems to think the change should
be reverted (and I have no strong opinion one way or another, so we'll
go with whatever he wants here, and I'm not doing so right now until
that's clarified.)

But this bit in the manual should be fixed in any case:

-----
@item M-x customize-changed @key{RET} @var{version} @key{RET}
Set up a customization buffer with all the settings and groups
whose meaning has changed since Emacs version @var{version}.

@item M-x customize-changed-options @key{RET} @var{version} @key{RET}
Set up a customization buffer with all the options whose meaning or
default values have changed since Emacs version @var{version}.
-----

Which is wrong in any case, since they are aliases of each other.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#23085: 24.5; `customized-changed-options`

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  23085@debbugs.gnu.org
> Date: Mon, 08 Feb 2021 07:10:03 +0100
> 
> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
> 
> > I agree, but mostly just wanted to say that if customize-changed-options
> > is renamed, then its occurrences in code, docstrings, and the manual
> > should be updated, and the rename should probably be called out in NEWS.
> 
> Definitely; I plumb forgot.  (But Eli seems to think the change should
> be reverted

No, ignore me on that one: I thought the change was in the opposite
direction.

> -----
> @item M-x customize-changed @key{RET} @var{version} @key{RET}
> Set up a customization buffer with all the settings and groups
> whose meaning has changed since Emacs version @var{version}.
> 
> @item M-x customize-changed-options @key{RET} @var{version} @key{RET}
> Set up a customization buffer with all the options whose meaning or
> default values have changed since Emacs version @var{version}.
> -----
> 
> Which is wrong in any case, since they are aliases of each other.

Right.

bug#23085: 24.5; `customized-changed-options`

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Definitely; I plumb forgot.  (But Eli seems to think the change should
>> be reverted
>
> No, ignore me on that one: I thought the change was in the opposite
> direction.

OK, I've now finished up the change.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#23085: 24.5; `customized-changed-options`

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm not sure this change is for the better: no one said that "options"
> should be interpreted narrowly as referring only to variables; and
> "customize-changed" is simply bad English and doesn't help
> understanding what it is about.  So I think Richard was right with
> that change.

Richard added the (perhaps oddly named) `customize-changed' alias,
though.

I have no strong opinions about this, but we do usually refer to
defcustom'd variables as "user options", so it doesn't seem unreasonable
for a user to expect that `customize-changed-options' will list only
"user options" -- that seems like a natural expectation in this context,
even if "options" has a wider meaning outside a Customize context.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no