unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#23085: 24.5; `customized-changed-options`
@ 2016-03-21 22:45 Drew Adams
  2016-03-27  0:43 ` John Wiegley
  2021-02-07 14:07 ` Lars Ingebrigtsen
  0 siblings, 2 replies; 10+ messages in thread
From: Drew Adams @ 2016-03-21 22:45 UTC (permalink / raw)
  To: 23085

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'





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#23085: 24.5; `customized-changed-options`
  2016-03-21 22:45 bug#23085: 24.5; `customized-changed-options` Drew Adams
@ 2016-03-27  0:43 ` John Wiegley
  2021-02-07 14:07 ` Lars Ingebrigtsen
  1 sibling, 0 replies; 10+ messages in thread
From: John Wiegley @ 2016-03-27  0:43 UTC (permalink / raw)
  To: Drew Adams; +Cc: 23085

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#23085: 24.5; `customized-changed-options`
  2016-03-21 22:45 bug#23085: 24.5; `customized-changed-options` Drew Adams
  2016-03-27  0:43 ` John Wiegley
@ 2021-02-07 14:07 ` Lars Ingebrigtsen
  2021-02-07 15:26   ` Eli Zaretskii
  1 sibling, 1 reply; 10+ messages in thread
From: Lars Ingebrigtsen @ 2021-02-07 14:07 UTC (permalink / raw)
  To: Drew Adams; +Cc: 23085

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#23085: 24.5; `customized-changed-options`
  2021-02-07 14:07 ` Lars Ingebrigtsen
@ 2021-02-07 15:26   ` Eli Zaretskii
  2021-02-07 18:08     ` bug#23085: [External] : " Drew Adams
                       ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Eli Zaretskii @ 2021-02-07 15:26 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 23085

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#23085: [External] : Re: bug#23085: 24.5; `customized-changed-options`
  2021-02-07 15:26   ` Eli Zaretskii
@ 2021-02-07 18:08     ` Drew Adams
  2021-02-07 20:47     ` Basil L. Contovounesios
  2021-02-08  6:05     ` Lars Ingebrigtsen
  2 siblings, 0 replies; 10+ messages in thread
From: Drew Adams @ 2021-02-07 18:08 UTC (permalink / raw)
  To: Eli Zaretskii, Lars Ingebrigtsen; +Cc: 23085@debbugs.gnu.org

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#23085: 24.5; `customized-changed-options`
  2021-02-07 15:26   ` Eli Zaretskii
  2021-02-07 18:08     ` bug#23085: [External] : " Drew Adams
@ 2021-02-07 20:47     ` Basil L. Contovounesios
  2021-02-08  6:10       ` Lars Ingebrigtsen
  2021-02-08  6:05     ` Lars Ingebrigtsen
  2 siblings, 1 reply; 10+ messages in thread
From: Basil L. Contovounesios @ 2021-02-07 20:47 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 23085

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#23085: 24.5; `customized-changed-options`
  2021-02-07 15:26   ` Eli Zaretskii
  2021-02-07 18:08     ` bug#23085: [External] : " Drew Adams
  2021-02-07 20:47     ` Basil L. Contovounesios
@ 2021-02-08  6:05     ` Lars Ingebrigtsen
  2 siblings, 0 replies; 10+ messages in thread
From: Lars Ingebrigtsen @ 2021-02-08  6:05 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 23085

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#23085: 24.5; `customized-changed-options`
  2021-02-07 20:47     ` Basil L. Contovounesios
@ 2021-02-08  6:10       ` Lars Ingebrigtsen
  2021-02-08 15:15         ` Eli Zaretskii
  0 siblings, 1 reply; 10+ messages in thread
From: Lars Ingebrigtsen @ 2021-02-08  6:10 UTC (permalink / raw)
  To: Basil L. Contovounesios; +Cc: 23085

"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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#23085: 24.5; `customized-changed-options`
  2021-02-08  6:10       ` Lars Ingebrigtsen
@ 2021-02-08 15:15         ` Eli Zaretskii
  2021-02-09  7:20           ` Lars Ingebrigtsen
  0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2021-02-08 15:15 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: contovob, 23085

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#23085: 24.5; `customized-changed-options`
  2021-02-08 15:15         ` Eli Zaretskii
@ 2021-02-09  7:20           ` Lars Ingebrigtsen
  0 siblings, 0 replies; 10+ messages in thread
From: Lars Ingebrigtsen @ 2021-02-09  7:20 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: contovob, 23085

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2021-02-09  7:20 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-21 22:45 bug#23085: 24.5; `customized-changed-options` Drew Adams
2016-03-27  0:43 ` John Wiegley
2021-02-07 14:07 ` Lars Ingebrigtsen
2021-02-07 15:26   ` Eli Zaretskii
2021-02-07 18:08     ` bug#23085: [External] : " Drew Adams
2021-02-07 20:47     ` Basil L. Contovounesios
2021-02-08  6:10       ` Lars Ingebrigtsen
2021-02-08 15:15         ` Eli Zaretskii
2021-02-09  7:20           ` Lars Ingebrigtsen
2021-02-08  6:05     ` Lars Ingebrigtsen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).