From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: toggling a minor mode should not tell Customize that the value has been set Date: Sun, 6 Jan 2008 12:47:23 -0800 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1199652457 30002 80.91.229.12 (6 Jan 2008 20:47:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 6 Jan 2008 20:47:37 +0000 (UTC) Cc: Emacs-Devel To: "Stefan Monnier" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 06 21:47:58 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JBcPV-00023g-Qs for ged-emacs-devel@m.gmane.org; Sun, 06 Jan 2008 21:47:58 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JBcP8-00070H-Ug for ged-emacs-devel@m.gmane.org; Sun, 06 Jan 2008 15:47:35 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JBcP4-00070C-BC for emacs-devel@gnu.org; Sun, 06 Jan 2008 15:47:30 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JBcP3-000700-1v for emacs-devel@gnu.org; Sun, 06 Jan 2008 15:47:29 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JBcP2-0006zx-Ro for emacs-devel@gnu.org; Sun, 06 Jan 2008 15:47:28 -0500 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JBcP2-0008Pv-8c for emacs-devel@gnu.org; Sun, 06 Jan 2008 15:47:28 -0500 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m06KlQKn023232; Sun, 6 Jan 2008 14:47:26 -0600 Original-Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m06KlORI010169; Sun, 6 Jan 2008 13:47:25 -0700 Original-Received: from 141.144.88.62 by acsmt351.oracle.com with ESMTP id 3479954631199652440; Sun, 06 Jan 2008 12:47:20 -0800 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:86391 Archived-At: > >> 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.