From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: void variable Date: 20 Aug 2004 10:54:53 -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> <200407262041.i6QKfFu15523@raven.dms.auburn.edu> <200408200127.i7K1Rpi00213@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1093013787 4503 80.91.224.253 (20 Aug 2004 14:56:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 20 Aug 2004 14:56:27 +0000 (UTC) Cc: larsh@math.ku.dk, rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 20 16:56:05 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 1ByAoG-0006nS-00 for ; Fri, 20 Aug 2004 16:56:04 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1ByAsZ-0001ln-SI for ged-emacs-devel@m.gmane.org; Fri, 20 Aug 2004 11:00:31 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1ByAsT-0001lK-2y for emacs-devel@gnu.org; Fri, 20 Aug 2004 11:00:25 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1ByAsS-0001ku-2N for emacs-devel@gnu.org; Fri, 20 Aug 2004 11:00:24 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1ByAsR-0001kl-J8 for emacs-devel@gnu.org; Fri, 20 Aug 2004 11:00:23 -0400 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ByAnI-0004TE-Qo; Fri, 20 Aug 2004 10:55:05 -0400 Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id E44D4B30279; Fri, 20 Aug 2004 10:54:53 -0400 (EDT) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id D1E528CA23; Fri, 20 Aug 2004 10:54:53 -0400 (EDT) Original-To: Luc Teirlinck In-Reply-To: <200408200127.i7K1Rpi00213@raven.dms.auburn.edu> Original-Lines: 51 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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=0, requis 5) 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: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:26343 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:26343 > Of course, `defcustom' has exactly the same problem as `defvar'. So > doing this for defvar and not defcustom seems inconsistent. Strictly Indeed. We had already mentioned defcustom, but I'd forgotten about it. But now that I looked at it, I also see that it's a bit ugly to do (ideally, defcustom would use defvar internally, but given the way custom is supposed to work, it's not easy to do). We'd probably need to create a new function like `outer-default-boundp' just for that. > speaking, `defconst' also has the same problem, but let-binding a > variable defined with defconst seems very iffy in any circumstances. The situation for defconst is a bit different indeed. The byte-compiler already warns when we do (defconst toto 1) (let ((toto 2)) (balbla)) It doesn't do that if the defconst was in another file, tho (because after the defconst is executed Emacs does not remember whether it was a defconst or a defvar or a setq). We could easily add a bit in the symbol to keep track of which vars are "const" to work around this (my own local Emacs branch has had that for a while, even making all `defconst'd variables read-only). > The message: VAR is still globally unbound > looks cryptic. :-) > "Can't bind `foo-bar' globally: `let' around `defvar'" > I would prefer: > "Warning: defvar for locally bound `%s' failed to globally define it." [...] > For one thing, local bindings are not always made with `let'. I like having `defvar' and `let' in the message. How about: "Warning: defvar ignored because %s is let-bound" Or maybe "skipped" or "failed" is better than "ignored". > Anyway, somebody with a reasonably fast machine may only see this when > studying the *Messages* buffer. It easily can be overwritten by > messages like: Actually I think the problem can show up on a slow machine just as well. But it's nothing new and is not specific to this particular case. Stefan