bug#62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable

[Stefan Monnier]

>>> (setq auto-fill-function 'local-symbol)
>>> (describe-variable 'auto-fill-function)
>>> ;; `auto-fill-function' is let-bound in the buffer scope
>>> (let ((auto-fill-function 'temp-symbol))
>>>  ;; Now there is no buffer-local variable for `auto-fill-function', but the
>>>  ;; `let' unwrapping info is still there.
>>>  (kill-local-variable 'auto-fill-function)
>>>  ;; Since the check in the emacs source is
>>>  ;; a) Is there a buffer-local variable.
>>>  ;; b) Is there a let-binding shadowing the current variable.
>>>  ;; Then this `setq' sets the *global* variable.
>>>  (setq auto-fill-function 'other-symbol))
>>> ;; Exiting the `let' has special handling to avoid resetting a local 
>>> variable
>>> ;; when the local variable was `let' bound, which means that overall the 
>>> `setq'
>>> ;; set the global variable and the `let' has been lost.
>> 
>> AFAIK the behavior is "as intended": the `let` only affects *one*
>> binding, either the global one or the buffer-local one.
>> 
>
> Not going to push much on this since your suggested change to
> `newline` would fix everything to me.  But the part I think is strange
> is `setq` not creating a buffer-local binding in this environment.

Hmm... maybe you're right that the (setq auto-fill-function 'other-symbol)
shouldn't set the global variable but the local one.
It might be a bug in how we check whether there's a let-binding that
should make us refrain from obeying the "automatically set buffer-locally".

Good point.  I'll have to take a closer look.

> I.e. currently the behaviour of `setq` on automatic   buffer-local variables 
> is:
>       - Outside `let`, always affect buffer-local (creating if necessary)
>       - In `let` of global binding, affect global binding.
>       - In `let` of buffer-local binding, affect buffer-local
>       - In `let` of buffer-local binding but where buffer-local value has
> been killed, affect global value.
>
> I believe that last condition is strange and the behaviour of `setq` would
> be more understandable without it.

Agreed.


        Stefan