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

[Michael Heerdegen]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

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

I think it does - it's only that `let' restores the old value.
>
> 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.

I don't think this is what is happening.  E.g.

#+begin_src emacs-lisp
(progn
  (defvar my-var :default-value)
  (let ((my-var :let-value))
    (make-local-variable 'my-var)
    (setq my-var :buffer-local-new))
  (list my-var (local-variable-p 'my-var))) ;; (:buffer-local-new t)
#+end_src

`setq' sets the buffer local binding, not the global value the `let'
binding refers to.

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

A different perspective on your recipe could also be: it changes the
value of a variable that controls evaluation of a buffer while
evaluating the contents of the buffer.  Probably not a good idea.

> Good luck debugging something like that.

The same can happen if you `setq' a global binding that happens to be
undone by a surrounding `let'.  Or that is `setq'd again by other code.

Michael.