Re: Why is not end-of-defun-function buffer local?

[Stefan Monnier]

>>> It surprises me that beginning/end-of-defun-function are not always
>>> buffer local.
>> 
>> Why force them to be buffer-local?  When you need to set them in
>> a buffer, just do
>> 
>> (set (make-local-variable 'end-of-defun-function) 'foo)
>> 
>> If you think that's too long, then you may want to request a new
>> `setq-local' macro.

> setq-local would be a good idea.

> But I do not understand how you think in this case.  Are not the
> variables above always meant to be buffer local?

I don't see why they should always be buffer-local.  It is quite
meaningful to set this variable globally so as to get a new improved
default behavior.

> Looking at some code that is a bit older it looks like some of it uses
> make-local-variable where it is not needed since the variables in question
> are always buffer local. From that I draw the conclusion that the code in
> Emacs uses make-variable-buffer-local more often now. Is not that the case?

make-variable-buffer-local has the following downsides:
1 - it cannot be reverted.
2 - it may be done too late.
3 - when you see `setq' it's not obvious that the setting is buffer-local
    unless you remember seeing the call to make-variable-buffer-local.
The second problem may also explain what you're seeing: some code may
set a variable before the make-variable-buffer-local gets run.
It's actually "common" to introduce bugs this way, because people see
"this is automatically buffer-local" in the C-h v info, so they just use
`setq' without realizing that the setq may occur before the package
gets loaded.
make-variable-buffer-local is not evil, but make-local-variable is much
tamer and more explicit, and it works just as well in most cases.


        Stefan