From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: obsolete comment in tool-bar.el Date: Fri, 15 Jul 2005 16:44:20 -0400 Message-ID: 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 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1121461172 6600 80.91.229.2 (15 Jul 2005 20:59:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 15 Jul 2005 20:59:32 +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 Fri Jul 15 22:59:29 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DtXHF-0007Jc-UR for ged-emacs-devel@m.gmane.org; Fri, 15 Jul 2005 22:59:22 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DtXJ3-0005pa-BC for ged-emacs-devel@m.gmane.org; Fri, 15 Jul 2005 17:01:13 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DtXGw-00059j-5c for emacs-devel@gnu.org; Fri, 15 Jul 2005 16:59:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DtXGm-00056U-6K for emacs-devel@gnu.org; Fri, 15 Jul 2005 16:58:56 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DtXGk-0004ud-Eq for emacs-devel@gnu.org; Fri, 15 Jul 2005 16:58:50 -0400 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DtXB8-0001Y8-UD; Fri, 15 Jul 2005 16:53:03 -0400 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 1592C2CF5C7; Fri, 15 Jul 2005 16:44:25 -0400 (EDT) Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id E55674AC00A; Fri, 15 Jul 2005 16:44:21 -0400 (EDT) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id CDBBDE6C1B; Fri, 15 Jul 2005 16:44:21 -0400 (EDT) Original-To: Luc Teirlinck In-Reply-To: <200507151353.j6FDrMf12755@raven.dms.auburn.edu> (Luc Teirlinck's message of "Fri, 15 Jul 2005 08:53:22 -0500 (CDT)") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.845, requis 5, autolearn=not spam, AWL 0.06, BAYES_00 -4.90) X-MailScanner-From: monnier@iro.umontreal.ca 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:40955 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:40955 > AFAIK, the motivation was also for some other cases where the user may > somehow setq the variable before loading the file. IIRC this setq may > actually be done by Custom (at a time where it doesn't yet know that > the var have a :setter). > The user should not set a minor mode variable directly unless setting > the variable is all that is needed to enable the mode, in which case > there is no need to call the function if the variable is already set. > The same applies to Custom. Can you prevent users and Custom from doing it? If not, the "should not" consideration is fairly meaningless. > Moreover, if it is done before loading the file, it is done before the > define-minor-mode. Of course. I'm not sure why you say it, tho. I must be misunderstanding something. > In Elisp, if you call a function before it is defined, you get an > error. If you reference a variable before it is defined, you get a > compiler warning, unless you use a compiler defvar. That is true in > particular for :set functions if the defcustom is not produced by > define-minor-mode. Why should defcustoms defined by define-minor-mode > be the lone exception? I do not believe that having to define > functions and variables before using them is that horrible, but if it > is, then should not changes in the way files are loaded or compiled be > implemented, instead of this define-minor-mode only kludge? In 99% of the cases, a minor mode's main body is only executed after the whole file was loaded, so programmers do not expect it to be executed while the file is being loaded. This is empirically true. The eval-after-load trick turns the 99% into 100%, thus removing corner case bugs. > Miles complained loudly (in the form of comments, some of which > may still be in the current elisp code ;-) > These comments make no sense. If you do not understand them, I fear you may not understand the problem well enough to judge what's the least bad solution. Stefan