[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 has b
From: |
Stefan Monnier |
Subject: |
Re: toggling a minor mode should not tell Customize that the value has been set |
Date: |
Sun, 06 Jan 2008 11:16:37 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux) |
>> 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
- toggling a minor mode should not tell Customize that the value has been set, Drew Adams, 2008/01/05
- Re: toggling a minor mode should not tell Customize that the value has been set, Stefan Monnier, 2008/01/05
- Re: toggling a minor mode should not tell Customize that the value has been set, martin rudalics, 2008/01/06
- RE: toggling a minor mode should not tell Customize that the value has been set, Drew Adams, 2008/01/06
- Re: toggling a minor mode should not tell Customize that the value has been set, Stefan Monnier, 2008/01/06
- Re: toggling a minor mode should not tell Customize that the value has been set, martin rudalics, 2008/01/07
- Re: toggling a minor mode should not tell Customize that the value has been set, Richard Stallman, 2008/01/07
Re: toggling a minor mode should not tell Customize that the value has been set, Richard Stallman, 2008/01/06