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

[Michael Heerdegen]

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

> A more corner case is:
>
>     (defvar-local my-foo :default)
>     (with-temp-buffer
>       (let ((my-foo :global-let))
>         (with-temp-buffer
>           (setq my-foo :set)
>           (list my-foo (with-temp-buffer my-foo)))))
>
> vs
>
>     (defvar-local my-foo :default)
>     (with-temp-buffer
>       (let ((my-foo :global-let))
>         (setq my-foo :set)
>         (list my-foo (with-temp-buffer my-foo))))
>
> IIRC this is done purposefully (the code has to work harder to get this
> semantics), but not really documented, and I can't offhand give you
> a good reason for that semantics.

Thanks for the example.  (info "(elisp) Creating Buffer-Local") says
about this case

| Making a variable buffer-local within a ‘let’-binding for that
| variable does not work reliably, unless the buffer in which you do
| this is not current either on entry to or exit from the ‘let’.
| This is because ‘let’ does not distinguish between different kinds
| of bindings; it knows only which variable the binding was made for.

I would really like to know a bit more than "doesn't work reliable".
Such situations happen in real Emacs life.  It's not always under the
control of the user or the programmer which variables are currently
let-bound when a buffer is created and buffer local variables might get
set.  "Anything can happen" leaves me with a very uneasy feeling.


Michael.