GNU bug report logs - #77883
31.0.50; C-c C-e in *scratch* generates a missing lexical binding cookie warning

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 77883 in the body.
You can then email your comments to 77883 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; C-c C-e in *scratch* generates a missing lexical binding
 cookie warning
Date: Fri, 18 Apr 2025 10:35:42 +0800

Hello,

Found another case.

*scratch* should probably remain under the dynamic binding dialect of
Emacs Lisp until and unless we switch the default.

-- 
Sean Whitton

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 77883 <at> debbugs.gnu.org
Subject: Re: bug#77883: 31.0.50;
 C-c C-e in *scratch* generates a missing lexical binding cookie
 warning
Date: Fri, 18 Apr 2025 13:49:07 +0300

> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Date: Fri, 18 Apr 2025 10:35:42 +0800
> 
> Found another case.

IMO, it's a bug, because "C-x C-e" doesn't generate any such warnings,
and lexical-binding is t in *scratch* anyway.

> *scratch* should probably remain under the dynamic binding dialect of
> Emacs Lisp until and unless we switch the default.

I think we intentionally decided to switch to t, and I don't see a
reason to revert that decision.  Please provide a rationale for your
suggestion, because without that there's no way of reasoning about
this.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77883 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#77883: 31.0.50; C-c C-e in *scratch* generates a missing
 lexical binding cookie warning
Date: Fri, 18 Apr 2025 13:12:48 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> IMO, it's a bug, because "C-x C-e" doesn't generate any such warnings,
> and lexical-binding is t in *scratch* anyway.

I agree it is a bug.

C-c C-e calls `eval-buffer' which "ignores the current value of the
`lexical-binding' variable.  Instead it will heed any
-*- lexical-binding: t -*- settings in the buffer, and if there is no such
setting, the buffer will be evaluated without lexical binding."

Not good in this case.


Michael.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77883 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#77883: 31.0.50; C-c C-e in *scratch* generates a missing
 lexical binding cookie warning
Date: Fri, 18 Apr 2025 19:37:04 +0800

Hello,

On Fri 18 Apr 2025 at 01:49pm +03, Eli Zaretskii wrote:

>> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> Date: Fri, 18 Apr 2025 10:35:42 +0800
>>
>> Found another case.
>
> IMO, it's a bug, because "C-x C-e" doesn't generate any such warnings,
> and lexical-binding is t in *scratch* anyway.

Right.

>> *scratch* should probably remain under the dynamic binding dialect of
>> Emacs Lisp until and unless we switch the default.
>
> I think we intentionally decided to switch to t, and I don't see a
> reason to revert that decision.

Oh, me neither, I had forgotten/missed that discussion.
What I really meant is that we shouldn't be adding a lexical binding
cookie to the file.

-- 
Sean Whitton

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 77883 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, spwhitton <at> spwhitton.name
Subject: Re: bug#77883: 31.0.50; C-c C-e in *scratch* generates a missing
 lexical binding cookie warning
Date: Fri, 18 Apr 2025 15:13:40 +0300

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: Sean Whitton <spwhitton <at> spwhitton.name>,  Stefan Monnier
>  <monnier <at> iro.umontreal.ca>,  77883 <at> debbugs.gnu.org
> Date: Fri, 18 Apr 2025 13:12:48 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > IMO, it's a bug, because "C-x C-e" doesn't generate any such warnings,
> > and lexical-binding is t in *scratch* anyway.
> 
> I agree it is a bug.
> 
> C-c C-e calls `eval-buffer' which "ignores the current value of the
> `lexical-binding' variable.  Instead it will heed any
> -*- lexical-binding: t -*- settings in the buffer, and if there is no such
> setting, the buffer will be evaluated without lexical binding."
> 
> Not good in this case.

Is it good in any other case?

I mean, what's the logic behind ignoring the current value of
lexical-binding, but heeding the cookie? let alone defaulting to
dynamic binding if there's no cookie?  If the reason is backward
compatibility, I think I'd like to see the details: where would
changing this cause problems?

And note that this aspect of the eval-buffer's behavior is not
documented in the ELisp manual, which is also not a good thing.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77883 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, spwhitton <at> spwhitton.name
Subject: Re: bug#77883: 31.0.50; C-c C-e in *scratch* generates a missing
 lexical binding cookie warning
Date: Fri, 18 Apr 2025 14:22:36 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> I mean, what's the logic behind ignoring the current value of
> lexical-binding, but heeding the cookie? let alone defaulting to
> dynamic binding if there's no cookie?  If the reason is backward
> compatibility, I think I'd like to see the details: where would
> changing this cause problems?
>
> And note that this aspect of the eval-buffer's behavior is not
> documented in the ELisp manual, which is also not a good thing.

