Re: make-variable-buffer-local change

[Juanma Barranquero]

On Fri, Sep 25, 2009 at 19:07, Dan Nicolaescu <address@hidden> wrote:

> "All packages that assign it"

Of course. For packages that read it, they only want to find the right
(local) value, or nil when it has not been assigned.

> It is globally assigned to nil.

That's the default. Every buffer-local variable has a global default.
Surely you're not implying that is a reason for assigning it globally.

> All buffers that don't set it explicitly use the global nil value.

All buffers that don't set it explicitly don't use it. All packages
that don't set it but read it expect it to be locally set (or globally
nil).

> Isn't it slightly more efficient to access global bindings than buffer
> local bindings, so forcing `make-variable-buffer-local' will force this
> inefficiency everywhere.

Sorry, I think I'm not understanding your point. The packages that
read it will read either the global value, if they're doing some
processing on a buffer that does not have a local value, or the local
value if it exists. There's not such thing as a valid, global, non-nil
value of `list-buffers-directory' (I can imagine uses of local
bindings, though). As I've said, every package that assigns it does it
so locally. So I don't think any inefficiency has been introduced; it
was already buffer-local whenever it was needed. Unless I'm mistaken,
it is not more costly to read a global value for a buffer-local
variable than for an automatically buffer-local variable. The only way
that it could be slightly less efficient is if buffers get
`list-buffers-directory' locally set to nil; I don't think that
happens right now in any standard package, but if it happened, a call
to `kill-local-variable' would be in order.

> IMHO the first thing to do there is to decide if this is a problem with
> uniquify, or if it's just working as expected.  (no idea here).

If you create a buffer *vc-dir* with working dir /emacs/lisp, and
another with working dir /emacs/src, one of the *vc-dir* buffers will
have a value for uniquify-managed and the other will not. That cannot
be right.

    Juanma