From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: void variable Date: Fri, 30 Jul 2004 00:55:36 -0400 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <410353ED.1090107@math.ku.dk> <4104091E.4040007@math.ku.dk> <200407252046.i6PKkFH29813@raven.dms.auburn.edu> <41042C27.90902@math.ku.dk> <200407260152.i6Q1qbA00327@raven.dms.auburn.edu> <200407260213.i6Q2DNV00353@raven.dms.auburn.edu> <41051F79.3020200@math.ku.dk> <200407290231.i6T2Vlk24222@raven.dms.auburn.edu> Reply-To: rms@gnu.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1091163397 8255 80.91.224.253 (30 Jul 2004 04:56:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 30 Jul 2004 04:56:37 +0000 (UTC) Cc: larsh@math.ku.dk, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 30 06:56:32 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BqPRY-0007SK-00 for ; Fri, 30 Jul 2004 06:56:32 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BqPUm-0000eD-0h for ged-emacs-devel@m.gmane.org; Fri, 30 Jul 2004 00:59:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BqPUa-0000bs-SE for emacs-devel@gnu.org; Fri, 30 Jul 2004 00:59:41 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BqPUY-0000an-MI for emacs-devel@gnu.org; Fri, 30 Jul 2004 00:59:39 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BqPUY-0000ak-Hy for emacs-devel@gnu.org; Fri, 30 Jul 2004 00:59:38 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BqPQe-0001AP-Ud for emacs-devel@gnu.org; Fri, 30 Jul 2004 00:55:36 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1BqPQe-00081K-I4; Fri, 30 Jul 2004 00:55:36 -0400 Original-To: Luc Teirlinck In-reply-to: <200407290231.i6T2Vlk24222@raven.dms.auburn.edu> (message from Luc Teirlinck on Wed, 28 Jul 2004 21:31:47 -0500 (CDT)) 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: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:26113 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:26113 + If you make a local binding for a variable defined with @code{defvar} + or @code{defcustom} in another non-preloaded file, and if anything in + the scope of the binding loads that file, for instance through + autoloading, then this may fail to properly initialize the variable. This tries to describe two different problem situations which in practice occur in different code and when doing different things. 1. Making a variable binding in certain cases. 2. Failing to add an autoload for certain variable definitions. That they are two ways of looking at the same underlying situation is beside the point. Each needs to be treated in the place that relates to the situation in which it occurs. Case #2 belongs in the section that describes autoload cookies. Case #1 belongs in the section which describes `let'. This section, about defvar, is not the right place for either of them. Although it has a relation to the issue, and to both cases, this is not the best place for either of them. Adding a shorter note to the existing warning at the end of the node is appropriate, but don't try to do here the jobs that should be done in other places. Meanwhile, let's leave this until after the new warning is implemented. That will change what we need to say about these cases. There is no point writing text we will have to change very soon.