GNU bug report logs - #23085
24.5; `customized-changed-options`

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "23085 <at> debbugs.gnu.org" <23085 <at> debbugs.gnu.org>
Subject: bug#23085: [External] : Re: bug#23085: 24.5; `customized-changed-options`
Date: Sun, 7 Feb 2021 18:08:38 +0000

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.