unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.





  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

  List information: https://www.gnu.org/software/emacs/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).