toggling a minor mode should not tell Customize that the value has been set

toggling a minor mode should not tell Customize that the value has been set

[Drew Adams]

`define-minor-mode' adds this code to the definition of every minor mode:

(if (called-interactively-p)
    (progn
      ,(if globalp `(customize-mark-as-set ',mode)) ; <=== WHY?
      ;; Avoid overwriting a message shown by the body,
      ;; but do overwrite previous messages.
      (unless (and (current-message)
                   (not (equal ,last-message
                               (current-message))))
        (message ,(format "%s %%sabled" pretty-name)
                 (if ,mode "en" "dis")))))

This means that if you so much as toggle a global minor mode, and you later
use `customize-customized' to see which options you have edited and set, the
minor mode variable shows up in the list of customized options.

This is wrong, IMO. Toggling a global minor mode should simply change the
variable's current value; it should not also tell Customize to set that
value (or tell it that the value has been set).

What was the rationale behind this behavior? Why should toggling
`iswitchb-mode' or `icicle-mode' tell Customize that the user has customized
the mode variable?

A user should be able to use `customize-customized' (including perhaps in
`kill-emacs-query-functions') to see what s?he has customized and might want
to save. It is unlikely that a global minor mode variable is in this
category, and if it is, it should only be the use of Customize that counts
for this, not merely toggling the mode.

Re: toggling a minor mode should not tell Customize that the value has been set

[Stefan Monnier]

