From: Eli Zaretskii <eliz@gnu.org>
To: Michael Heerdegen <michael_heerdegen@web.de>
Cc: gerd.moellmann@gmail.com, 65209@debbugs.gnu.org,
monnier@iro.umontreal.ca
Subject: bug#65209: 30.0.50; Unexpected behaviour of setq-local
Date: Thu, 24 Aug 2023 08:22:35 +0300 [thread overview]
Message-ID: <83msyhqajo.fsf@gnu.org> (raw)
In-Reply-To: <87pm3dnt9j.fsf@web.de> (message from Michael Heerdegen on Thu, 24 Aug 2023 03:06:32 +0200)
> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier
> <monnier@iro.umontreal.ca>, 65209@debbugs.gnu.org,
> gerd.moellmann@gmail.com
> Date: Thu, 24 Aug 2023 03:06:32 +0200
>
> > 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".
I don't think we should tell more about it in the manual. When the
manual says "doesn't work reliably", the meaning is clear: stay away
from doing that unless you know very well what you are doing. So if
someone wants to use this regardless of the warning, and they don't
yet "know what they are doing well enough", they should either study
the code or ask some expert. Such subtleties have no place in the
manual, since that would make it very large and hard to read for the
majority who will indeed "stay away".
> 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.
Please describe such situations, where the escape (i.e. how to avoid
bumping into this subtlety, by either rewriting the code or using
auxiliary variables) is not clear.
next prev parent reply other threads:[~2023-08-24 5:22 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-10 13:50 bug#65209: 30.0.50; Unexpected behaviour of setq-local Gerd Möllmann
2023-08-10 14:00 ` Eli Zaretskii
2023-08-11 0:17 ` Michael Heerdegen
2023-08-11 4:56 ` Gerd Möllmann
2023-08-11 5:53 ` Michael Heerdegen
2023-08-11 8:17 ` Gerd Möllmann
2023-08-11 11:09 ` Eli Zaretskii
2023-08-11 11:34 ` Gerd Möllmann
2023-08-11 11:36 ` Eli Zaretskii
2023-08-13 4:16 ` Michael Heerdegen
2023-08-13 5:53 ` Eli Zaretskii
2023-08-11 14:58 ` Drew Adams
2023-08-13 16:43 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-13 19:51 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-14 3:24 ` Michael Heerdegen
2023-08-14 4:05 ` Gerd Möllmann
2023-08-18 23:24 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-20 4:43 ` Michael Heerdegen
2023-08-20 6:49 ` Eli Zaretskii
2023-08-22 3:09 ` Michael Heerdegen
2023-08-22 10:56 ` Eli Zaretskii
2023-08-23 3:47 ` Michael Heerdegen
2023-08-23 11:39 ` Eli Zaretskii
2023-08-23 12:51 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-24 1:06 ` Michael Heerdegen
2023-08-24 5:22 ` Eli Zaretskii [this message]
2023-08-26 2:09 ` Michael Heerdegen
2023-08-26 6:02 ` Eli Zaretskii
2023-08-26 14:25 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-27 4:19 ` Michael Heerdegen
2023-08-24 3:31 ` Michael Heerdegen
2023-08-24 5:35 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83msyhqajo.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=65209@debbugs.gnu.org \
--cc=gerd.moellmann@gmail.com \
--cc=michael_heerdegen@web.de \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.