From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: obsolete comment in tool-bar.el Date: Fri, 15 Jul 2005 20:47:52 -0500 (CDT) Message-ID: <200507160147.j6G1lqt13574@raven.dms.auburn.edu> References: <200507071915.j67JFZT29961@raven.dms.auburn.edu> <200507090235.j692ZER04883@raven.dms.auburn.edu> <200507110321.j6B3LgG09526@raven.dms.auburn.edu> <85y88dfcqw.fsf@lola.goethe.zz> <200507130302.j6D32qE05640@raven.dms.auburn.edu> <200507140208.j6E28tr08794@raven.dms.auburn.edu> <200507141830.j6EIU5r11167@raven.dms.auburn.edu> <878y08k857.fsf-monnier+emacs@gnu.org> <200507151353.j6FDrMf12755@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1121478682 16524 80.91.229.2 (16 Jul 2005 01:51:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 16 Jul 2005 01:51:22 +0000 (UTC) Cc: rms@gnu.org, mituharu@math.s.chiba-u.ac.jp, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 16 03:51:20 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Dtbpn-0006jx-8k for ged-emacs-devel@m.gmane.org; Sat, 16 Jul 2005 03:51:19 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dtbrb-000172-GX for ged-emacs-devel@m.gmane.org; Fri, 15 Jul 2005 21:53:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Dtbr1-00015f-0N for emacs-devel@gnu.org; Fri, 15 Jul 2005 21:52:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Dtbr0-000153-1h for emacs-devel@gnu.org; Fri, 15 Jul 2005 21:52:34 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dtbqz-00014t-Va for emacs-devel@gnu.org; Fri, 15 Jul 2005 21:52:34 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Dtbv2-0000Ha-US; Fri, 15 Jul 2005 21:56:45 -0400 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id j6G1m3CK010250; Fri, 15 Jul 2005 20:48:03 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j6G1lqt13574; Fri, 15 Jul 2005 20:47:52 -0500 (CDT) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: monnier@iro.umontreal.ca In-reply-to: (message from Stefan Monnier on Fri, 15 Jul 2005 16:44:20 -0400) 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:40976 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:40976 Here is the code: ;; If the mode is global, call the function according to the default. ,(if globalp `(if (and load-file-name (not (equal ,init-value ,mode))) (eval-after-load load-file-name '(,mode (if ,mode 1 -1)))) I believe that this code definitely should be removed. What does this code do? Nothing, if the current value of the minor mode variable is equal to the standard value. That is, it does _not_ enable the mode if the standard value is t, even though the defcustom sets the minor mode variable to t, thereby introducing a bug, which the programmer using `define-minor-mode' will have to hand correct. It only does something (other than throwing unnecessary errors) if the define-minor-mode is loaded in a file and the minor mode variable has a value different from the default _and_ out of sync with the actual situation, something that can only occur if there is a bug in Emacs or a user mistake. Now what is this code _trying_ to do? To "call the function according to the default", if we are to believe the comment. That would mean that we should call the minor mode function if ,init-value is t and the minor mode variable was unbound before the defcustom got executed. So, to do what the comment says, we should replace the default :initialize for minor modes from 'custom-initialize-default to 'custom-initialize-set. Then the only effect that loading the file would have would be to establish the intended default if the user did not override that default before the file got loaded. (Note: do not confuse custom-initialize-set with the very disruptive default :initialize function custom-initialize-reset.) This would avoid both problems I pointed out with the present approach. It would still mean that define-minor-mode should not be called too soon, but only if the minor mode is to be enabled by default, which is rare for a global minor mode. Maybe, in spite of the comment, the code is _really_ trying to do what it actually does: try to bring the mode variable back in sync with the actual situation if it has gotten out of sync due to some bug. But that is a very misguided thing to do. If the source of the bug is Emacs, we should correct the bug in the code, not hide it by correcting it more or less at random in this clumsy way. If the user setq-ed the variable rather than calling the function or setting the variable through Custom, then you have to give the user the opportunity to find out that it does not work. Correcting it at random when a file gets loaded is not helping the user, but leading him into total confusion: sometimes setting the variable works, sometimes not, but then at some given moment, say when browsing Custom for unrelated reasons, it all of a sudden starts working again. Sincerely, Luc.