> `define-minor-mode' adds this code to the definition of every minor mode:
> (if (called-interactively-p)
>     (progn
>       ,(if globalp `(customize-mark-as-set ',mode)) ; <=== WHY?

Because M-x foo-mode RET on such global minor-modes isn't much different
from M-x customize-variable RET foo-mode RET .... -> Set for current session.

> What was the rationale behind this behavior? Why should toggling

The rationale is that Custom does not like it when Elisp code modifies
a defcustom behind its back.

If we don't do it, then Custom will simply tell you that the variable
was set outside of Custom and that saving the var may hence not have
the expected effect.

> A user should be able to use `customize-customized' (including perhaps in
> `kill-emacs-query-functions') to see what s?he has customized and might want
> to save.

Exactly, after trying our M-x iswtchb-mode RET she may very much like to
see that iswitchb-mode is now eabled and that she could save it so that
it's enabled next time around.


        Stefan

RE: toggling a minor mode should not tell Customize that the value has been set

[Drew Adams]

> > `define-minor-mode' adds this code to the definition of every
> > minor mode:
> > (if (called-interactively-p)
> >     (progn
> >       ,(if globalp `(customize-mark-as-set ',mode)) ; <=== WHY?
>
> Because M-x foo-mode RET on such global minor-modes isn't much different
> from M-x customize-variable RET foo-mode RET .... -> Set for
> current session.

"isn't much different"  How so? What do you mean by that?

Obviously, if the code calls `customize-mark-as-set' then they are similar.
But _why_ should they be treated similarly? That is the question.

Logically and a priori, it isn't much the _same_, I'd say.

> > What was the rationale behind this behavior? Why should toggling
>
> The rationale is that Custom does not like it when Elisp code modifies
> a defcustom behind its back.

Modifies a defcustom? What does that mean?

Changing the value of a variable that happens to be defined by defcustom is
not the same thing as setting it by Customize or for Customize. And it
shouldn't be the same thing.

Why should toggling a minor mode be tantamount to customizing its variable?

And if it should for some reason, then why distinguish between global and
local modes in this regard?

> If we don't do it, then Custom will simply tell you that the variable
> was set outside of Custom and that saving the var may hence not have
> the expected effect.

But that's what happened: the value was changed outside Customize.

If you ask Customize for what was changed outside Customize, this variable
should show up. But if you ask Customize for what was customized but not
saved (`customize-customized'), this should not show up.

At least that's the way it seems to me. You haven't given any argument to
the contrary that might change my mind. Why should toggling a mode variable
be considered the same as customizing it?

> > A user should be able to use `customize-customized' (including
> > perhaps in `kill-emacs-query-functions') to see what s?he has
> > customized and might want to save.
>
> Exactly, after trying our M-x iswtchb-mode RET she may very much like to
> see that iswitchb-mode is now eabled and that she could save it so that
> it's enabled next time around.

"May?" This design is based only on that _possibility_?

Why assume that about what the user wants? Why not let the user decide? If
that is what s?he wants, s?he can simply use Customize to set anything that
s?he might later want to save.

It think it is far more likely that someone will toggle a mode on and off
occasionally, without that action implying that s?he would want to save its
last value.

A toggle is, well, a toggle - something designed to be turned on and off -
and often more than once. If a mode variable were simply a boolean
preference that one sets once and for all, then there would be no need for a
command to toggle it.

I expect that we will see more and more use of global minor modes (as well
as local ones) in the future, and I think (at least until I see a good
argument to the contrary) that this automatic customizing behavior is
obstructive - simply not TRT.

WDOT? Does this sound like a good idea to you? To me it seems very wrong.

Re: toggling a minor mode should not tell Customize that the value has been set

[Stefan Monnier]

>> Because M-x foo-mode RET on such global minor-modes isn't much different
>> from M-x customize-variable RET foo-mode RET .... -> Set for
>> current session.
> "isn't much different"  How so? What do you mean by that?

It has the same user-visible effect of enabling/disabling the mode in
the current session.

> But _why_ should they be treated similarly? That is the question.

Because they have the same effect in all other respects.

> Logically and a priori, it isn't much the _same_, I'd say.

In which way is it different?

>> > What was the rationale behind this behavior? Why should toggling
>> 
>> The rationale is that Custom does not like it when Elisp code modifies
>> a defcustom behind its back.

> Modifies a defcustom? What does that mean?

"Modifies a variable that's defined via defcustom".

> Changing the value of a variable that happens to be defined by defcustom is

Right, so you did understand ;-)

> Why should toggling a minor mode be tantamount to customizing its variable?

You mean "when done interactively"?
Well that's what this thread is trying to explain, isn't it?

> And if it should for some reason, then why distinguish between global and
> local modes in this regard?

Simple: local modes are not defined via defcustom.

>> If we don't do it, then Custom will simply tell you that the variable
>> was set outside of Custom and that saving the var may hence not have
>> the expected effect.
> But that's what happened: the value was changed outside Customize.

Who says?

> If you ask Customize for what was changed outside Customize, this variable
> should show up.  But if you ask Customize for what was customized but not
> saved (`customize-customized'), this should not show up.

Why?  What would be the benefit?

> Why should toggling a mode variable be considered the same as
> customizing it?

Again, because "they have the same effect in all other respects".

>> > A user should be able to use `customize-customized' (including
>> > perhaps in `kill-emacs-query-functions') to see what s?he has
>> > customized and might want to save.
>> 
>> Exactly, after trying our M-x iswtchb-mode RET she may very much like to
>> see that iswitchb-mode is now eabled and that she could save it so that
>> it's enabled next time around.

> "May?" This design is based only on that _possibility_?

No.  It was in response to some request.  I can't remember the details
of it, but I can assure you that it wouldn't have crossed my mind to do
that if it weren't for someone complaining about the "changed outside
Customize".

> It think it is far more likely that someone will toggle a mode on and off
> occasionally, without that action implying that s?he would want to save its
> last value.

Nobody complained about this behavior since it was introduced (in
Emacs-21 IIRC), so I don't know about "far more likely" or about the
importance of this detail.


        Stefan

RE: toggling a minor mode should not tell Customize that the value has been set

[Drew Adams]

> >> Because M-x foo-mode RET on such global minor-modes isn't much
> >> different from M-x customize-variable RET foo-mode RET .... ->
> >> Set for current session.
> >
> > "isn't much different"  How so? What do you mean by that?
>
> It has the same user-visible effect of enabling/disabling the mode in
> the current session.

No, that's not all it does - it has more effect. Setting the variable in
Customize also customizes it: adds it to what `customize-customized'
returns. That's an additional user-visible effect beyond simply changing its
value.

> > But _why_ should they be treated similarly? That is the question.
>
> Because they have the same effect in all other respects.

No, not if the code doesn't use `customize-mark-as-set'. That produces an
additional effect.

(setq foo-mode (not foo-mode)) has the "same effect in all other respects",
but it does not also tell Customize that the user has customized the
variable.

Treat toggling the mode variable like a simple assignment, and there is no
problem. It is the extra Customize semantics that are currently added to
toggling that are inappropriate.

> > Logically and a priori, it isn't much the _same_, I'd say.
>
> In which way is it different?

Simply assigning the variable with `setq' "has the same user-visible effect
of enabling/disabling the mode in the current session".

The toggle code, in addition, changes the meaning of the variable for
Customize. That is neither necessary for nor a consequence of
"enabling/disabling the mode in the current session." It is gratuitous - an
extra effect that doesn't belong.

> >> > What was the rationale behind this behavior? Why should toggling
> >>
> >> The rationale is that Custom does not like it when Elisp code modifies
> >> a defcustom behind its back.
>
> > Why should toggling a minor mode be tantamount to customizing
> > its variable?
>
> You mean "when done interactively"?
> Well that's what this thread is trying to explain, isn't it?

I haven't seen any explanation. You've simply said, as support, that
toggling the variable enables/disables the mode for the session.

Enabling/disabling the mode has nothing to do with Customize. Enabling or
disabling, whether interactively or by program, does not imply that the
value change should be considered a change for Customize. What is the
rationale for connecting the two?

> >> If we don't do it, then Custom will simply tell you that the variable
> >> was set outside of Custom and that saving the var may hence not have
> >> the expected effect.
> >
> > But that's what happened: the value was changed outside Customize.
>
> Who says?

Uh, `M-x foo-mode'. No relation with using Customize.

The user need not do that inside a Customize buffer. A Customize buffer need
not even be open at the time.

And even if that were done in a Customize buffer, it is not an act of using
the Customize UI to set the variable value. There is simply no logical
connection.

> > If you ask Customize for what was changed outside Customize,
> > this variable should show up.  But if you ask Customize for what was
> > customized but not saved (`customize-customized'), this should not
> > show up.
>
> Why?  What would be the benefit?

There is no logical connection - no reason to couple them. Or at least you
haven't given any.

Benefit: If you use `customize-customized' on `kill-emacs-query-functions',
and you never use the Customize UI during your session, nothing happens. You
just exit Emacs, without Emacs asking you if you want to open Customize to
see stuff you customized but didn't save. And you don't need to answer yes,
just to find out that the only thing Customize thought you had customized
was `foo-mode'.

> > Why should toggling a mode variable be considered the same as
> > customizing it?
>
> Again, because "they have the same effect in all other respects".

See above. They do not. Changing the value of the mode variable has nothing,
logically, to do with Customize. The code couples the two together
inappropriately.

> >> > A user should be able to use `customize-customized' (including
> >> > perhaps in `kill-emacs-query-functions') to see what s?he has
> >> > customized and might want to save.
> >>
> >> Exactly, after trying our M-x iswtchb-mode RET she may very
> >> much like to see that iswitchb-mode is now eabled and that she
> >> could save it so that it's enabled next time around.
>
> > "May?" This design is based only on that _possibility_?
>
> No.  It was in response to some request.  I can't remember the details
> of it, but I can assure you that it wouldn't have crossed my mind to do
> that if it weren't for someone complaining about the "changed outside
> Customize".

That's what "changed outside Customize" is for. That's the way Customize is
designed.

People have sometimes complained about "changed outside Customize" in
general. I am one, in fact, who thinks that in some cases Customize should
be led to treat an outside change as if it were made by the user inside
Customize.

But this is not such a case: toggles are for toggling - toggling a variable
is not tantamount to customizing it.

> > It think it is far more likely that someone will toggle a mode
> > on and off occasionally, without that action implying that s?he
> > would want to save its last value.
>
> Nobody complained about this behavior since it was introduced (in
> Emacs-21 IIRC), so I don't know about "far more likely" or about the
> importance of this detail.

"Nobody complained before" is the last refuge. So I get the prize for being
first, so what? You haven't given one argument why setting a mode variable
outside Customize should be treated the same as editing and setting it
inside Customize.

Try adding `customize-customized' to your `kill-emacs-query-functions' to
check for unsaved customizations, and see how long it takes until you are
annoyed by this unnecessary coupling.

Putting `customize-customized' on `kill-emacs-query-functions' is analogous
to Emacs telling you that you have unsaved modified buffers, and asking if
you want to quit anyway and lose your changes. Toggling a mode variable is
not an act of customization; there is no loss if you exit without saving the
latest value.

Re: toggling a minor mode should not tell Customize that the value has been set

[Stefan Monnier]

> I haven't seen any explanation. You've simply said, as support, that
> toggling the variable enables/disables the mode for the session.

OK, let's take a step back:

  There are currently only two options: either toggling the mode
  interactively causes the var to be "changed outside Customize" or it
  marks it as "Customized".

The current code chooses the second and you advocate the first.
The problem with the first is that it's a catch-all case: it just says
"this has been changed somehow and we have no clue whatsoever what it
means, how it was done, whether it'll occur again in the future, and hence
Customize doesn't know what effect will result from changing and/or
saving this variable.  For all Customize knows, the value might already
have changed between the time Customize read it to display it and the
time the user gets to see the displayed value".

In contrast, when the user interactively does M-x foo-mode RET, we know
that this has been done in a way that Customize can easily understand
and which does not affect its ability o make further changes and/or save
the variable.  Calling it customize-mark-as-set is a way to better
interact with Customize.

For that reason, the first option is *wrong*: it loses
valuable information about how the minor mode was changed.

In my mind "customize-customized" returns the list of defcustom
variables that were changed in a principled way.  Period.
If you want to distinguish more finely between "principled" and "via
Custom", go ahead, but I doubt the benefits are worth the trouble.


        Stefan

RE: toggling a minor mode should not tell Customize that the value has been set

[Drew Adams]

> > I haven't seen any explanation. You've simply said, as support, that
> > toggling the variable enables/disables the mode for the session.
>
> There are currently only two options: either toggling the mode
> interactively causes the var to be "changed outside Customize" or it
> marks it as "Customized".
>
> The current code chooses the second and you advocate the first.

Yes. The first is exactly what happens if you simply use `setq' (or
`set-variable', for that matter). It is also what happens if you change any
other user option outside Customize. I gave the example of
`Buffer-menu-sort-column' (assuming a defcustom definition).

> The problem with the first is that it's a catch-all case: it just says
> "this has been changed somehow and we have no clue whatsoever what it
> means, how it was done, whether it'll occur again in the future, and hence
> Customize doesn't know what effect will result from changing and/or
> saving this variable.  For all Customize knows, the value might already
> have changed between the time Customize read it to display it and the
> time the user gets to see the displayed value".

Yes. Changing the value outside Customize is not customizing it. Simply
doing that should not tell Customize anything, other than that the variable
was changed. Why? Because that's all that happened.

> In contrast, when the user interactively does M-x foo-mode RET, we know
> that this has been done in a way that Customize can easily understand
> and which does not affect its ability o make further changes and/or save
> the variable.  Calling it customize-mark-as-set is a way to better
> interact with Customize.

You could say the same thing for any assignment to any user option outside
of Customize, interactive or not. Why not have all code and every command
that changes a user option set `customize-mark-as-set' to let Customize know
that it has been customized? Why not change `set-variable' so it too does
that?

Why not? Because the variable has _not_ been Customized - simple as that.

I was the first to suggest that we do that, in fact, as a general policy. As
long as we do not, however, we should do it only for specific, documented
cases where it really makes sense.

You might have a command, for instance, that edits a face, and you might
want your command to also tell Customize that the face has been customized
(not just edited, but also set). You could do that, provided you made it
clear in the doc string that the command not only edits but also customizes
faces. You could even write a command that not only edits and sets but also
saves - provided the doc string makes that clear.

But a minor-mode variable is the _last_ variable we should do that for.

If we do it for _all_ outside changes, systematically, I say fine. Bring
them all inside, so that Customize is integrated fully with Emacs - no
outside or inside. I proposed that, but it was not accepted.

As long as that is not the policy, as long as outside != inside, minor mode
variables should not be treated any differently from other user options.

It's not simply because a command _can_ tell Customize that a variable has
been customized that it _should_. What is the reason why command `foo-mode'
should tell Customize that variable `foo-mode' has been set inside
Customized?

> For that reason, the first option is *wrong*: it loses
> valuable information about how the minor mode was changed.

Why is it important for Customize to know that the minor-mode variable was
changed by calling the minor-mode command? Why bring Customize into it at
all? It has no business being involved with changing such a variable, except
within its UI.

We obviously disagree about what is "*wrong*". To me, it is wrong for
Customize to treat toggling a variable as customizing it. Toggling a
variable is not establishing its latest value as a user preference. Toggling
is intended as a back-and-forth, not as a set-with-an-eye-toward-saving.

> In my mind "customize-customized" returns the list of defcustom
> variables that were changed in a principled way.  Period.
> If you want to distinguish more finely between "principled" and "via
> Custom", go ahead, but I doubt the benefits are worth the trouble.

I have no idea what that means, and I'm not sure you do either.

I don't know what's in your mind, but `customize-customized' opens Customize
on all options that you customized during the session. The doc string says
this: "Customize all user options set in this session but not saved."
Period.

"Set" here can only mean set for Customize, since (setq toto 4) does not
affect `customize-customized' wrt user option `toto'. And `M-x foo-mode'
does not set the mode variable within Customize; it does so from the
outside.

Simply changing the value of a user option, whether interactively or not,
does not set the value for Customize. You've introduced an exception.

Even `set-variable', which is about as close to customizing as a command
gets without being a Customize command, does not set the value for
Customize.

`M-x set-variable toto 4', then `M-x customize-customized', displays the
message "No unsaved customizations (faces or variables)". Which is exactly
correct. And if you then do `M-x customize-option toto', the Customize UI
says "this option has been changed outside the customize buffer." Which is
also exactly correct.

`M-x foo-mode' should behave the same way. Your argument, that because
command `foo-mode' _can_ tell Customize that the variable has been
customized it _should_, applies equally to `set-variable': It could also
tell that to Customize, but it doesn't. And it shouldn't.

There are commands that do that explicitly: `customize-set-value' and
`customize-set-variable'. And nothing stops anyone from writing more
commands that do that (hopefully with appropriate doc). But there is no
reason that toggling a minor mode should do it.

Re: toggling a minor mode should not tell Customize that the value has been set

[Stefan Monnier]

>> In contrast, when the user interactively does M-x foo-mode RET, we know
>> that this has been done in a way that Customize can easily understand
>> and which does not affect its ability o make further changes and/or save
>> the variable.  Calling it customize-mark-as-set is a way to better
>> interact with Customize.

> You could say the same thing for any assignment to any user option outside
> of Customize, interactive or not.

No, you couldn't.  The fact that you can't is at the very core of the
existence of the status "set outside Customize".  That's also why the
call to customize-mark-as-set is only done if the minor mode function is
called interactively.

Your failure to understand the above is probably at the origin of your
desire to change the behavior.

Depending on how the assignment takes place, Customize can't do anything
with it: modifying the variable back to some other value may not
actually take effect (because the offending setq may be on
a post-command-hook, for example and hence resets the var right after
Customize changed it), saving the var may also fail to take effect next
time we start Emacs (because the offending `setq' is run later on in the
.emacs file), ...


        Stefan

Re: toggling a minor mode should not tell Customize that the value has been set

[martin rudalics]

 > Putting `customize-customized' on `kill-emacs-query-functions' is analogous
 > to Emacs telling you that you have unsaved modified buffers, and asking if
 > you want to quit anyway and lose your changes. Toggling a mode variable is
 > not an act of customization; there is no loss if you exit without saving the
 > latest value.

There is.  Suppose you have done "set for current session only" and some
action changes this to "CHANGED outside Customize; operating on it here
may be unreliable".  When you now exit Emacs you will _not_ get warned
that you have unsaved customizations.

RE: toggling a minor mode should not tell Customize that the value has been set

[Drew Adams]

>  > Putting `customize-customized' on `kill-emacs-query-functions'
>  > is analogous to Emacs telling you that you have unsaved modified
>  > buffers, and asking if you want to quit anyway and lose your
>  > changes. Toggling a mode variable is not an act of customization;
>  > there is no loss if you exit without saving the latest value.
>
> There is.  Suppose you have done "set for current session only" and some
> action changes this to "CHANGED outside Customize; operating on it here
> may be unreliable".  When you now exit Emacs you will _not_ get warned
> that you have unsaved customizations.

Fair enough. Would you then change all commands that change option values so
that they too tell Customize that the value has been customized? Would you
somehow make sure that not only commands but all Lisp code does the same
thing?

If not, then the problem you raise remains for every option other than a
minor-mode variable. No - it remains even for a minor-mode variable, except
when it is toggled via its mode command.

What is special about toggling a minor mode in this respect? Why is it an
exception? That is the question.

Making a minor-mode toggle command do this does not take care of the general
issue you raise, in any case. And if a user is really worried about the
scenario you raise, then s?he can use `customize-rogue' instead of
`customize-customized' in the hook.

Re: toggling a minor mode should not tell Customize that the value has been set

[Stefan Monnier]

>> > Putting `customize-customized' on `kill-emacs-query-functions'
>> > is analogous to Emacs telling you that you have unsaved modified
>> > buffers, and asking if you want to quit anyway and lose your
>> > changes. Toggling a mode variable is not an act of customization;
>> > there is no loss if you exit without saving the latest value.
>> 
>> There is.  Suppose you have done "set for current session only" and some
>> action changes this to "CHANGED outside Customize; operating on it here
>> may be unreliable".  When you now exit Emacs you will _not_ get warned
>> that you have unsaved customizations.

> Fair enough.  Would you then change all commands that change option
> values so that they too tell Customize that the value has been
> customized?

Yes, I think they should, whenever possible.

> Would you somehow make sure that not only commands but all
> Lisp code does the same thing?

The "whenever possible" is key.


        Stefan

Re: toggling a minor mode should not tell Customize that the value has been set

[martin rudalics]

 > Fair enough. Would you then change all commands that change option values so
 > that they too tell Customize that the value has been customized? Would you
 > somehow make sure that not only commands but all Lisp code does the same
 > thing?

No.  I wouldn't use `customize-unsaved' in `kill-emacs-query-functions'.
At least I wouldn't do that if I exited Emacs more often than once a
week.

 > Making a minor-mode toggle command do this does not take care of the general
 > issue you raise, in any case. And if a user is really worried about the
 > scenario you raise, then s?he can use `customize-rogue' instead of
 > `customize-customized' in the hook.

My *Customize Rogue* buffer is _large enough_ with Emacs -Q.  I'm just
trying to get rid of its `menu-bar-mode' entry.

Re: toggling a minor mode should not tell Customize that the value has been set

[Richard Stallman]

    Fair enough. Would you then change all commands that change option values so
    that they too tell Customize that the value has been customized? Would you
    somehow make sure that not only commands but all Lisp code does the same
    thing?

That approach (all or none) is basically mistaken.

Anyway, there's no point spending more time discussing this; I've told
you the decision.

Re: toggling a minor mode should not tell Customize that the value has been set

[Richard Stallman]

    This means that if you so much as toggle a global minor mode, and you later
    use `customize-customized' to see which options you have edited and set, the
    minor mode variable shows up in the list of customized options.

I think this was done deliberately to make the interaction with Custom
smoother.  Otherwise Custom would say it was "changed outside of
Custom" and it would make users worry.

RE: toggling a minor mode should not tell Customize that the value hasbeen set

[Drew Adams]

>     This means that if you so much as toggle a global minor mode,
>     and you later use `customize-customized' to see which options
>     you have edited and set, the minor mode variable shows up in
>     the list of customized options.
>
> I think this was done deliberately to make the interaction with Custom
> smoother.  Otherwise Custom would say it was "changed outside of
> Custom" and it would make users worry.

Yes, that's what I assumed. I think that's a mistake. It has the result that
users see such changes show up with `customize-customized', even for simple
toggles. Toggling a minor-mode variable does not mean "customizing" it.

Here's an analogy (no, it's not the same thing; it's an analogy):

`Buffer-menu-sort-column' is a defvar, but it could be a defcustom. (In
fact, in my code it is, and I think it should be generally, so that users
can specify their preferred sort column without using setq or defvar.)

Change it to a defcustom, hypothetically. Now, what's the Customize behavior
if a user clicks a column header or two a few times to change sort orders
dynamically? Customize thinks (correctly) that the value was changed outside
Customize. The user has not tried to _customize_ the value, to change its
value as a preference, and that's what Customize thinks also.

If the user (perhaps as part of `kill-emacs-query-functions') calls
`customize-customized', s?he is not told that `Buffer-menu-sort-column' was
customized ("set"). That's a good thing. It is _not_ a likely candidate for
saving - the user did not set it using Customize.

That same behavior should be available for minor mode variables. As long as
there is a distinction between changing an option's value outside Customize
and changing (setting) its value inside Customize, variables such as
`Buffer-menu-sort-column' and toggles should not be automatically customized
whenever you change them.

I would agree that it can be appropriate for some commands to automatically
customize (i.e. "set") options when run outside Customize. And it might be
appropriate for some options to be automatically customized whenever they
are set outside Customize. But clicking a sort column header and toggling a
minor mode do not fall into that category, IMO.

You might remember that I was the first one (perhaps the only one) who
argued that Customize should be made to play better with Emacs, in
particular by having changes that you make outside Customize be reflected
inside it, so Customize recognizes them, just as if you had made them inside
Customize. That means automatically "setting" any option that is changed in
any way.

That idea was not accepted. OK. As long as there is a difference between
"changed outside" and "set" (inside), `customize-customized' should not
identify variables such as minor modes and `Buffer-menu-sort-column' as
having been "customized". These are things that are designed to be changed
multiple times during a session, without such change signifying a change in
preferred default value. If a user wants to then set or even save such a
change with Customize, it is easy enough to do.

Re: toggling a minor mode should not tell Customize that the value hasbeen set

[Richard Stallman]

    Yes, that's what I assumed. I think that's a mistake. It has the result that
    users see such changes show up with `customize-customized', even for simple
    toggles.

I just don't think that is a problem.

    `Buffer-menu-sort-column' is a defvar, but it could be a defcustom. (In
    fact, in my code it is, and I think it should be generally, so that users
    can specify their preferred sort column without using setq or defvar.)

    Change it to a defcustom, hypothetically. Now, what's the Customize behavior
    if a user clicks a column header or two a few times to change sort orders
    dynamically?

I think that is not really analogous.  `Buffer-menu-sort-column' is a
local variable and you are changing it only for one buffer.  That is why
that outcome feels wrong.

Please let's drop the subject.  We have other issues to spend time on.