[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Drew Adams
Subject: RE: toggling a minor mode should not tell Customize that the value hasbeen set
Date: Sun, 6 Jan 2008 08:19:24 -0800

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]