[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

crazy interaction between buffer-locality and function-locality of varia

From: Ami Fischman
Subject: crazy interaction between buffer-locality and function-locality of variables
Date: Sat, 1 Nov 2008 20:34:07 -0700

This snippet:

(make-local-variable 'ami-wcb-bug-foo)
(defun ami-wcb-bug (ami-wcb-bug-foo)
(ami-wcb-bug 'bar)

eval'd in a *scratch* buffer results in this error: (void-variable ami-wcb-bug-foo)
because ami-wcb-bug-foo is not bound in the temporary buffer, because the same name has been declared local in *scratch*, and the function-call binding happens in that buffer.  A similar situation for let-binding is described in elisp.info's "11.10.1 Introduction to Buffer-Local Variables".  This happens in 22.1.1 and in CVS HEAD.

Is the behavior of binding function arguments variables subject to the locality of the current buffer at function call time intentional?  It makes writing functions that respond to asynchronous events require using local variables with names that are globally unique (prefixed with package name, presumably), which is a PITA.  An example of where this bit me: gnus makes 'timestamp buffer-local in *Summary* buffers, and emacs-jabber has a function that uses "timestamp" as the name of one of its arguments and then calls with-temp-buffer inside that function.  So most of the time receiving jabber messages works just fine, but if the user happens to have point in a *Summary* buffer then message reciept triggers a void-variable error.

It seems to me that this behavior is broken, but if it's to be kept there needs to be strong guidance against making variables whose names /aren't/ prefixed with the package name buffer-local.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]