* toggling a minor mode should not tell Customize that the value has been set @ 2008-01-05 17:48 Drew Adams 2008-01-06 2:14 ` Stefan Monnier 2008-01-06 10:46 ` Richard Stallman 0 siblings, 2 replies; 16+ messages in thread From: Drew Adams @ 2008-01-05 17:48 UTC (permalink / raw) To: Emacs-Devel `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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: toggling a minor mode should not tell Customize that the value has been set 2008-01-05 17:48 toggling a minor mode should not tell Customize that the value has been set Drew Adams @ 2008-01-06 2:14 ` Stefan Monnier 2008-01-06 8:01 ` Drew Adams 2008-01-06 10:46 ` Richard Stallman 1 sibling, 1 reply; 16+ messages in thread From: Stefan Monnier @ 2008-01-06 2:14 UTC (permalink / raw) To: Drew Adams; +Cc: Emacs-Devel > `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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: toggling a minor mode should not tell Customize that the value has been set 2008-01-06 2:14 ` Stefan Monnier @ 2008-01-06 8:01 ` Drew Adams 2008-01-06 16:16 ` Stefan Monnier 0 siblings, 1 reply; 16+ messages in thread From: Drew Adams @ 2008-01-06 8:01 UTC (permalink / raw) To: Stefan Monnier; +Cc: Emacs-Devel > > `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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: toggling a minor mode should not tell Customize that the value has been set 2008-01-06 8:01 ` Drew Adams @ 2008-01-06 16:16 ` Stefan Monnier 2008-01-06 20:47 ` Drew Adams 0 siblings, 1 reply; 16+ messages in thread From: Stefan Monnier @ 2008-01-06 16:16 UTC (permalink / raw) To: Drew Adams; +Cc: Emacs-Devel >> 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: toggling a minor mode should not tell Customize that the value has been set 2008-01-06 16:16 ` Stefan Monnier @ 2008-01-06 20:47 ` Drew Adams 2008-01-06 21:20 ` Stefan Monnier 2008-01-06 22:41 ` martin rudalics 0 siblings, 2 replies; 16+ messages in thread From: Drew Adams @ 2008-01-06 20:47 UTC (permalink / raw) To: Stefan Monnier; +Cc: Emacs-Devel > >> 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: toggling a minor mode should not tell Customize that the value has been set 2008-01-06 20:47 ` Drew Adams @ 2008-01-06 21:20 ` Stefan Monnier 2008-01-06 23:00 ` Drew Adams 2008-01-06 22:41 ` martin rudalics 1 sibling, 1 reply; 16+ messages in thread From: Stefan Monnier @ 2008-01-06 21:20 UTC (permalink / raw) To: Drew Adams; +Cc: Emacs-Devel > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: toggling a minor mode should not tell Customize that the value has been set 2008-01-06 21:20 ` Stefan Monnier @ 2008-01-06 23:00 ` Drew Adams 2008-01-07 1:32 ` Stefan Monnier 0 siblings, 1 reply; 16+ messages in thread From: Drew Adams @ 2008-01-06 23:00 UTC (permalink / raw) To: Stefan Monnier; +Cc: Emacs-Devel > > 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: toggling a minor mode should not tell Customize that the value has been set 2008-01-06 23:00 ` Drew Adams @ 2008-01-07 1:32 ` Stefan Monnier 0 siblings, 0 replies; 16+ messages in thread From: Stefan Monnier @ 2008-01-07 1:32 UTC (permalink / raw) To: Drew Adams; +Cc: Emacs-Devel >> 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: toggling a minor mode should not tell Customize that the value has been set 2008-01-06 20:47 ` Drew Adams 2008-01-06 21:20 ` Stefan Monnier @ 2008-01-06 22:41 ` martin rudalics 2008-01-06 23:41 ` Drew Adams 1 sibling, 1 reply; 16+ messages in thread From: martin rudalics @ 2008-01-06 22:41 UTC (permalink / raw) To: Drew Adams; +Cc: Stefan Monnier, Emacs-Devel > 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: toggling a minor mode should not tell Customize that the value has been set 2008-01-06 22:41 ` martin rudalics @ 2008-01-06 23:41 ` Drew Adams 2008-01-07 1:26 ` Stefan Monnier ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Drew Adams @ 2008-01-06 23:41 UTC (permalink / raw) To: martin rudalics; +Cc: Stefan Monnier, Emacs-Devel > > 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: toggling a minor mode should not tell Customize that the value has been set 2008-01-06 23:41 ` Drew Adams @ 2008-01-07 1:26 ` Stefan Monnier 2008-01-07 7:34 ` martin rudalics 2008-01-07 11:31 ` Richard Stallman 2 siblings, 0 replies; 16+ messages in thread From: Stefan Monnier @ 2008-01-07 1:26 UTC (permalink / raw) To: Drew Adams; +Cc: martin rudalics, Emacs-Devel >> > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: toggling a minor mode should not tell Customize that the value has been set 2008-01-06 23:41 ` Drew Adams 2008-01-07 1:26 ` Stefan Monnier @ 2008-01-07 7:34 ` martin rudalics 2008-01-07 11:31 ` Richard Stallman 2 siblings, 0 replies; 16+ messages in thread From: martin rudalics @ 2008-01-07 7:34 UTC (permalink / raw) To: Drew Adams; +Cc: Stefan Monnier, Emacs-Devel > 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: toggling a minor mode should not tell Customize that the value has been set 2008-01-06 23:41 ` Drew Adams 2008-01-07 1:26 ` Stefan Monnier 2008-01-07 7:34 ` martin rudalics @ 2008-01-07 11:31 ` Richard Stallman 2 siblings, 0 replies; 16+ messages in thread From: Richard Stallman @ 2008-01-07 11:31 UTC (permalink / raw) To: Drew Adams; +Cc: rudalics, monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: toggling a minor mode should not tell Customize that the value has been set 2008-01-05 17:48 toggling a minor mode should not tell Customize that the value has been set Drew Adams 2008-01-06 2:14 ` Stefan Monnier @ 2008-01-06 10:46 ` Richard Stallman 2008-01-06 16:19 ` toggling a minor mode should not tell Customize that the value hasbeen set Drew Adams 1 sibling, 1 reply; 16+ messages in thread From: Richard Stallman @ 2008-01-06 10:46 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: toggling a minor mode should not tell Customize that the value hasbeen set 2008-01-06 10:46 ` Richard Stallman @ 2008-01-06 16:19 ` Drew Adams 2008-01-07 17:15 ` Richard Stallman 0 siblings, 1 reply; 16+ messages in thread From: Drew Adams @ 2008-01-06 16:19 UTC (permalink / raw) To: rms; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: toggling a minor mode should not tell Customize that the value hasbeen set 2008-01-06 16:19 ` toggling a minor mode should not tell Customize that the value hasbeen set Drew Adams @ 2008-01-07 17:15 ` Richard Stallman 0 siblings, 0 replies; 16+ messages in thread From: Richard Stallman @ 2008-01-07 17:15 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2008-01-07 17:15 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-01-05 17:48 toggling a minor mode should not tell Customize that the value has been set Drew Adams 2008-01-06 2:14 ` Stefan Monnier 2008-01-06 8:01 ` Drew Adams 2008-01-06 16:16 ` Stefan Monnier 2008-01-06 20:47 ` Drew Adams 2008-01-06 21:20 ` Stefan Monnier 2008-01-06 23:00 ` Drew Adams 2008-01-07 1:32 ` Stefan Monnier 2008-01-06 22:41 ` martin rudalics 2008-01-06 23:41 ` Drew Adams 2008-01-07 1:26 ` Stefan Monnier 2008-01-07 7:34 ` martin rudalics 2008-01-07 11:31 ` Richard Stallman 2008-01-06 10:46 ` Richard Stallman 2008-01-06 16:19 ` toggling a minor mode should not tell Customize that the value hasbeen set Drew Adams 2008-01-07 17:15 ` Richard Stallman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.