Indeed.  This looks like an anachronism to me.  But I would have to
investigate how the current situation evolved.  Unless someone else
remembers...


Michael.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77883 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, spwhitton <at> spwhitton.name
Subject: Re: bug#77883: 31.0.50; C-c C-e in *scratch* generates a missing
 lexical binding cookie warning
Date: Fri, 18 Apr 2025 15:05:34 +0200

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Indeed.  This looks like an anachronism to me.  But I would have to
> investigate how the current situation evolved.  Unless someone else
> remembers...

See Bug#20139.  That was quite a while ago (2019) and just documented
the status quo (and in the docstring only) at that point of time because
someone had been surprised by the behavior.

Looks like `eval-buffer' has just been completely forgotten in the
transition to making lexical binding the default.


Michael.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 77883 <at> debbugs.gnu.org,
 spwhitton <at> spwhitton.name
Subject: Re: bug#77883: 31.0.50; C-c C-e in *scratch* generates a missing
 lexical binding cookie warning
Date: Fri, 18 Apr 2025 09:16:18 -0400

>> C-c C-e calls `eval-buffer' which "ignores the current value of the
>> `lexical-binding' variable.  Instead it will heed any
>> -*- lexical-binding: t -*- settings in the buffer, and if there is no such
>> setting, the buffer will be evaluated without lexical binding."
>> 
>> Not good in this case.
>
> Is it good in any other case?
>
> I mean, what's the logic behind ignoring the current value of
> lexical-binding, but heeding the cookie? let alone defaulting to
> dynamic binding if there's no cookie?  If the reason is backward
> compatibility, I think I'd like to see the details: where would
> changing this cause problems?

I can't remember how we ended up with this, but I strongly suspect it
has to do with the use of `eval-buffer` in `load-with-code-conversion`,
which is the most common use of `eval-buffer` (in dynamic counts, not
static counts, of course).


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: michael_heerdegen <at> web.de, 77883 <at> debbugs.gnu.org, spwhitton <at> spwhitton.name
Subject: Re: bug#77883: 31.0.50; C-c C-e in *scratch* generates a missing
 lexical binding cookie warning
Date: Fri, 18 Apr 2025 16:45:44 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Michael Heerdegen <michael_heerdegen <at> web.de>,  spwhitton <at> spwhitton.name,
>   77883 <at> debbugs.gnu.org
> Date: Fri, 18 Apr 2025 09:16:18 -0400
> 
> >> C-c C-e calls `eval-buffer' which "ignores the current value of the
> >> `lexical-binding' variable.  Instead it will heed any
> >> -*- lexical-binding: t -*- settings in the buffer, and if there is no such
> >> setting, the buffer will be evaluated without lexical binding."
> >> 
> >> Not good in this case.
> >
> > Is it good in any other case?
> >
> > I mean, what's the logic behind ignoring the current value of
> > lexical-binding, but heeding the cookie? let alone defaulting to
> > dynamic binding if there's no cookie?  If the reason is backward
> > compatibility, I think I'd like to see the details: where would
> > changing this cause problems?
> 
> I can't remember how we ended up with this, but I strongly suspect it
> has to do with the use of `eval-buffer` in `load-with-code-conversion`,
> which is the most common use of `eval-buffer` (in dynamic counts, not
> static counts, of course).

If load-with-code-conversion is the only case where this is needed, we
could do that locally in load-with-code-conversion, right?  I mean,
there's no need to "punish" all the users of eval-buffer for that
single use.  Right?

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, 77883 <at> debbugs.gnu.org, spwhitton <at> spwhitton.name
Subject: Re: bug#77883: 31.0.50; C-c C-e in *scratch* generates a missing
 lexical binding cookie warning
Date: Fri, 18 Apr 2025 11:36:30 -0400

> If load-with-code-conversion is the only case where this is needed, we
> could do that locally in load-with-code-conversion, right?  I mean,
> there's no need to "punish" all the users of eval-buffer for that
> single use.  Right?

I guess someone should look at the other uses of `eval-buffer` to figure
out if that's the case.

Another approach might be to check if `lexical-binding` is set
buffer-locally and if so to obey it without even checking the
`lexical-binding` cookie.


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: michael_heerdegen <at> web.de, 77883 <at> debbugs.gnu.org, spwhitton <at> spwhitton.name
Subject: Re: bug#77883: 31.0.50; C-c C-e in *scratch* generates a missing
 lexical binding cookie warning
Date: Sat, 03 May 2025 11:15:00 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: michael_heerdegen <at> web.de,  spwhitton <at> spwhitton.name,  77883 <at> debbugs.gnu.org
> Date: Fri, 18 Apr 2025 11:36:30 -0400
> 
> > If load-with-code-conversion is the only case where this is needed, we
> > could do that locally in load-with-code-conversion, right?  I mean,
> > there's no need to "punish" all the users of eval-buffer for that
> > single use.  Right?
> 
> I guess someone should look at the other uses of `eval-buffer` to figure
> out if that's the case.
> 
> Another approach might be to check if `lexical-binding` is set
> buffer-locally and if so to obey it without even checking the
> `lexical-binding` cookie.

I prefer the latter solution, as it sounds to me less ad-hoc.  Any
objections to installing the below on the master branch?

diff --git a/src/lread.c b/src/lread.c
index 5c8bbe7..6a1d259 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -2589,11 +2589,13 @@ DEFUN ("eval-buffer", Feval_buffer, Seval_buffer, 0, 5, "",
  evaluated code should work normally even if PRINTFLAG is nil, in
  which case the output is displayed in the echo area.
 
-This function ignores the current value of the `lexical-binding'
-variable.  Instead it will heed any
+This function ignores the global value of the `lexical-binding'
+variable.  Instead it will heed the buffer-local value of that
+variable and any
   -*- lexical-binding: t -*-
-settings in the buffer, and if there is no such setting, the buffer
-will be evaluated without lexical binding.
+settings in the buffer; if there is no such setting, and the
+buffer-local value of the variable is nil, the buffer will be
+evaluated without lexical binding.
 
 This function preserves the position of point.  */)
   (Lisp_Object buffer, Lisp_Object printflag, Lisp_Object filename,
@@ -2621,7 +2623,10 @@ DEFUN ("eval-buffer", Feval_buffer, Seval_buffer, 0, 5, "",
   specbind (Qstandard_output, tem);
   record_unwind_protect_excursion ();
   BUF_TEMP_SET_PT (XBUFFER (buf), BUF_BEGV (XBUFFER (buf)));
-  specbind (Qlexical_binding, get_lexical_binding (buf, buf));
+  /* Don't emit a warning about 'lexical-binding' if it already has a
+     local binding in the buffer.  */
+  if (NILP (Flocal_variable_p (Qlexical_binding, buf)))
+    specbind (Qlexical_binding, get_lexical_binding (buf, buf));
   BUF_TEMP_SET_PT (XBUFFER (buf), BUF_BEGV (XBUFFER (buf)));
   readevalloop (buf, 0, filename,
 		!NILP (printflag), unibyte, Qnil, Qnil, Qnil);

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, 77883 <at> debbugs.gnu.org, spwhitton <at> spwhitton.name
Subject: Re: bug#77883: 31.0.50; C-c C-e in *scratch* generates a missing
 lexical binding cookie warning
Date: Sat, 03 May 2025 09:12:32 -0400

> I prefer the latter solution, as it sounds to me less ad-hoc.  Any
> objections to installing the below on the master branch?

LGTM.

> -settings in the buffer, and if there is no such setting, the buffer
> -will be evaluated without lexical binding.
> +settings in the buffer; if there is no such setting, and the
> +buffer-local value of the variable is nil, the buffer will be
> +evaluated without lexical binding.

BTW, this last point is not completely true any more: it depends
on the `default-toplevel-value`.


        Stefan

Message #45 received at 77883-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: michael_heerdegen <at> web.de, 77883-done <at> debbugs.gnu.org,
 spwhitton <at> spwhitton.name
Subject: Re: bug#77883: 31.0.50; C-c C-e in *scratch* generates a missing
 lexical binding cookie warning
Date: Sat, 03 May 2025 16:28:43 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: michael_heerdegen <at> web.de,  spwhitton <at> spwhitton.name,  77883 <at> debbugs.gnu.org
> Date: Sat, 03 May 2025 09:12:32 -0400
> 
> > I prefer the latter solution, as it sounds to me less ad-hoc.  Any
> > objections to installing the below on the master branch?
> 
> LGTM.

Thanks, installed on master, and closing the bug.

> > -settings in the buffer, and if there is no such setting, the buffer
> > -will be evaluated without lexical binding.
> > +settings in the buffer; if there is no such setting, and the
> > +buffer-local value of the variable is nil, the buffer will be
> > +evaluated without lexical binding.
> 
> BTW, this last point is not completely true any more: it depends
> on the `default-toplevel-value`.

Right, fixed.

Previous Next

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