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

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

[Ami Fischman]

[-- 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 --]

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

[Stefan Monnier]

> Is the behavior of binding function arguments variables subject to the
> locality of the current buffer at function call time intentional?  It makes

Yes.  It's not great, but there's no easy fix for it.

> 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.

Indeed, it's a Gnus bug.  Please report it there.

> It seems to me that this behavior is broken, but if it's to be kept

It's partly broken, but other behaviors are broken in other ways.
The only good solution is to be careful not to mix them up (except when
it's really wanted, such as with default-directory which is often
let-bound).

> there needs to be strong guidance against making variables whose names
> /aren't/ prefixed with the package name buffer-local.

Agreed.  Where would you like to see it?  In the coding conventions?


        Stefan

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

[Ami Fischman]

> > It seems to me that this behavior is broken, but if it's to be kept
> It's partly broken, but other behaviors are broken in other ways.
> The only good solution is to be careful not to mix them up (except when
> it's really wanted, such as with default-directory which is often
> let-bound).

My point was that the only way to avoid mixing the behaviors is to
make variable names unwieldy.  As an async-event-handler-writer all
function arguments and local variables must be
globally-uniquely-named, and as a major-mode writer all buffer-local
variables must be globally-uniquely-named.  The latter is perhaps not
too terrible a burden, but the former would make coding in elisp
unbearable IMO.  I'll report this to the gnus devel list.

> > there needs to be strong guidance against making variables whose names
> > /aren't/ prefixed with the package name buffer-local.
> Agreed.  Where would you like to see it?  In the coding conventions?

At least also at the same place as the warning about the conflict
between buffer-locals and let-binding in elisp.info that I pointed to
in my original email.  But also this should be a great big warning in
the defun docs of the make-variable-*-local and make-local-variable
since it's the authors using those functions (and friends?  I don't
have a complete list) that must shoulder the burden of avoiding
collisions.

-a

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

[Stefan Monnier]

> My point was that the only way to avoid mixing the behaviors is to
> make variable names unwieldy.  As an async-event-handler-writer all
> function arguments and local variables must be
> globally-uniquely-named, and as a major-mode writer all buffer-local
> variables must be globally-uniquely-named.

Actually, function arguments (and typical local variables) don't need to
be globally unique: they just need to use a name space that's not used
for buffer-local variables.

In Emacs we get this behavior as follows: buffer-local variables should
use a package prefix.

> The latter is perhaps not too terrible a burden, but the former would
> make coding in elisp unbearable IMO.

Indeed, which is why the convention moves the responsability to the
buffer-local side.

>> > there needs to be strong guidance against making variables whose names
>> > /aren't/ prefixed with the package name buffer-local.
>> Agreed.  Where would you like to see it?  In the coding conventions?

> At least also at the same place as the warning about the conflict
> between buffer-locals and let-binding in elisp.info that I pointed to
> in my original email.  But also this should be a great big warning in
> the defun docs of the make-variable-*-local and make-local-variable
> since it's the authors using those functions (and friends?  I don't
> have a complete list) that must shoulder the burden of avoiding
> collisions.

Hmm... at the place you mentioned in the elisp.info, we're kind of far
from discussing naming conventions, but I'll try and add a cross-ref.


        Stefan

RE: crazy interaction between buffer-locality and function-localityof variables

[Drew Adams]

> Hmm... at the place you mentioned in the elisp.info, we're kind of far
> from discussing naming conventions, but I'll try and add a cross-ref.

I'm not following this closely, but an illustrative example of the problem, in
the doc, would help understanding. It's presumably the _reason_ for the naming
convention (that is, the problem the convention tries to avoid) that it is
important to understand.

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

[Richard M. Stallman]

    (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)

This is intentional.  It is more coherent than the other possible
behaviors.

    Is the behavior of binding function arguments variables subject to the
    locality of the current buffer at function call time intentional?

That's a confusing way to describe things.  The current buffer
when the function is called has no direct effect on the function.
What does have an effect is switching buffers within the function.

Normally this is not a problem, because the sort of names that are
used for function arguments are never made buffer-local.  But you
encountered an exception.

      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.

We should probably change the name of that variable in Gnus.
to something like `gnus-timestamp'.

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

[Ami Fischman]

>    Is the behavior of binding function arguments variables subject to the
>    locality of the current buffer at function call time intentional?
> That's a confusing way to describe things.

I intentionally described the behavior I observed in a way as
confusing as I found the behavior to be, hoping to draw attention to
the deficiency I considered in the behavior.

> The current buffer
> when the function is called has no direct effect on the function.
> What does have an effect is switching buffers within the function.

This distinction lacks a difference to me.  Buffer-switching is a
standard idiom of elisp and normally considered an implementation
detail of a function, not part of its external contract.  If including
buffer-switching in a function's code unbinds variables bound in that
function then that promotes the presence of buffer-switching from
implementation detail to externally-visible effect.  Put another way,
a function that uses buffer-switching is always at the mercy of the
buffers in which it is invoked, to avoid making local variables with
the same names as the function's arguments or let-bound variables.
This is what I was hoping was unintentional and fixable, though you
and Stefan have now told me that it is the lesser evil (and by
implication here to stay).

> We should probably change the name of that variable in Gnus.
> to something like `gnus-timestamp'.

I have posted a request for something similar to the gnus mailing list:
http://thread.gmane.org/gmane.emacs.gnus.general/67732

-a