GNU bug report logs - #44733
Nested let bindings for non-local DEFVAR_PER_BUFFER variables unwind wrong

Previous Next

Full log

Message #23 received at 44733 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> catern.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44733 <at> debbugs.gnu.org
Subject: Re: bug#44733: Nested let bindings for non-local DEFVAR_PER_BUFFER
 variables unwind wrong
Date: Thu, 19 Nov 2020 15:56:54 -0500

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>> This is a bug, indeed.  It should be 123 at this point.
>> That's one perspective, but it seems less consistent with the
>> documentation and with expected behavior.
>
> That's the way all other variables behave:
>
>     (defvar-local sm-foo 1)
>     (let ((sm-foo 23))
>       (setq sm-foo 45)
>       (list sm-foo
>             (with-temp-buffer sm-foo)))

Aha, okay, I certainly can't argue with that.  DEFVAR_PER_BUFFER
variables should match that behavior.  I'll update my patch series to
match.

> and I think it's asking for trouble if
>
>     (let ((sm-foo 23))
>       ...)
>
> behaves differently from
>
>     (let (sm-foo)
>       (setq sm-foo 23)
>       ...)

Ah, this example is persuasive to me.

I see also that there is at least some documentation of this behavior,
in the make-variable-buffer-local documentation in variables.texi, which
I missed:

  A peculiar wrinkle of this feature is that binding the variable (with
  @code{let} or other binding constructs) does not create a buffer-local
  binding for it.  Only setting the variable (with @code{set} or
  @code{setq}), while the variable does not have a @code{let}-style
  binding that was made in the current buffer, does so.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.