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.