bug#65209: 30.0.50; Unexpected behaviour of setq-local

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

On 11.08.23 02:17, Michael Heerdegen wrote:
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> 
>> Evaluate the following
>>
>> (progn
>>    (defvar my-var :default-value)
>>    (make-variable-buffer-local 'my-var)
>>    (let ((my-var :let-value))
>>      (setq-local my-var :buffer-local-new))
>>    my-var)
>> => :default-value
>>
>> (progn
>>    (defvar my-var1 :default-value)
>>    (make-variable-buffer-local 'my-var1)
>>    (setq my-var1 :buffer-local)
>>    (let ((my-var1 :let-value))
>>      (setq-local my-var1 :buffer-local-new))
>>    my-var1)
>> => :buffer-local
>>
>> In both cases, setq-local has no effect.
> 
> But isn't it expected that `let' restores the value that was present
> before entering `let'?
That's right, but here's what the docs say about setq-local:

  -- Macro: setq-local &rest pairs
      PAIRS is a list of variable and value pairs.  This macro creates a
      buffer-local binding in the current buffer for each of the
      variables, and gives them a buffer-local value.  It is equivalent
      to calling ‘make-local-variable’ followed by ‘setq’ for each of the
      variables.

In my first example, setq-local doesn't create a buffer-local binding. 
In the second example, it doesn't set a buffer-local value.  So 
setq-local doesn't what the first sentence of the doc says it does.

The second sentence of the doc says something quite different than the 
first sentence because setq in the presence of a let-binding of course 
sets the value of the let-binding.

What's the right thing to do here I find hard to tell.

I think I'd personally prefer if setq-local did what the first sentence 
says.  Just to make things in general easier to understand, I guess.   I 
mean, the let-binding which changes the behaviour of 
lisp-interaction-mode in my case could be anywhere.  It's kind of like a 
spooky action at a distance.  Good luck debugging something like that.

But that's just my 2 cents.