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

[Eli Zaretskii <eliz@gnu.org>]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: monnier@iro.umontreal.ca,  65209@debbugs.gnu.org,  gerd.moellmann@gmail.com
> Date: Sat, 26 Aug 2023 04:09:11 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.
> 
> I don't know.  The problem is that when setting buffer-local variables
> it is unknown which bindings are in effect unless you explicitly look.

Only if you happen to write the convoluted code such as the one you
show, right?  Because in simple cases the results are predictable and
known in advance, right?

> I don't know whether something like this can happen at all.  Stefan's
> examples use `setq', not `setq-local', so maybe everything is just fine
> after his fix of this bug.  I can't tell for sure because I can't read C
> very efficiently and we don't have doc describing this, so I am not
> really a good person to ask.  Since Stefan is quiet, let's assume the
> situation is good enough now.

From where I stand, we cannot possibly include all of this in the
manual.  Emacs Lisp is a large and complex language, especially when
the code mixes some of the advanced features in complex ways.  Trying
to describe all of them and all of their combinations will just make
the manual harder to read.

There are times when I bump into situations like that, even though I
try to avoid such complex code as mush as possible (because it also
increases the probability of making mistakes due to complexity).  When
that happens, and the blunder is not clear upon examination and
debugging, I simply rewrite the code to use simpler patterns.  This is
my advice to anyone who bumps into these situations.