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

["Drew Adams" <drew.adams@oracle.com>]

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