[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#67991: 30.0.50; boundp always returns nil in format-mode-line with l
From: |
Gerd Möllmann |
Subject: |
bug#67991: 30.0.50; boundp always returns nil in format-mode-line with let* after 0fde935 |
Date: |
Sat, 23 Dec 2023 17:13:18 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Aaron Jensen <aaronjensen@gmail.com> writes:
> On Sat, Dec 23, 2023 at 10:21 AM Gerd Möllmann <gerd.moellmann@gmail.com>
> wrote:
>>
>> Aaron Jensen <aaronjensen@gmail.com> writes:
>>
>> > After commits:
>> >
>> > 0fde935b66e43e4d7ec137ba6195de993168587a
>> > a63b206fbde2ead91f1053d80a275f8850e5ffce
>> >
>> > boundp returns nil here, rather than t, like it used to:
>> >
>> > (format-mode-line
>> > '(:eval (let* ((some-var "some-value")
>> > (_ (message "Bound: %S" (boundp 'some-var))))
>> > (message "Var: %S, Bound: %S" some-var (boundp 'some-var)))))
>> >
>> > This has an impact on a particular package I use for my modeline, which
>> > can be worked around if this behavior is expected. It seemed a
>> > significant chagne, so I wanted to report it, in case it was not expected.
>>
>> I don't know why that would have changed things with Stefan's commit,
>> but are your sure that some-var is declared special (has a defvar, for
>> instance)? When it is, boundp returns t here.
>
> It's not in the package in question.
It should have a defvar, to make sure that the binding of some-var in
the let* behaves as expected also when lexical-binding it t, which it is
in lisp-interaction-mode, for example.
> But even if I defvar w/o giving
> it a value, it does not return t:
That's strange, indeed:
(defvar some-var2)
=> some-var2
(special-variable-p 'some-var2)
=> nil
(defvar some-var3 nil)
=> some-var3
(special-variable-p 'some-var3)
=> t
Does someone know if that's intended for some reason?
Looks like a bug to me.