[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65209: 30.0.50; Unexpected behaviour of setq-local
From: |
Michael Heerdegen |
Subject: |
bug#65209: 30.0.50; Unexpected behaviour of setq-local |
Date: |
Thu, 24 Aug 2023 03:06:32 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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.
- bug#65209: 30.0.50; Unexpected behaviour of setq-local, (continued)
- bug#65209: 30.0.50; Unexpected behaviour of setq-local, Michael Heerdegen, 2023/08/13
- bug#65209: 30.0.50; Unexpected behaviour of setq-local, Gerd Möllmann, 2023/08/14
- bug#65209: 30.0.50; Unexpected behaviour of setq-local, Stefan Monnier, 2023/08/18
- bug#65209: 30.0.50; Unexpected behaviour of setq-local, Michael Heerdegen, 2023/08/20
- bug#65209: 30.0.50; Unexpected behaviour of setq-local, Eli Zaretskii, 2023/08/20
- bug#65209: 30.0.50; Unexpected behaviour of setq-local, Michael Heerdegen, 2023/08/21
- bug#65209: 30.0.50; Unexpected behaviour of setq-local, Eli Zaretskii, 2023/08/22
- bug#65209: 30.0.50; Unexpected behaviour of setq-local, Michael Heerdegen, 2023/08/22
- bug#65209: 30.0.50; Unexpected behaviour of setq-local, Eli Zaretskii, 2023/08/23
- bug#65209: 30.0.50; Unexpected behaviour of setq-local, Stefan Monnier, 2023/08/23
- bug#65209: 30.0.50; Unexpected behaviour of setq-local,
Michael Heerdegen <=
- bug#65209: 30.0.50; Unexpected behaviour of setq-local, Eli Zaretskii, 2023/08/24
- bug#65209: 30.0.50; Unexpected behaviour of setq-local, Michael Heerdegen, 2023/08/25
- bug#65209: 30.0.50; Unexpected behaviour of setq-local, Eli Zaretskii, 2023/08/26
- bug#65209: 30.0.50; Unexpected behaviour of setq-local, Stefan Monnier, 2023/08/26
- bug#65209: 30.0.50; Unexpected behaviour of setq-local, Michael Heerdegen, 2023/08/27
- bug#65209: 30.0.50; Unexpected behaviour of setq-local, Michael Heerdegen, 2023/08/23
- bug#65209: 30.0.50; Unexpected behaviour of setq-local, Eli Zaretskii, 2023/08/24