Re: make-variable-buffer-local change

[Dan Nicolaescu <dann@ics.uci.edu>]

Juanma Barranquero <lekktu@gmail.com> writes:

  > On Fri, Sep 25, 2009 at 18:09, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > 
  > > Can you please explain the reason for this change:
  > 
  > Sure.
  > 
  > > In most cases it is better to use `make-local-variable',
  > > which makes a variable local in just one buffer.
  > 
  > That's true, in the case where a variable has local and non-local
  > uses. The warning that you quote is intended to keep people from
  > blindly making variables automatically buffer-local as soon as they
  > realize that the variable *could* sometimes be useful as buffer-local.
  > That's a good suggestion.
  > 
  > However, `list-buffers-directory' is *always* used as buffer-local.
  > All packages that assign it make it buffer-local first. There's no

"All packages that assign it"

  > reason ever (that I can think of) to assign it globally; it would in

It is globally assigned to nil. 

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

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.

  > BTW, I did this patch while investigating #3224. uniquify has code to
  > deal with buffers that assign `list-buffers-directory', but it is
  > doing a bad job of it. I cannot think of a clean way to fix it that
  > does not involve changing more code than I would like, though. Ideas
  > welcome.

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