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

["Ami Fischman" <ami@fischman.org>]

[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]

This snippet:

(make-local-variable 'ami-wcb-bug-foo)
(defun ami-wcb-bug (ami-wcb-bug-foo)
  (with-temp-buffer
    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.

Cheers,
-Ami

[-- Attachment #2: Type: text/html, Size: 1699 bytes --]