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 15:00:56 -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 1199660482 22646 80.91.229.12 (6 Jan 2008 23:01:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 6 Jan 2008 23:01:22 +0000 (UTC) Cc: Emacs-Devel To: "Stefan Monnier" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 07 00:01:43 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 1JBeUw-00057r-3k for ged-emacs-devel@m.gmane.org; Mon, 07 Jan 2008 00:01:42 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JBeUZ-0000UL-9H for ged-emacs-devel@m.gmane.org; Sun, 06 Jan 2008 18:01:19 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JBeUU-0000Q2-SL for emacs-devel@gnu.org; Sun, 06 Jan 2008 18:01:14 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JBeUU-0000P2-3x for emacs-devel@gnu.org; Sun, 06 Jan 2008 18:01:14 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JBeUU-0000On-03 for emacs-devel@gnu.org; Sun, 06 Jan 2008 18:01:14 -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 1JBeUT-0003Jw-Oc for emacs-devel@gnu.org; Sun, 06 Jan 2008 18:01:14 -0500 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m06N1AVN010704; Sun, 6 Jan 2008 17:01:11 -0600 Original-Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m06FGBdW008122; Sun, 6 Jan 2008 16:01:10 -0700 Original-Received: from dhcp-amer-csvpn-gw2-141-144-72-69.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 3480026691199660452; Sun, 06 Jan 2008 15:00:52 -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:86406 Archived-At: > > 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.