From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Barry Margolin Newsgroups: gmane.emacs.help Subject: Re: Defadvice use Date: Tue, 19 Apr 2005 01:07:49 -0400 Organization: Symantec Message-ID: References: <1113844268.703229.310830@g14g2000cwa.googlegroups.com> <1113851147.155814.314630@g14g2000cwa.googlegroups.com> <87y8bfzx9z.fsf-monnier+gnu.emacs.help@gnu.org> <1113869741.838603.250620@o13g2000cwo.googlegroups.com> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1113887181 9244 80.91.229.2 (19 Apr 2005 05:06:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 19 Apr 2005 05:06:21 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Apr 19 07:06:18 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DNkw6-0003bt-L1 for geh-help-gnu-emacs@m.gmane.org; Tue, 19 Apr 2005 07:06:11 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DNl0K-0007jq-A3 for geh-help-gnu-emacs@m.gmane.org; Tue, 19 Apr 2005 01:10:32 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!postnews.google.com!news4.google.com!news.glorb.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail Original-NNTP-Posting-Date: Tue, 19 Apr 2005 00:07:50 -0500 Original-Newsgroups: gnu.emacs.help Mail-Copies-To: nobody User-Agent: MT-NewsWatcher/3.4 (PPC Mac OS X) X-Copies-To: never Original-Lines: 76 Original-NNTP-Posting-Host: 24.128.234.87 Original-X-Trace: sv3-xHbxQSYc79WmnsPqATAUklXcwAKVGfUd2mKkauSoFWlZPfrWY0QMqKCee5OXOgrBWdY6v1ANaOvcx6p!Gnb2/vxtSzLa6uWjNQDu6dqid/0icE5DPzMlwfMYGO/VeMYF99cmOeL0almScAPxB5uWkxJDWoOo!DFpb+3ElMubhYKJOtYfFrEM6CwpV1b4h8Q== Original-X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Original-Xref: shelby.stanford.edu gnu.emacs.help:130242 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:25810 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:25810 In article <1113869741.838603.250620@o13g2000cwo.googlegroups.com>, "rgb" wrote: > Stefan Monnier wrote: > > > Doesn't (let (bookmark-bmenu-other-window) ...) have limited life. > > > > (let (bookmark-bmenu-other-window) ...) > > > > only affects the bookmark-bmenu-other-window *variable*, not the > > bookmark-bmenu-other-window function. > > > > If that isn't a bug waiting to happen I don't know what is. > You appear to be asserting that it's documented to work that > way but I'd counter with 2 arguments. > > 1. The `feature' is only _implied_, not documented. There is > no mention in any Elisp manual section that covers plists > or symbol function cells about this behavior. The Elisp manual specifically says that 'let' binds variables. That's all it does. Does it have to explicitly say all the things it *doesn't* do, like binding functions and property lists? Function and variable bindings of symbols are totally independent. If you want to bind a function, you can (require 'cl) and then use 'flet'. > > 2. The `feature' invalidates much of the documented behavior of > symbols unless you know how the symbol was created. > > Look at this: > > (defun test1 () > (let (a01) > (put 'a01 'hold "this") > (symbol-plist 'a01))) > > (put 'a01 'hold "that") ; insure symbol already exists > (symbol-plist 'a01) > => (hold "that") ; value is there as expected > > (test1) > => (hold "this") > > (symbol-plist 'a01) > => (hold "this") ; external value unexpectedly changed > > (unintern "a01") ; insure it doesn't exist > (symbol-plist 'a01) > => nil ; no error. > > (test1) > => (hold "this") > > (symbol-plist 'a01) ; Given the external value should change > => nil ; it now unexpectedly doesn't You're looking at the plist of a different symbol. test1 is still referencing the symbol that you uninterned. When you then type 'a01 later, you intern a new symbol, which is not the one whose plist is modified when you call test1. > It's obviously impossible to easily create any function or > macro that manipulates function or property cells unless you > can guarantee none of the symbols are ever created by let. > > Since it appears to be by design, I'd be terribly curious to > see any archive of discussions concerning why this is > appropriate behavior. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me ***