GNU bug report logs - #62419
28.2; Elisp let-bound buffer-local variable and kill-local-variable

Previous Next

Package: emacs;

Reported by: Matthew Malcomson <hardenedapple <at> gmail.com>

Date: Fri, 24 Mar 2023 13:42:02 UTC

Severity: normal

Found in version 28.2

Done: Stefan Kangas <stefankangas <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #23 received at 62419 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Matthew Malcomson <hardenedapple <at> gmail.com>
Cc: 62419 <at> debbugs.gnu.org
Subject: Re: bug#62419: 28.2; Elisp let-bound buffer-local variable and
 kill-local-variable
Date: Sun, 26 Mar 2023 11:16:44 -0400
>>> (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





This bug report was last modified 1 year and 311 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.