In article <[EMAIL PROTECTED]>, "rgb" <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** _______________________________________________ Help-gnu-emacs mailing list Help-gnu-emacs@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnu-emacs