GNU bug report logs -
#74145
31.0.50; Default lexical-binding to t
Previous Next
To reply to this bug, email your comments to 74145 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
monnier <at> iro.umontreal.ca, bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Thu, 31 Oct 2024 20:59:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>:
New bug report received and forwarded. Copy sent to
monnier <at> iro.umontreal.ca, bug-gnu-emacs <at> gnu.org.
(Thu, 31 Oct 2024 20:59:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Package: Emacs
Version: 31.0.50
I believe the time has come to change the default dialect.
I attached a suggested patch to do that.
Stefan
[0001-Change-the-default-value-of-lexical-binding.patch (text/x-diff, inline)]
From 973939b9dd79735f051c99f1a20d74aabad931ff Mon Sep 17 00:00:00 2001
From: Stefan Monnier <monnier <at> iro.umontreal.ca>
Date: Thu, 31 Oct 2024 16:00:10 -0400
Subject: [PATCH] Change the default value of `lexical-binding`
* src/lread.c (syms_of_lread): Set `Vlexical_binding` to Qt.
(Fload, Feval_buffer): Don't assume the default value of
`lexical-binding` is nil.
* lisp/loadup.el: Don't assume the default value of `lexical-binding`
is nil.
* doc/misc/cl.texi (Porting Common Lisp):
* doc/lispref/variables.texi (Variable Scoping)
(Selecting Lisp Dialect): Adjust to new default of `lexical-binding`.
* doc/lispref/edebug.texi (Edebug Eval): Remove out of date paragraph.
* doc/lispintro/emacs-lisp-intro.texi (How let Binds Variables)
(Lexical vs. Dynamic Binding Example, defvar): Only consider the
lexical dialect of ELisp.
---
doc/lispintro/emacs-lisp-intro.texi | 26 ++++++++----------------
doc/lispref/edebug.texi | 7 -------
doc/lispref/variables.texi | 31 +++++++++++++++--------------
doc/misc/cl.texi | 9 +++++----
etc/NEWS | 6 ++++++
lisp/loadup.el | 4 ++--
src/lread.c | 14 +++++++++----
7 files changed, 47 insertions(+), 50 deletions(-)
diff --git a/doc/lispintro/emacs-lisp-intro.texi b/doc/lispintro/emacs-lisp-intro.texi
index 49916235fbf..6cc7a5b3cf2 100644
--- a/doc/lispintro/emacs-lisp-intro.texi
+++ b/doc/lispintro/emacs-lisp-intro.texi
@@ -3754,21 +3754,12 @@ How let Binds Variables
Emacs Lisp supports two different ways of binding variable names to
their values. These ways affect the parts of your program where a
-particular binding is valid. For historical reasons, Emacs Lisp uses
-a form of variable binding called @dfn{dynamic binding} by default.
-However, in this manual we discuss the preferred form of binding,
-called @dfn{lexical binding}, unless otherwise noted (in the future,
-the Emacs maintainers plan to change the default to lexical binding).
+particular binding is valid.
+In this manual we discuss the preferred form of binding,
+called @dfn{lexical binding}, unless otherwise noted.
If you have programmed in other languages before, you're likely
already familiar with how lexical binding behaves.
-In order to use lexical binding in a program, you should add this to
-the first line of your Emacs Lisp file:
-
-@example
-;;; -*- lexical-binding: t -*-
-@end example
-
For more information about this, @pxref{Variable Scoping, , ,
elisp, The Emacs Lisp Reference Manual}.
@@ -3818,8 +3809,6 @@ Lexical vs. Dynamic Binding Example
For example, see what happens in this code under lexical binding:
@example
-;;; -*- lexical-binding: t -*-
-
(setq x 0)
(defun getx ()
@@ -3845,7 +3834,7 @@ Lexical vs. Dynamic Binding Example
If we use dynamic binding instead, the behavior is different:
@example
-;;; -*- lexical-binding: nil -*-
+(defvar x) ;; Use dynamic binding for 'x'.
(setq x 0)
@@ -3867,8 +3856,9 @@ Lexical vs. Dynamic Binding Example
@code{x}, since its binding is below the one from our @code{let}
expression in the stack of bindings.
-(Some variables are also ``special'', and they are always dynamically
-bound even when @code{lexical-binding} is @code{t}. @xref{defvar, ,
+(The @code{defvar} declaration above is said to make the variable
+``special'', which causes it to obey the dynamic binding rules instead of
+the default lexical binding rules. @xref{defvar, ,
Initializing a Variable with @code{defvar}}.)
@node if
@@ -9229,7 +9219,7 @@ defvar
The @code{defvar} special form is similar to @code{setq} in that it
sets the value of a variable. It is unlike @code{setq} in three ways:
first, it marks the variable as ``special'' so that it is always
-dynamically bound, even when @code{lexical-binding} is @code{t}
+dynamically bound
(@pxref{How let Binds Variables}). Second, it only sets the value of
the variable if the variable does not already have a value. If the
variable already has a value, @code{defvar} does not override the
diff --git a/doc/lispref/edebug.texi b/doc/lispref/edebug.texi
index 03fae67e528..fe617550b09 100644
--- a/doc/lispref/edebug.texi
+++ b/doc/lispref/edebug.texi
@@ -722,13 +722,6 @@ Edebug Eval
pretty-printed in a separate buffer.
@end table
-@cindex lexical binding (Edebug)
- Edebug supports evaluation of expressions containing references to
-lexically bound symbols created by the following constructs in
-@file{cl.el}: @code{lexical-let}, @code{macrolet}, and
-@code{symbol-macrolet}.
-@c FIXME? What about lexical-binding = t?
-
@node Eval List
@subsection Evaluation List Buffer
diff --git a/doc/lispref/variables.texi b/doc/lispref/variables.texi
index af11e498d86..fa5f792b40f 100644
--- a/doc/lispref/variables.texi
+++ b/doc/lispref/variables.texi
@@ -285,7 +285,7 @@ Local Variables
@defspec letrec (bindings <at> dots{}) forms <at> dots{}
This special form is like @code{let*}, but all the variables are bound
before any of the local values are computed. The values are then
-assigned to the locally bound variables. This is only useful when
+assigned to the locally bound variables. This is useful only when
lexical binding is in effect, and you want to create closures that
refer to bindings that would otherwise not yet be in effect when using
@code{let*}.
@@ -351,7 +351,7 @@ Local Variables
done so that the value returned by the call is the value of @var{body}
itself, as is the case in the recursive call to @code{sum} above.
-@code{named-let} can only be used when lexical-binding is enabled.
+@code{named-let} can be used only when lexical-binding is enabled.
@xref{Lexical Binding}.
@end defspec
@@ -392,7 +392,7 @@ Void Variables
to evaluate the variable signals a @code{void-variable} error, instead
of returning a value.
- Under the optional lexical scoping rule, the value cell only holds
+ Under the optional lexical scoping rule, the value cell holds only
the variable's global value---the value outside of any lexical binding
construct. When a variable is lexically bound, the local value is
determined by the lexical environment; hence, variables can have local
@@ -514,7 +514,7 @@ Defining Variables
Note that specifying a value, even @code{nil}, marks the variable as
special permanently. Whereas if @var{value} is omitted then the
-variable is only marked special locally (i.e.@: within the current
+variable is marked special only locally (i.e.@: within the current
lexical scope, or file if at the top-level). This can be useful for
suppressing byte compilation warnings, see @ref{Compiler Errors}.
@@ -706,8 +706,8 @@ Accessing Variables
The usual way to reference a variable is to write the symbol which
names it. @xref{Symbol Forms}.
- Occasionally, you may want to reference a variable which is only
-determined at run time. In that case, you cannot specify the variable
+ Occasionally, you may want to reference a variable which is determined
+only at run time. In that case, you cannot specify the variable
name in the text of the program. You can use the @code{symbol-value}
function to extract the value.
@@ -1003,14 +1003,15 @@ Variable Scoping
while the binding construct (such as the body of a @code{let} form) is
being executed.
- The old dynamic-only Emacs Lisp dialect is still the default in code
+ The new lexically scoped Emacs Lisp dialect is now the default in code
loaded or evaluated from Lisp files that lack a dialect declaration.
-Eventually the modern dialect will be made the default.
-All Lisp files should declare the dialect used to ensure that they
-keep working correctly in the future.
+Lisp files which still need the old dynamically scoped dialect need to declare
+it explicitly to ensure that they keep working correctly, and should
+eventually be converted to use the new dialect to
+ensure that they keep working correctly in the future.
The following subsections describe lexical binding and dynamic
-binding in greater detail, and how to enable lexical binding in Emacs
+binding in greater detail, and how to disable lexical binding in Emacs
Lisp programs.
@menu
@@ -1319,8 +1320,8 @@ Selecting Lisp Dialect
@noindent
for the old dynamic-only dialect. When no declaration is present the
-old dialect is used, but this may change in a future release.
-The compiler will warn if no declaration is present.
+new dialect is used. Support for the old dialect may be removed in
+a future release.
When evaluating Emacs Lisp code directly using an @code{eval} call,
lexical binding is enabled if the @var{lexical} argument to
@@ -1980,8 +1981,8 @@ File Local Variables
@defvar permanently-enabled-local-variables
Some local variable settings will, by default, be heeded even if
-@code{enable-local-variables} is @code{nil}. By default, this is only
-the case for the @code{lexical-binding} local variable setting, but
+@code{enable-local-variables} is @code{nil}. By default, this is the
+case only for the @code{lexical-binding} local variable setting, but
this can be controlled by using this variable, which is a list of
symbols.
@end defvar
diff --git a/doc/misc/cl.texi b/doc/misc/cl.texi
index 113029700ec..395725944f0 100644
--- a/doc/misc/cl.texi
+++ b/doc/misc/cl.texi
@@ -4758,12 +4758,13 @@ Porting Common Lisp
@item
Lexical scoping. In Common Lisp, function arguments and @code{let}
bindings apply only to references physically within their bodies (or
-within macro expansions in their bodies). Traditionally, Emacs Lisp
-uses @dfn{dynamic scoping} wherein a binding to a variable is visible
+within macro expansions in their bodies). The is also the case in
+modern Emacs Lisp, but historically, Emacs Lisp
+used @dfn{dynamic scoping} wherein a binding to a variable is visible
even inside functions called from the body.
@xref{Dynamic Binding,,,elisp,GNU Emacs Lisp Reference Manual}.
-Lexical binding is available since Emacs 24.1, so be sure to set
-@code{lexical-binding} to @code{t} if you need to emulate this aspect
+Lexical binding is available since Emacs 24.1, but be sure not to set
+@code{lexical-binding} to @code{nil} if you need to emulate this aspect
of Common Lisp. @xref{Lexical Binding,,,elisp,GNU Emacs Lisp Reference Manual}.
Here is an example of a Common Lisp code fragment that would fail in
diff --git a/etc/NEWS b/etc/NEWS
index d1c7303f976..5a480c5f68a 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -636,6 +636,12 @@ the directory into which the repository was cloned.
* Incompatible Lisp Changes in Emacs 31.1
++++
+** 'lexical-binding' now defaults to t.
+The default ELisp dialect is now the lexically scoped dialect.
+Any code which has not yet been adapted should either be
+adapted or set 'lexical-binding' to nil explicitly.
+
** Nested backquotes are not supported any more in Pcase patterns.
** The 'rx' category name 'chinese-two-byte' must now be spelled correctly.
diff --git a/lisp/loadup.el b/lisp/loadup.el
index bd74a9d6aff..e676c338c14 100644
--- a/lisp/loadup.el
+++ b/lisp/loadup.el
@@ -654,9 +654,9 @@ comp-subr-arities-h
(unwind-protect
(let ((tmp-dump-mode dump-mode)
(dump-mode nil)
- ;; Set `lexical-binding' to nil by default
+ ;; Set `lexical-binding' to its default value
;; in the dumped Emacs.
- (lexical-binding nil))
+ (lexical-binding (default-toplevel-value 'lexical-binding)))
(if (member tmp-dump-mode '("pdump" "pbootstrap"))
(dump-emacs-portable (expand-file-name output invocation-directory))
(dump-emacs output (if (eq system-type 'ms-dos)
diff --git a/src/lread.c b/src/lread.c
index ea0398196e3..9f56880e551 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -1522,7 +1522,7 @@ DEFUN ("load", Fload, Sload, 1, 5, 0,
otherwise using a file-variable in the first line. This is bound here
so that it takes effect whether or not we use
Vload_source_file_function. */
- specbind (Qlexical_binding, Qnil);
+ specbind (Qlexical_binding, Fdefault_toplevel_value (Qlexical_binding));
Lisp_Object found_eff =
is_native_elisp
@@ -1720,8 +1720,11 @@ DEFUN ("load", Fload, Sload, 1, 5, 0,
}
else
{
- if (lisp_file_lexical_cookie (Qget_file_char) == Cookie_Lex)
+ lexical_cookie_t lexc = lisp_file_lexical_cookie (Qget_file_char);
+ if (lexc == Cookie_Lex)
Fset (Qlexical_binding, Qt);
+ else if (lexc == Cookie_Dyn)
+ Fset (Qlexical_binding, Qnil);
if (! version || version >= 22)
readevalloop (Qget_file_char, &input, hist_file_name,
@@ -2606,8 +2609,11 @@ 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)));
+ lexical_cookie_t lexc = lisp_file_lexical_cookie (buf);
specbind (Qlexical_binding,
- lisp_file_lexical_cookie (buf) == Cookie_Lex ? Qt : Qnil);
+ lexc == Cookie_Lex ? Qt
+ : lexc == Cookie_Dyn ? Qnil
+ : Fdefault_toplevel_value (Qlexical_binding));
BUF_TEMP_SET_PT (XBUFFER (buf), BUF_BEGV (XBUFFER (buf)));
readevalloop (buf, 0, filename,
!NILP (printflag), unibyte, Qnil, Qnil, Qnil);
@@ -6056,7 +6062,7 @@ syms_of_lread (void)
This variable is automatically set from the file variables of an
interpreted Lisp file read using `load'. Unlike other file local
variables, this must be set in the first line of a file. */);
- Vlexical_binding = Qnil;
+ Vlexical_binding = Qt;
Fmake_variable_buffer_local (Qlexical_binding);
DEFVAR_LISP ("eval-buffer-list", Veval_buffer_list,
--
2.39.5
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Thu, 31 Oct 2024 23:33:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 74145 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:
> I believe the time has come to change the default dialect.
> I attached a suggested patch to do that.
Sounds good to me. Legacy code can still run with a lexical-binding:nil
cookie, so I think we're good in the backwards-compatibility department.
Andrea and Eli?
Some minor comments and questions on your patch below.
> @@ -392,7 +392,7 @@ Void Variables
> to evaluate the variable signals a @code{void-variable} error, instead
> of returning a value.
>
> - Under the optional lexical scoping rule, the value cell only holds
> + Under the optional lexical scoping rule, the value cell holds only
> the variable's global value---the value outside of any lexical binding
> construct. When a variable is lexically bound, the local value is
> determined by the lexical environment; hence, variables can have local
I think this section might need more work. It's a bit confusing to talk
about "default dynamic scoping" and "optional lexical scoping" now.
Shouldn't we talk about "normal variables with lexical scoping" and
"special variables with dynamic scoping" or something along those lines?
> diff --git a/lisp/loadup.el b/lisp/loadup.el
> index bd74a9d6aff..e676c338c14 100644
> --- a/lisp/loadup.el
> +++ b/lisp/loadup.el
> @@ -654,9 +654,9 @@ comp-subr-arities-h
> (unwind-protect
> (let ((tmp-dump-mode dump-mode)
> (dump-mode nil)
> - ;; Set `lexical-binding' to nil by default
> + ;; Set `lexical-binding' to its default value
> ;; in the dumped Emacs.
> - (lexical-binding nil))
> + (lexical-binding (default-toplevel-value 'lexical-binding)))
> (if (member tmp-dump-mode '("pdump" "pbootstrap"))
> (dump-emacs-portable (expand-file-name output invocation-directory))
> (dump-emacs output (if (eq system-type 'ms-dos)
Why not just use `t` here instead of its `default-toplevel-value`?
> diff --git a/src/lread.c b/src/lread.c
> index ea0398196e3..9f56880e551 100644
> --- a/src/lread.c
> +++ b/src/lread.c
> @@ -1522,7 +1522,7 @@ DEFUN ("load", Fload, Sload, 1, 5, 0,
> otherwise using a file-variable in the first line. This is bound here
> so that it takes effect whether or not we use
> Vload_source_file_function. */
> - specbind (Qlexical_binding, Qnil);
> + specbind (Qlexical_binding, Fdefault_toplevel_value (Qlexical_binding));
>
> Lisp_Object found_eff =
> is_native_elisp
And here?
> @@ -2606,8 +2609,11 @@ 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)));
> + lexical_cookie_t lexc = lisp_file_lexical_cookie (buf);
> specbind (Qlexical_binding,
> - lisp_file_lexical_cookie (buf) == Cookie_Lex ? Qt : Qnil);
> + lexc == Cookie_Lex ? Qt
> + : lexc == Cookie_Dyn ? Qnil
> + : Fdefault_toplevel_value (Qlexical_binding));
> BUF_TEMP_SET_PT (XBUFFER (buf), BUF_BEGV (XBUFFER (buf)));
> readevalloop (buf, 0, filename,
> !NILP (printflag), unibyte, Qnil, Qnil, Qnil);
And here?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Fri, 01 Nov 2024 01:21:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 74145 <at> debbugs.gnu.org (full text, mbox):
Hi Stefan,
>> @@ -392,7 +392,7 @@ Void Variables
>> to evaluate the variable signals a @code{void-variable} error, instead
>> of returning a value.
>>
>> - Under the optional lexical scoping rule, the value cell only holds
>> + Under the optional lexical scoping rule, the value cell holds only
>> the variable's global value---the value outside of any lexical binding
>> construct. When a variable is lexically bound, the local value is
>> determined by the lexical environment; hence, variables can have local
>
> I think this section might need more work. It's a bit confusing to talk
> about "default dynamic scoping" and "optional lexical scoping" now.
> Shouldn't we talk about "normal variables with lexical scoping" and
> "special variables with dynamic scoping" or something along those lines?
Very good point, will take a closer look.
>> + (lexical-binding (default-toplevel-value 'lexical-binding)))
> Why not just use `t` here instead of its `default-toplevel-value`?
I "fixed" the code such that the default is set at exactly one place,
i.e. in `syms_of_lread`, but indeed it's not indispensable.
It's not super important, but it seemed cleaner.
It also makes it easy for users to "go back" to the nil default,
e.g. for testing purposes, or as a quick fix until you can track down
the `.el` files that need to be adjusted.
Stefan
Severity set to 'wishlist' from 'normal'
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Fri, 01 Nov 2024 01:26:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Fri, 01 Nov 2024 02:07:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 74145 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> I think this section might need more work. It's a bit confusing to talk
>> about "default dynamic scoping" and "optional lexical scoping" now.
>> Shouldn't we talk about "normal variables with lexical scoping" and
>> "special variables with dynamic scoping" or something along those lines?
>
> Very good point, will take a closer look.
Great, thanks.
Meanwhile, here's two more things I thought of:
- I think there's some text in doc/lispref/tips.texi that will need
updating too.
- Should we provide any advice somewhere for Emacs Lisp authors that
want to support Emacs 30 or older? For example, they will want to
keep the lexical-binding:t cookie.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Fri, 01 Nov 2024 03:08:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 74145 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Great, thanks.
Updated patch below.
> Meanwhile, here's two more things I thought of:
> - I think there's some text in doc/lispref/tips.texi that will need
> updating too.
I didn't think it necessary, but after taking another look at it,
I tweaked a few more things, indeed.
> - Should we provide any advice somewhere for Emacs Lisp authors that
> want to support Emacs 30 or older? For example, they will want to
> keep the lexical-binding:t cookie.
Currently, the doc recommends to add the cookie "everywhere", and my
patch doesn't really change that, so I think we're OK in this respect
(the new change in `tips.texi` does mention that the cookie is needed
only for compatibility with Emacs<31).
Stefan
[0001-Change-the-default-value-of-lexical-binding.patch (text/x-diff, inline)]
From e69585bfbca950bce14fb51db385a72f6ecb553d Mon Sep 17 00:00:00 2001
From: Stefan Monnier <monnier <at> iro.umontreal.ca>
Date: Thu, 31 Oct 2024 16:00:10 -0400
Subject: [PATCH] Change the default value of `lexical-binding`
* src/lread.c (syms_of_lread): Set `Vlexical_binding` to Qt.
(Fload, Feval_buffer): Don't assume the default value of
`lexical-binding` is nil.
* lisp/loadup.el: Don't assume the default value of `lexical-binding`
is nil.
* doc/misc/cl.texi (Porting Common Lisp):
* doc/lispref/tips.texi (Coding Conventions, Library Headers):
* doc/lispref/variables.texi (Variable Scoping, Selecting Lisp Dialect)
(Void Variables): Adjust to new default of `lexical-binding`.
* doc/lispref/edebug.texi (Edebug Eval): Remove out of date paragraph.
* doc/lispintro/emacs-lisp-intro.texi (How let Binds Variables)
(Lexical vs. Dynamic Binding Example, defvar): Only consider the
lexical dialect of ELisp.
---
doc/lispintro/emacs-lisp-intro.texi | 26 +++++++----------------
doc/lispref/edebug.texi | 7 ------
doc/lispref/tips.texi | 6 ++++--
doc/lispref/variables.texi | 33 +++++++++++++++--------------
doc/misc/cl.texi | 9 ++++----
etc/NEWS | 6 ++++++
lisp/loadup.el | 4 ++--
src/lread.c | 14 ++++++++----
8 files changed, 52 insertions(+), 53 deletions(-)
diff --git a/doc/lispintro/emacs-lisp-intro.texi b/doc/lispintro/emacs-lisp-intro.texi
index 49916235fbf..6cc7a5b3cf2 100644
--- a/doc/lispintro/emacs-lisp-intro.texi
+++ b/doc/lispintro/emacs-lisp-intro.texi
@@ -3754,21 +3754,12 @@ How let Binds Variables
Emacs Lisp supports two different ways of binding variable names to
their values. These ways affect the parts of your program where a
-particular binding is valid. For historical reasons, Emacs Lisp uses
-a form of variable binding called @dfn{dynamic binding} by default.
-However, in this manual we discuss the preferred form of binding,
-called @dfn{lexical binding}, unless otherwise noted (in the future,
-the Emacs maintainers plan to change the default to lexical binding).
+particular binding is valid.
+In this manual we discuss the preferred form of binding,
+called @dfn{lexical binding}, unless otherwise noted.
If you have programmed in other languages before, you're likely
already familiar with how lexical binding behaves.
-In order to use lexical binding in a program, you should add this to
-the first line of your Emacs Lisp file:
-
-@example
-;;; -*- lexical-binding: t -*-
-@end example
-
For more information about this, @pxref{Variable Scoping, , ,
elisp, The Emacs Lisp Reference Manual}.
@@ -3818,8 +3809,6 @@ Lexical vs. Dynamic Binding Example
For example, see what happens in this code under lexical binding:
@example
-;;; -*- lexical-binding: t -*-
-
(setq x 0)
(defun getx ()
@@ -3845,7 +3834,7 @@ Lexical vs. Dynamic Binding Example
If we use dynamic binding instead, the behavior is different:
@example
-;;; -*- lexical-binding: nil -*-
+(defvar x) ;; Use dynamic binding for 'x'.
(setq x 0)
@@ -3867,8 +3856,9 @@ Lexical vs. Dynamic Binding Example
@code{x}, since its binding is below the one from our @code{let}
expression in the stack of bindings.
-(Some variables are also ``special'', and they are always dynamically
-bound even when @code{lexical-binding} is @code{t}. @xref{defvar, ,
+(The @code{defvar} declaration above is said to make the variable
+``special'', which causes it to obey the dynamic binding rules instead of
+the default lexical binding rules. @xref{defvar, ,
Initializing a Variable with @code{defvar}}.)
@node if
@@ -9229,7 +9219,7 @@ defvar
The @code{defvar} special form is similar to @code{setq} in that it
sets the value of a variable. It is unlike @code{setq} in three ways:
first, it marks the variable as ``special'' so that it is always
-dynamically bound, even when @code{lexical-binding} is @code{t}
+dynamically bound
(@pxref{How let Binds Variables}). Second, it only sets the value of
the variable if the variable does not already have a value. If the
variable already has a value, @code{defvar} does not override the
diff --git a/doc/lispref/edebug.texi b/doc/lispref/edebug.texi
index 03fae67e528..fe617550b09 100644
--- a/doc/lispref/edebug.texi
+++ b/doc/lispref/edebug.texi
@@ -722,13 +722,6 @@ Edebug Eval
pretty-printed in a separate buffer.
@end table
-@cindex lexical binding (Edebug)
- Edebug supports evaluation of expressions containing references to
-lexically bound symbols created by the following constructs in
-@file{cl.el}: @code{lexical-let}, @code{macrolet}, and
-@code{symbol-macrolet}.
-@c FIXME? What about lexical-binding = t?
-
@node Eval List
@subsection Evaluation List Buffer
diff --git a/doc/lispref/tips.texi b/doc/lispref/tips.texi
index 14eabb3558f..2b1b79a7f4f 100644
--- a/doc/lispref/tips.texi
+++ b/doc/lispref/tips.texi
@@ -96,7 +96,7 @@ Coding Conventions
alternative common prefixes, so long as they make sense.
@item
-We recommend enabling @code{lexical-binding} in new code, and
+We recommend not disabling @code{lexical-binding} in new code, and
converting existing Emacs Lisp code to enable @code{lexical-binding}
if it doesn't already. @xref{Selecting Lisp Dialect}.
@@ -1082,7 +1082,9 @@ Library Headers
@end example
@noindent
-The description should be contained in one line. If the file needs to
+The description should be contained in one line.
+The @code{lexical-binding} is not necessary if you do not care about
+compatibility with Emacs<31. If the file needs to
set more variables in the @samp{-*-} specification, add it after
@code{lexical-binding}. If this would make the first line too long, use
a Local Variables section at the end of the file.
diff --git a/doc/lispref/variables.texi b/doc/lispref/variables.texi
index af11e498d86..d4b179003e3 100644
--- a/doc/lispref/variables.texi
+++ b/doc/lispref/variables.texi
@@ -285,7 +285,7 @@ Local Variables
@defspec letrec (bindings <at> dots{}) forms <at> dots{}
This special form is like @code{let*}, but all the variables are bound
before any of the local values are computed. The values are then
-assigned to the locally bound variables. This is only useful when
+assigned to the locally bound variables. This is useful only when
lexical binding is in effect, and you want to create closures that
refer to bindings that would otherwise not yet be in effect when using
@code{let*}.
@@ -351,7 +351,7 @@ Local Variables
done so that the value returned by the call is the value of @var{body}
itself, as is the case in the recursive call to @code{sum} above.
-@code{named-let} can only be used when lexical-binding is enabled.
+@code{named-let} can be used only when lexical-binding is enabled.
@xref{Lexical Binding}.
@end defspec
@@ -383,7 +383,7 @@ Void Variables
We say that a variable is void if its symbol has an unassigned value
cell (@pxref{Symbol Components}).
- Under Emacs Lisp's default dynamic scoping rule (@pxref{Variable
+ Under Emacs Lisp's dynamic scoping rule (@pxref{Variable
Scoping}), the value cell stores the variable's current (local or
global) value. Note that an unassigned value cell is @emph{not} the
same as having @code{nil} in the value cell. The symbol @code{nil} is
@@ -392,7 +392,7 @@ Void Variables
to evaluate the variable signals a @code{void-variable} error, instead
of returning a value.
- Under the optional lexical scoping rule, the value cell only holds
+ Under the lexical scoping rule, the value cell holds only
the variable's global value---the value outside of any lexical binding
construct. When a variable is lexically bound, the local value is
determined by the lexical environment; hence, variables can have local
@@ -514,7 +514,7 @@ Defining Variables
Note that specifying a value, even @code{nil}, marks the variable as
special permanently. Whereas if @var{value} is omitted then the
-variable is only marked special locally (i.e.@: within the current
+variable is marked special only locally (i.e.@: within the current
lexical scope, or file if at the top-level). This can be useful for
suppressing byte compilation warnings, see @ref{Compiler Errors}.
@@ -706,8 +706,8 @@ Accessing Variables
The usual way to reference a variable is to write the symbol which
names it. @xref{Symbol Forms}.
- Occasionally, you may want to reference a variable which is only
-determined at run time. In that case, you cannot specify the variable
+ Occasionally, you may want to reference a variable which is determined
+only at run time. In that case, you cannot specify the variable
name in the text of the program. You can use the @code{symbol-value}
function to extract the value.
@@ -1003,14 +1003,15 @@ Variable Scoping
while the binding construct (such as the body of a @code{let} form) is
being executed.
- The old dynamic-only Emacs Lisp dialect is still the default in code
+ The new lexically scoped Emacs Lisp dialect is now the default in code
loaded or evaluated from Lisp files that lack a dialect declaration.
-Eventually the modern dialect will be made the default.
-All Lisp files should declare the dialect used to ensure that they
-keep working correctly in the future.
+Lisp files which still need the old dynamically scoped dialect need to declare
+it explicitly to ensure that they keep working correctly, and should
+eventually be converted to use the new dialect to
+ensure that they keep working correctly in the future.
The following subsections describe lexical binding and dynamic
-binding in greater detail, and how to enable lexical binding in Emacs
+binding in greater detail, and how to disable lexical binding in Emacs
Lisp programs.
@menu
@@ -1319,8 +1320,8 @@ Selecting Lisp Dialect
@noindent
for the old dynamic-only dialect. When no declaration is present the
-old dialect is used, but this may change in a future release.
-The compiler will warn if no declaration is present.
+new dialect is used. Support for the old dialect may be removed in
+a future release.
When evaluating Emacs Lisp code directly using an @code{eval} call,
lexical binding is enabled if the @var{lexical} argument to
@@ -1980,8 +1981,8 @@ File Local Variables
@defvar permanently-enabled-local-variables
Some local variable settings will, by default, be heeded even if
-@code{enable-local-variables} is @code{nil}. By default, this is only
-the case for the @code{lexical-binding} local variable setting, but
+@code{enable-local-variables} is @code{nil}. By default, this is the
+case only for the @code{lexical-binding} local variable setting, but
this can be controlled by using this variable, which is a list of
symbols.
@end defvar
diff --git a/doc/misc/cl.texi b/doc/misc/cl.texi
index 113029700ec..395725944f0 100644
--- a/doc/misc/cl.texi
+++ b/doc/misc/cl.texi
@@ -4758,12 +4758,13 @@ Porting Common Lisp
@item
Lexical scoping. In Common Lisp, function arguments and @code{let}
bindings apply only to references physically within their bodies (or
-within macro expansions in their bodies). Traditionally, Emacs Lisp
-uses @dfn{dynamic scoping} wherein a binding to a variable is visible
+within macro expansions in their bodies). The is also the case in
+modern Emacs Lisp, but historically, Emacs Lisp
+used @dfn{dynamic scoping} wherein a binding to a variable is visible
even inside functions called from the body.
@xref{Dynamic Binding,,,elisp,GNU Emacs Lisp Reference Manual}.
-Lexical binding is available since Emacs 24.1, so be sure to set
-@code{lexical-binding} to @code{t} if you need to emulate this aspect
+Lexical binding is available since Emacs 24.1, but be sure not to set
+@code{lexical-binding} to @code{nil} if you need to emulate this aspect
of Common Lisp. @xref{Lexical Binding,,,elisp,GNU Emacs Lisp Reference Manual}.
Here is an example of a Common Lisp code fragment that would fail in
diff --git a/etc/NEWS b/etc/NEWS
index d1c7303f976..5a480c5f68a 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -636,6 +636,12 @@ the directory into which the repository was cloned.
* Incompatible Lisp Changes in Emacs 31.1
++++
+** 'lexical-binding' now defaults to t.
+The default ELisp dialect is now the lexically scoped dialect.
+Any code which has not yet been adapted should either be
+adapted or set 'lexical-binding' to nil explicitly.
+
** Nested backquotes are not supported any more in Pcase patterns.
** The 'rx' category name 'chinese-two-byte' must now be spelled correctly.
diff --git a/lisp/loadup.el b/lisp/loadup.el
index bd74a9d6aff..e676c338c14 100644
--- a/lisp/loadup.el
+++ b/lisp/loadup.el
@@ -654,9 +654,9 @@ comp-subr-arities-h
(unwind-protect
(let ((tmp-dump-mode dump-mode)
(dump-mode nil)
- ;; Set `lexical-binding' to nil by default
+ ;; Set `lexical-binding' to its default value
;; in the dumped Emacs.
- (lexical-binding nil))
+ (lexical-binding (default-toplevel-value 'lexical-binding)))
(if (member tmp-dump-mode '("pdump" "pbootstrap"))
(dump-emacs-portable (expand-file-name output invocation-directory))
(dump-emacs output (if (eq system-type 'ms-dos)
diff --git a/src/lread.c b/src/lread.c
index ea0398196e3..9f56880e551 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -1522,7 +1522,7 @@ DEFUN ("load", Fload, Sload, 1, 5, 0,
otherwise using a file-variable in the first line. This is bound here
so that it takes effect whether or not we use
Vload_source_file_function. */
- specbind (Qlexical_binding, Qnil);
+ specbind (Qlexical_binding, Fdefault_toplevel_value (Qlexical_binding));
Lisp_Object found_eff =
is_native_elisp
@@ -1720,8 +1720,11 @@ DEFUN ("load", Fload, Sload, 1, 5, 0,
}
else
{
- if (lisp_file_lexical_cookie (Qget_file_char) == Cookie_Lex)
+ lexical_cookie_t lexc = lisp_file_lexical_cookie (Qget_file_char);
+ if (lexc == Cookie_Lex)
Fset (Qlexical_binding, Qt);
+ else if (lexc == Cookie_Dyn)
+ Fset (Qlexical_binding, Qnil);
if (! version || version >= 22)
readevalloop (Qget_file_char, &input, hist_file_name,
@@ -2606,8 +2609,11 @@ 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)));
+ lexical_cookie_t lexc = lisp_file_lexical_cookie (buf);
specbind (Qlexical_binding,
- lisp_file_lexical_cookie (buf) == Cookie_Lex ? Qt : Qnil);
+ lexc == Cookie_Lex ? Qt
+ : lexc == Cookie_Dyn ? Qnil
+ : Fdefault_toplevel_value (Qlexical_binding));
BUF_TEMP_SET_PT (XBUFFER (buf), BUF_BEGV (XBUFFER (buf)));
readevalloop (buf, 0, filename,
!NILP (printflag), unibyte, Qnil, Qnil, Qnil);
@@ -6056,7 +6062,7 @@ syms_of_lread (void)
This variable is automatically set from the file variables of an
interpreted Lisp file read using `load'. Unlike other file local
variables, this must be set in the first line of a file. */);
- Vlexical_binding = Qnil;
+ Vlexical_binding = Qt;
Fmake_variable_buffer_local (Qlexical_binding);
DEFVAR_LISP ("eval-buffer-list", Veval_buffer_list,
--
2.39.5
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Fri, 01 Nov 2024 07:08:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> Cc: monnier <at> iro.umontreal.ca
> Date: Thu, 31 Oct 2024 16:57:57 -0400
> From: Stefan Monnier via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> I believe the time has come to change the default dialect.
> I attached a suggested patch to do that.
Thanks, but this kind of change cannot be discussed here. Please
start a discussion on emacs-devel, and please include in your
suggestion the description of the effects of this change on various
parts of Emacs and third-party package. We need to give the community
ample time and opportunity to discuss those effects and express
opinions, before we install something like that. In particular, any
objections should be taken very seriously, and perhaps some follow-up
measures should be included in the changeset to make the transition
smoother and easier.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Fri, 01 Nov 2024 15:39:01 GMT)
Full text and
rfc822 format available.
Message #25 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> Thanks, but this kind of change cannot be discussed here. Please
> start a discussion on emacs-devel, and please include in your
I posted something there, but to be honest at this point I don't think
discussion is going to be useful.
Also, I'm doing this now, i.e. early in the Emacs-31 development cycle,
so that we get a chance to get as much feedback as possible before
committing to it in a release: the patch is easy to revert since (beside the
doc) it's a matter of changing
Vlexical_binding = Qt;
back to
Vlexical_binding = Qnil;
> In particular, any objections should be taken very seriously,
I'm not sure what that means concretely.
> and perhaps some follow-up measures should be included in the
> changeset to make the transition smoother and easier.
I think we've already done about as much as we could over the past
several years. Maybe after installing the patch we will discover new
cases which warrant further changes, but I doubt we'll be able to figure
that out via discussions on emacs-devel.
Stefan
Added tag(s) patch.
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Sun, 03 Nov 2024 05:48:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Mon, 04 Nov 2024 05:37:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 74145 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> We need to give the community
> ample time and opportunity to discuss those effects and express
> opinions, before we install something like that. In particular, any
> objections should be taken very seriously, and perhaps some follow-up
> measures should be included in the changeset to make the transition
> smoother and easier.
Hear, hear. We ought to this in the way that is most gentle to the
users.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Sat, 28 Dec 2024 17:42:02 GMT)
Full text and
rfc822 format available.
Message #33 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> I believe the time has come to change the default dialect.
Agreed, the sooner the better. (Sorry about the delay; I'm trying to catch up.)
The compilation warning about missing lexical-binding declaration is still there which makes sense. Eventually it should be removed but it's not urgent to plan for it now.
The patch looks fine. Some very minor comments (that you can ignore):
> - The old dynamic-only Emacs Lisp dialect is still the default in code
> + The new lexically scoped Emacs Lisp dialect is now the default in code
Maybe do away with the 'new' and 'now' here -- I think the documentation should describe Emacs as it is, and NEWS have the changes.
> for the old dynamic-only dialect. When no declaration is present the
> -old dialect is used, but this may change in a future release.
> -The compiler will warn if no declaration is present.
> +new dialect is used. Support for the old dialect may be removed in
> +a future release.
Well, the compiler still warns, as it should, so this isn't quite accurate.
>
> +** 'lexical-binding' now defaults to t.
> +The default ELisp dialect is now the lexically scoped dialect.
> +Any code which has not yet been adapted should either be
> +adapted or set 'lexical-binding' to nil explicitly.
Maybe mention that the cookie warning is still there?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Mon, 30 Dec 2024 04:13:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 74145 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > for the old dynamic-only dialect. When no declaration is present the
> > -old dialect is used, but this may change in a future release.
> > -The compiler will warn if no declaration is present.
> > +new dialect is used. Support for the old dialect may be removed in
> > +a future release.
We should delete that last sentence.
It would be a mistake to delete support for lexical-binding: nil, even
20 years from now.
To convert a program from dynamic binding to lexical binding is not a
trivial transformatoin -- it requires actually understanding the code.
It would be bad judgment to require people to do that work for their
old programs merely to simplify one small piece of the language.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Fri, 14 Feb 2025 16:54:02 GMT)
Full text and
rfc822 format available.
Message #39 received at 74145 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> I believe the time has come to change the default dialect.
> I attached a suggested patch to do that.
OK, before we change the default, I propose the patch below, which
should not change the behavior at all, but allows users to
(set-default-toplevel-value 'lexical-binding t)
IOW. It does "everything" the previous patch did except actually change
the default. The remaining step is to change the single line that sets
the default (currently to nil, then to t) and update the docs.
Any objection?
Stefan
[lexical-binding.patch (text/x-diff, inline)]
diff --git a/doc/lispintro/emacs-lisp-intro.texi b/doc/lispintro/emacs-lisp-intro.texi
index b041678d8c8..1d60c6b0f88 100644
--- a/doc/lispintro/emacs-lisp-intro.texi
+++ b/doc/lispintro/emacs-lisp-intro.texi
@@ -3845,7 +3845,7 @@ Lexical vs Dynamic Binding Example
If we use dynamic binding instead, the behavior is different:
@example
-;;; -*- lexical-binding: nil -*-
+(defvar x) ;; Use dynamic binding for 'x'.
(setq x 0)
@@ -3867,8 +3867,9 @@ Lexical vs Dynamic Binding Example
@code{x}, since its binding is below the one from our @code{let}
expression in the stack of bindings.
-(Some variables are also ``special'', and they are always dynamically
-bound even when @code{lexical-binding} is @code{t}. @xref{defvar, ,
+(The @code{defvar} declaration above is said to make the variable
+``special'', which causes it to obey the dynamic binding rules instead of
+the default binding rules. @xref{defvar, ,
Initializing a Variable with @code{defvar}}.)
@node if
diff --git a/doc/lispref/edebug.texi b/doc/lispref/edebug.texi
index e234db6fce5..15836591032 100644
--- a/doc/lispref/edebug.texi
+++ b/doc/lispref/edebug.texi
@@ -722,13 +722,6 @@ Edebug Eval
pretty-printed in a separate buffer.
@end table
-@cindex lexical binding (Edebug)
- Edebug supports evaluation of expressions containing references to
-lexically bound symbols created by the following constructs in
-@file{cl.el}: @code{lexical-let}, @code{macrolet}, and
-@code{symbol-macrolet}.
-@c FIXME? What about lexical-binding = t?
-
@node Eval List
@subsection Evaluation List Buffer
diff --git a/doc/lispref/variables.texi b/doc/lispref/variables.texi
index 89ccb8ea740..998a74d067a 100644
--- a/doc/lispref/variables.texi
+++ b/doc/lispref/variables.texi
@@ -285,7 +285,7 @@ Local Variables
@defspec letrec (bindings <at> dots{}) forms <at> dots{}
This special form is like @code{let*}, but all the variables are bound
before any of the local values are computed. The values are then
-assigned to the locally bound variables. This is only useful when
+assigned to the locally bound variables. This is useful only when
lexical binding is in effect, and you want to create closures that
refer to bindings that would otherwise not yet be in effect when using
@code{let*}.
@@ -351,7 +351,7 @@ Local Variables
done so that the value returned by the call is the value of @var{body}
itself, as is the case in the recursive call to @code{sum} above.
-@code{named-let} can only be used when lexical-binding is enabled.
+@code{named-let} can be used only when lexical-binding is enabled.
@xref{Lexical Binding}.
@end defspec
@@ -392,7 +392,7 @@ Void Variables
to evaluate the variable signals a @code{void-variable} error, instead
of returning a value.
- Under the optional lexical scoping rule, the value cell only holds
+ Under the optional lexical scoping rule, the value cell holds only
the variable's global value---the value outside of any lexical binding
construct. When a variable is lexically bound, the local value is
determined by the lexical environment; hence, variables can have local
@@ -710,8 +710,8 @@ Accessing Variables
The usual way to reference a variable is to write the symbol which
names it. @xref{Symbol Forms}.
- Occasionally, you may want to reference a variable which is only
-determined at run time. In that case, you cannot specify the variable
+ Occasionally, you may want to reference a variable which is determined
+only at run time. In that case, you cannot specify the variable
name in the text of the program. You can use the @code{symbol-value}
function to extract the value.
@@ -1991,8 +1991,8 @@ File Local Variables
@defvar permanently-enabled-local-variables
Some local variable settings will, by default, be heeded even if
-@code{enable-local-variables} is @code{nil}. By default, this is only
-the case for the @code{lexical-binding} local variable setting, but
+@code{enable-local-variables} is @code{nil}. By default, this is the
+case only for the @code{lexical-binding} local variable setting, but
this can be controlled by using this variable, which is a list of
symbols.
@end defvar
diff --git a/lisp/loadup.el b/lisp/loadup.el
index 98a47f2867f..ebd35291050 100644
--- a/lisp/loadup.el
+++ b/lisp/loadup.el
@@ -617,9 +617,9 @@ comp-subr-arities-h
(unwind-protect
(let ((tmp-dump-mode dump-mode)
(dump-mode nil)
- ;; Set `lexical-binding' to nil by default
+ ;; Set `lexical-binding' to its default value
;; in the dumped Emacs.
- (lexical-binding nil))
+ (lexical-binding (default-toplevel-value 'lexical-binding)))
(if (member tmp-dump-mode '("pdump" "pbootstrap"))
(dump-emacs-portable (expand-file-name output invocation-directory))
(dump-emacs output (if (eq system-type 'ms-dos)
diff --git a/src/lread.c b/src/lread.c
index 46c705e5c76..df1caaf5732 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -1720,8 +1720,11 @@ DEFUN ("load", Fload, Sload, 1, 5, 0,
}
else
{
- if (lisp_file_lexical_cookie (Qget_file_char) == Cookie_Lex)
- Fset (Qlexical_binding, Qt);
+ lexical_cookie_t lexc = lisp_file_lexical_cookie (Qget_file_char);
+ Fset (Qlexical_binding,
+ (lexc == Cookie_Lex ? Qt
+ : lexc == Cookie_Dyn ? Qnil
+ : Fdefault_toplevel_value (Qlexical_binding)));
if (! version || version >= 22)
readevalloop (Qget_file_char, &input, hist_file_name,
@@ -2606,8 +2609,11 @@ 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)));
+ lexical_cookie_t lexc = lisp_file_lexical_cookie (buf);
specbind (Qlexical_binding,
- lisp_file_lexical_cookie (buf) == Cookie_Lex ? Qt : Qnil);
+ lexc == Cookie_Lex ? Qt
+ : lexc == Cookie_Dyn ? Qnil
+ : Fdefault_toplevel_value (Qlexical_binding));
BUF_TEMP_SET_PT (XBUFFER (buf), BUF_BEGV (XBUFFER (buf)));
readevalloop (buf, 0, filename,
!NILP (printflag), unibyte, Qnil, Qnil, Qnil);
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Fri, 14 Feb 2025 18:13:01 GMT)
Full text and
rfc822 format available.
Message #42 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> Sent: Saturday, February 15, 2025 at 4:53 AM
> From: "Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> To: 74145 <at> debbugs.gnu.org
> Subject: bug#74145: 31.0.50; Default lexical-binding to t
>
> > I believe the time has come to change the default dialect.
> > I attached a suggested patch to do that.
>
> OK, before we change the default, I propose the patch below, which
> should not change the behavior at all, but allows users to
>
> (set-default-toplevel-value 'lexical-binding t)
>
> IOW. It does "everything" the previous patch did except actually change
> the default. The remaining step is to change the single line that sets
> the default (currently to nil, then to t) and update the docs.
>
> Any objection? > Stefan
;; ---------------------------------------------------------------
In the swirling chaos of modern existence, we find ourselves shackled
by an insidious disease - the inability to truly transform. Claiming
to do everything except actually change the default, is a perfect
encapsulation of this malaise. It’s a farce wrapped in the pretense
of progress, a cruel joke played on the hopeful souls who dare to believe
that anything can be different.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Sat, 15 Feb 2025 03:29:02 GMT)
Full text and
rfc822 format available.
Message #45 received at 74145 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> I believe the time has come to change the default dialect.
>> I attached a suggested patch to do that.
>
> OK, before we change the default, I propose the patch below, which
> should not change the behavior at all, but allows users to
>
> (set-default-toplevel-value 'lexical-binding t)
>
> IOW. It does "everything" the previous patch did except actually change
> the default. The remaining step is to change the single line that sets
> the default (currently to nil, then to t) and update the docs.
>
> Any objection?
Makes sense to me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Sun, 16 Feb 2025 23:52:02 GMT)
Full text and
rfc822 format available.
Message #48 received at 74145 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
Someone else wrote:
> > I believe the time has come to change the default dialect.
> > I attached a suggested patch to do that.
Certainly not! That would be too abrupt.
By contrast, your proposed change
> OK, before we change the default, I propose the patch below, which
> should not change the behavior at all, but allows users to
> (set-default-toplevel-value 'lexical-binding t)
is a step along a reasonable path. It won't impose anything on anyone
immediately, but it will encourage users to try this out and report
problems.
One always looks forward to reaching the end of a series of changes
planned to reach an intended destination. But if we want to do a good
job for the users, we must not rush them.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Mon, 17 Feb 2025 02:13:02 GMT)
Full text and
rfc822 format available.
Message #51 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> > > I believe the time has come to change the default dialect.
> > > I attached a suggested patch to do that.
>
> Certainly not! That would be too abrupt.
> By contrast, your proposed change
>
> > OK, before we change the default, I propose the patch below, which
> > should not change the behavior at all, but allows users to
>
> > (set-default-toplevel-value 'lexical-binding t)
>
> is a step along a reasonable path. It won't impose anything on anyone
> immediately, but it will encourage users to try this out and report
> problems.
The difference between the two, for users, is whether they need
(set-default-toplevel-value 'lexical-binding t)
to get the new setup or
(set-default-toplevel-value 'lexical-binding nil)
to continue with the old setup.
It's a small enough difference that I don't think it justifies
describing one as "reasonable path" and the other as "too abrupt".
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Mon, 17 Feb 2025 09:17:01 GMT)
Full text and
rfc822 format available.
Message #54 received at 74145 <at> debbugs.gnu.org (full text, mbox):
On 2025-02-16 18:50, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> Someone else wrote:
>
> > > I believe the time has come to change the default dialect.
> > > I attached a suggested patch to do that.
>
> Certainly not! That would be too abrupt.
>
> By contrast, your proposed change
>
> > OK, before we change the default, I propose the patch below, which
> > should not change the behavior at all, but allows users to
>
> > (set-default-toplevel-value 'lexical-binding t)
>
> is a step along a reasonable path. It won't impose anything on anyone
> immediately, but it will encourage users to try this out and report
> problems.
>
> One always looks forward to reaching the end of a series of changes
> planned to reach an intended destination. But if we want to do a good
> job for the users, we must not rush them.
It's been many years now. Everyone has had enough time to adapt to
lexical-binding.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Tue, 18 Feb 2025 11:02:02 GMT)
Full text and
rfc822 format available.
Message #57 received at 74145 <at> debbugs.gnu.org (full text, mbox):
dancol wrote:
> It's been many years now. Everyone has had enough time to adapt to
> lexical-binding.
I'm sure a majority of elisp programmers are aware of lexical-binding
by this point, and (in a great many cases) have adapted to it; but,
with the exception of those who are following current developments,
nobody has had ANY time to adapt to the idea that lexical-binding is
the DEFAULT. Users having time to adapt to THAT begins with the first
release that warns that it's going to happen, and we haven't had one
of those yet.
Even the users who understand Emacs Lisp should have advance warning
of such a change so that they can make the necessary changes in
advance of that change coming into effect.
Emacs is not only used by elisp programmers, though. Many users don't
understand elisp; will not understand dynamic-vs-lexical binding; and
will not know why the libraries they have been using for many years
suddenly don't work properly.
Those users should be informed that they need to change something
before it has a chance to break things, so this should be sign-posted
for a long time in advance of the actual change, so that users really
do have time to adapt.
Consider users who are running Ubuntu 24.04 GNU/Linux as their OS
(being a popular OS with long-term support). That OS release is
supported for 5 years as standard, and it provides Emacs 29. So a lot
of those users will be running Emacs 29 with dynamic binding as the
default until 2029, and when they update their OS in 2029 and acquire,
say, Emacs 31, it would be beneficial if their Emacs config wasn't
suddenly broken on account of something they'd had no prior warning
about.
(There may or may not be other breaking changes, but IMHO this
doesn't need to be one of them.)
I'm not seeing a cost/benefit analysis in favour of making this change
sooner. The risk of changing it sooner is that we cause some users
pain by breaking things without warning, whereas (so far as I can see)
the only benefit of making the change earlier would be that elisp
authors could choose to stop including a file-local variable in their
elisp files -- something those authors are fully-aware they need to do
(and which is quite probably being done for them automatically via
autoinsert.el or similar).
So I see no notable benefit to making this change in a hurry, but I do
see a cost. I think we're contrasting an extremely minor convenience
for elisp authors against a real inconvenience for any users who get
affected by it. My feeling is that Emacs 30 should start issuing
warnings, which could be made more severe in Emacs 31, and that the
change itself shouldn't happen earlier than 2029 to align with some of
the popular OS support cycles.
I don't understand why we'd want to enact such a significant change
without at least that much warning, given how little we gain from it.
-Phil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Tue, 18 Feb 2025 11:56:02 GMT)
Full text and
rfc822 format available.
Message #60 received at 74145 <at> debbugs.gnu.org (full text, mbox):
[புதன் பிப்ரவரி 19, 2025] Phil Sainty wrote:
> dancol wrote:
>> It's been many years now. Everyone has had enough time to adapt to
>> lexical-binding.
>
> I'm sure a majority of elisp programmers are aware of lexical-binding
> by this point, and (in a great many cases) have adapted to it; but,
> with the exception of those who are following current developments,
> nobody has had ANY time to adapt to the idea that lexical-binding is
> the DEFAULT. Users having time to adapt to THAT begins with the first
> release that warns that it's going to happen, and we haven't had one
> of those yet.
>
> Even the users who understand Emacs Lisp should have advance warning
> of such a change so that they can make the necessary changes in
> advance of that change coming into effect.
>
> Emacs is not only used by elisp programmers, though. Many users don't
> understand elisp; will not understand dynamic-vs-lexical binding; and
> will not know why the libraries they have been using for many years
> suddenly don't work properly.
>
> Those users should be informed that they need to change something
> before it has a chance to break things, so this should be sign-posted
> for a long time in advance of the actual change, so that users really
> do have time to adapt.
+1. It is also a bit time consuming to change code to follow lexical
binding and AFAIU from reading the list, there is no straightforward way
to do so. Despite that, I hope there could be some addition to the
manual to outline the rough pathway one may follow. If not possible,
then at least some tricks or trips to ensure that one has successfully
changed the code to follow lexical binding for the most part. Any bugs
hidden would be uncovered soon enough with regular usage of the
converted code.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Tue, 18 Feb 2025 12:21:01 GMT)
Full text and
rfc822 format available.
Message #63 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> Sent: Tuesday, February 18, 2025 at 11:55 PM
> From: "Visuwesh" <visuweshm <at> gmail.com>
> To: "Phil Sainty" <psainty <at> orcon.net.nz>
> Cc: dancol <at> dancol.org, 74145 <at> debbugs.gnu.org
> Subject: bug#74145: 31.0.50; Default lexical-binding to t
>
> [புதன் பிப்ரவரி 19, 2025] Phil Sainty wrote:
>
> > dancol wrote:
> >> It's been many years now. Everyone has had enough time to adapt to
> >> lexical-binding.
> >
> > I'm sure a majority of elisp programmers are aware of lexical-binding
> > by this point, and (in a great many cases) have adapted to it; but,
> > with the exception of those who are following current developments,
> > nobody has had ANY time to adapt to the idea that lexical-binding is
> > the DEFAULT. Users having time to adapt to THAT begins with the first
> > release that warns that it's going to happen, and we haven't had one
> > of those yet.
> >
> > Even the users who understand Emacs Lisp should have advance warning
> > of such a change so that they can make the necessary changes in
> > advance of that change coming into effect.
> >
> > Emacs is not only used by elisp programmers, though. Many users don't
> > understand elisp; will not understand dynamic-vs-lexical binding; and
> > will not know why the libraries they have been using for many years
> > suddenly don't work properly.
> >
> > Those users should be informed that they need to change something
> > before it has a chance to break things, so this should be sign-posted
> > for a long time in advance of the actual change, so that users really
> > do have time to adapt.
>
> +1. It is also a bit time consuming to change code to follow lexical
> binding and AFAIU from reading the list, there is no straightforward way
> to do so.
Not taking the time to do the change is no excuse. Perhaps they can use
an older emacs release so that they continue what they were doing, and
concurrently doing the changes.
> Despite that, I hope there could be some addition to the
> manual to outline the rough pathway one may follow. If not possible,
> then at least some tricks or trips to ensure that one has successfully
> changed the code to follow lexical binding for the most part. Any bugs
> hidden would be uncovered soon enough with regular usage of the
> converted code.
>
>
>
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Tue, 18 Feb 2025 15:23:01 GMT)
Full text and
rfc822 format available.
Message #66 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> Cc: dancol <at> dancol.org, 74145 <at> debbugs.gnu.org
> From: Visuwesh <visuweshm <at> gmail.com>
> Date: Tue, 18 Feb 2025 17:25:45 +0530
>
> +1. It is also a bit time consuming to change code to follow lexical
> binding and AFAIU from reading the list, there is no straightforward way
> to do so. Despite that, I hope there could be some addition to the
> manual to outline the rough pathway one may follow.
I asked about that, and got the answer that it was impossible.
> If not possible, then at least some tricks or trips to ensure that
> one has successfully changed the code to follow lexical binding for
> the most part.
I think I got the same answer to that, too.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Tue, 18 Feb 2025 16:08:02 GMT)
Full text and
rfc822 format available.
Message #69 received at 74145 <at> debbugs.gnu.org (full text, mbox):
[செவ்வாய் பிப்ரவரி 18, 2025] Eli Zaretskii wrote:
>> Cc: dancol <at> dancol.org, 74145 <at> debbugs.gnu.org
>> From: Visuwesh <visuweshm <at> gmail.com>
>> Date: Tue, 18 Feb 2025 17:25:45 +0530
>>
>> +1. It is also a bit time consuming to change code to follow lexical
>> binding and AFAIU from reading the list, there is no straightforward way
>> to do so. Despite that, I hope there could be some addition to the
>> manual to outline the rough pathway one may follow.
>
> I asked about that, and got the answer that it was impossible.
>
>> If not possible, then at least some tricks or trips to ensure that
>> one has successfully changed the code to follow lexical binding for
>> the most part.
>
> I think I got the same answer to that, too.
Yes, I remember reading these answers. IMO "put the lexical-binding
cookie and try to compile" is at least a starter, having recently
followed it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Tue, 18 Feb 2025 16:54:02 GMT)
Full text and
rfc822 format available.
Message #72 received at 74145 <at> debbugs.gnu.org (full text, mbox):
>> +1. It is also a bit time consuming to change code to follow lexical
>> binding and AFAIU from reading the list, there is no straightforward way
>> to do so. Despite that, I hope there could be some addition to the
>> manual to outline the rough pathway one may follow.
>
> I asked about that, and got the answer that it was impossible.
This said, we do have
@node Converting to Lexical Binding
@subsection Converting to Lexical Binding
in `variables.texi`.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Tue, 18 Feb 2025 17:28:02 GMT)
Full text and
rfc822 format available.
Message #75 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Visuwesh <visuweshm <at> gmail.com>, psainty <at> orcon.net.nz,
> dancol <at> dancol.org, 74145 <at> debbugs.gnu.org
> Date: Tue, 18 Feb 2025 11:53:45 -0500
>
> >> +1. It is also a bit time consuming to change code to follow lexical
> >> binding and AFAIU from reading the list, there is no straightforward way
> >> to do so. Despite that, I hope there could be some addition to the
> >> manual to outline the rough pathway one may follow.
> >
> > I asked about that, and got the answer that it was impossible.
>
> This said, we do have
>
> @node Converting to Lexical Binding
> @subsection Converting to Lexical Binding
>
> in `variables.texi`.
Yes, but the problem is not that there's no such place, the problem is
with what it says. Basically, it says "use it and fix any problems
you find" (and yes, I know that every summary comes with a
simplification that sometimes does injustice to the original text).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Tue, 18 Feb 2025 18:02:02 GMT)
Full text and
rfc822 format available.
Message #78 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> Yes, but the problem is not that there's no such place, the problem is
> with what it says. Basically, it says "use it and fix any problems
> you find".
But at least it gives you the steps to take and presumably you (the
author of the code who presumably knows what's going on in that code)
should know how to fix the problems.
Are you worried about those cases where the users don't actually know
what the code should do (although they may have written it themselves)?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Tue, 18 Feb 2025 19:00:04 GMT)
Full text and
rfc822 format available.
Message #81 received at 74145 <at> debbugs.gnu.org (full text, mbox):
Visuwesh <visuweshm <at> gmail.com> writes:
> [புதன் பிப்ரவரி 19, 2025] Phil Sainty wrote:
>
>> dancol wrote:
>>> It's been many years now. Everyone has had enough time to adapt to
>>> lexical-binding.
>>
>> I'm sure a majority of elisp programmers are aware of lexical-binding
>> by this point, and (in a great many cases) have adapted to it; but,
>> with the exception of those who are following current developments,
>> nobody has had ANY time to adapt to the idea that lexical-binding is
>> the DEFAULT. Users having time to adapt to THAT begins with the first
>> release that warns that it's going to happen, and we haven't had one
>> of those yet.
>>
>> Even the users who understand Emacs Lisp should have advance warning
>> of such a change so that they can make the necessary changes in
>> advance of that change coming into effect.
>>
>> Emacs is not only used by elisp programmers, though. Many users don't
>> understand elisp; will not understand dynamic-vs-lexical binding; and
>> will not know why the libraries they have been using for many years
>> suddenly don't work properly.
>>
>> Those users should be informed that they need to change something
>> before it has a chance to break things, so this should be sign-posted
>> for a long time in advance of the actual change, so that users really
>> do have time to adapt.
>
> +1. It is also a bit time consuming to change code to follow lexical
> binding and AFAIU from reading the list, there is no straightforward way
> to do so.
This change is unlikely to be very disruptive at this point. For
starters, users can easily just add this to any ELisp file that lacks it
and move on with their lives:
-*- lexical-binding:nil -*-
This is a trivial exercise for an Emacs user of almost any skill level.
We could consider providing Emacs commands and/or awk scripts to make
this even easier, but I'm not convinced that we even need that. It
can't hurt, I suppose.
What's more, and this is from my personal experience of converting
hundreds of .el files (see git log), most files will usually run just
fine under lexbind, without any changes. I expect that user init files
will typically fall into this category.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Tue, 18 Feb 2025 20:07:02 GMT)
Full text and
rfc822 format available.
Message #84 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: visuweshm <at> gmail.com, psainty <at> orcon.net.nz, dancol <at> dancol.org,
> 74145 <at> debbugs.gnu.org
> Date: Tue, 18 Feb 2025 13:00:59 -0500
>
> > Yes, but the problem is not that there's no such place, the problem is
> > with what it says. Basically, it says "use it and fix any problems
> > you find".
>
> But at least it gives you the steps to take and presumably you (the
> author of the code who presumably knows what's going on in that code)
> should know how to fix the problems.
>
> Are you worried about those cases where the users don't actually know
> what the code should do (although they may have written it themselves)?
They definitely might not understand the differences between the two
flavors well enough to know what to expect. For example, warnings
from the byte compiler about "unused lexical variable" might be
extremely puzzling if those differences are not well understood,
because to someone who is used to dynamic binding, the code looks 100%
legit.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Tue, 18 Feb 2025 20:24:02 GMT)
Full text and
rfc822 format available.
Message #87 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> They definitely might not understand the differences between the two
> flavors well enough to know what to expect. For example, warnings
> from the byte compiler about "unused lexical variable" might be
> extremely puzzling if those differences are not well understood,
> because to someone who is used to dynamic binding, the code looks
> 100% legit.
That's what the doc tries to explain:
A warning about an unused variable may be a good hint that the
variable was intended to be dynamically scoped (because it is
actually used, but in another function), but it may also be an
indication that the variable is simply really not used and could
simply be removed. So you need to find out which case it is, and
based on that, either add a @code{defvar} or remove the variable
altogether. If removal is not possible or not desirable (typically
because it is a formal argument and that we cannot or don't want to
change all the callers), you can also add a leading underscore to
the variable's name to indicate to the compiler that this is
a variable known not to be used.)
- Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Tue, 18 Feb 2025 20:31:01 GMT)
Full text and
rfc822 format available.
Message #90 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> Cc: dancol <at> dancol.org, 74145 <at> debbugs.gnu.org
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Tue, 18 Feb 2025 13:59:13 -0500
>
> This change is unlikely to be very disruptive at this point. For
> starters, users can easily just add this to any ELisp file that lacks it
> and move on with their lives:
>
> -*- lexical-binding:nil -*-
I thought we planned on displaying a warning for that?
> What's more, and this is from my personal experience of converting
> hundreds of .el files (see git log), most files will usually run just
> fine under lexbind, without any changes. I expect that user init files
> will typically fall into this category.
I actually expect the contrary, because user init files are in many
cases not regularly maintained and cleaned up like our Lisp sources
are. I won't be surprised if there are portions of our init files
which we haven't looked at for decades, because they "just work".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Tue, 18 Feb 2025 20:48:02 GMT)
Full text and
rfc822 format available.
Message #93 received at 74145 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Cc: dancol <at> dancol.org, 74145 <at> debbugs.gnu.org
>> From: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Tue, 18 Feb 2025 13:59:13 -0500
>>
>> This change is unlikely to be very disruptive at this point. For
>> starters, users can easily just add this to any ELisp file that lacks it
>> and move on with their lives:
>>
>> -*- lexical-binding:nil -*-
>
> I thought we planned on displaying a warning for that?
We have discussed different warnings, so I'm not sure which exact
proposals are currently on the table. But I think we currently warn
only if the lexical-binding cookie is missing.
As Stefan Monnier has pointed out, one could also use this to change the
global value:
(set-default-toplevel-value 'lexical-binding nil)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Tue, 18 Feb 2025 21:28:02 GMT)
Full text and
rfc822 format available.
Message #96 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> Makes sense to me.
Pushed to `master`.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Wed, 19 Feb 2025 12:19:02 GMT)
Full text and
rfc822 format available.
Message #99 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> Cc: 74145 <at> debbugs.gnu.org
> Date: Tue, 18 Feb 2025 16:27:43 -0500
> From: Stefan Monnier via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> > Makes sense to me.
>
> Pushed to `master`.
Boom! Just like that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Wed, 19 Feb 2025 15:05:01 GMT)
Full text and
rfc822 format available.
Message #102 received at 74145 <at> debbugs.gnu.org (full text, mbox):
>> Pushed to `master`.
> Boom! Just like that.
Well, yes. It's harmless.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Wed, 19 Feb 2025 17:05:02 GMT)
Full text and
rfc822 format available.
Message #105 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: stefankangas <at> gmail.com, 74145 <at> debbugs.gnu.org
> Date: Wed, 19 Feb 2025 10:04:41 -0500
>
> >> Pushed to `master`.
> > Boom! Just like that.
>
> Well, yes. It's harmless.
Maybe so, but I think we should have explained why we disregarded
objections and suggestions for slower movement forward.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Wed, 19 Feb 2025 21:31:01 GMT)
Full text and
rfc822 format available.
Message #108 received at 74145 <at> debbugs.gnu.org (full text, mbox):
>> >> Pushed to `master`.
>> > Boom! Just like that.
>> Well, yes. It's harmless.
> Maybe so, but I think we should have explained why we disregarded
> objections and suggestions for slower movement forward.
Which objections are you referring to?
I feel like I'm missing something.
The patch I pushed does not change any of Emacs's behavior, like
changing the default to t (which is what the objections I've seen object
to). The only "objection" I've seen was Christopher's sarcasm
about our inability to make consequential decisions.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Thu, 20 Feb 2025 06:45:01 GMT)
Full text and
rfc822 format available.
Message #111 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: stefankangas <at> gmail.com, 74145 <at> debbugs.gnu.org
> Date: Wed, 19 Feb 2025 16:30:36 -0500
>
> >> >> Pushed to `master`.
> >> > Boom! Just like that.
> >> Well, yes. It's harmless.
> > Maybe so, but I think we should have explained why we disregarded
> > objections and suggestions for slower movement forward.
>
> Which objections are you referring to?
I said "objections and suggestions". I meant these:
https://lists.gnu.org/archive/html/emacs-devel/2025-01/msg00531.html
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74145#36
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74145#57
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74145#60
It's okay to note those and decide to go ahead anyway, but I think we
should at least offer the courtesy of explaining why we did so. The
people who wrote those messages are active participants in Emacs
development, so IMNSHO they deserve to have such an explanation.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Thu, 20 Feb 2025 12:03:02 GMT)
Full text and
rfc822 format available.
Message #114 received at 74145 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > One always looks forward to reaching the end of a series of changes
> > planned to reach an intended destination. But if we want to do a good
> > job for the users, we must not rush them.
> It's been many years now. Everyone has had enough time to adapt to
> lexical-binding.
A smooth and painless transition calls for giving users time, but we
need to give them something else too. It also calls for intermediate
steps that will remind users to update, to remind them to update old code
_before_ it breaks.
For instance, we could set up a warning (which the user can
deactiviate if perse wishes) for files that don't explicitly specify a
value for lexical-binding. That warning will help fix their files to
be proof against future change in how that works.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Thu, 20 Feb 2025 12:04:02 GMT)
Full text and
rfc822 format available.
Message #117 received at 74145 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> The difference between the two, for users, is whether they need
> (set-default-toplevel-value 'lexical-binding t)
> to get the new setup or
> (set-default-toplevel-value 'lexical-binding nil)
> to continue with the old setup.
That is the crucial point at which the change becomes incompatible and
causes old files to break.
I suggest we make this process smoother by giving users a warning on
loading a file that fails to specify `lexical-binding' locally.
If `warn-unset-lexical-bindng' is t (which would be the default),
those warnings would be issued. If it is nil, there would be no
warning.
Meanwhile, the default value of `lexical-binding' would control the
behavior of variable binding when the file does not specify that,
just as now.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Thu, 20 Feb 2025 14:53:04 GMT)
Full text and
rfc822 format available.
Message #120 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> I said "objections and suggestions". I meant these:
>
> https://lists.gnu.org/archive/html/emacs-devel/2025-01/msg00531.html
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74145#57
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74145#60
These are about changing the default, which is not what the patch
I pushed does.
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74145#36
The patch I pushed does not include this change.
The patch I pushed does not close this issue at all.
It only contains the small subset of my original patch for which I did
not see any objections!
I wrote "I feel like I'm missing something", but I'm starting to think
that you're the one who missed the fact that the patch I pushed is not
the one you think.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Thu, 20 Feb 2025 17:03:03 GMT)
Full text and
rfc822 format available.
Message #123 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: stefankangas <at> gmail.com, 74145 <at> debbugs.gnu.org
> Date: Thu, 20 Feb 2025 09:52:03 -0500
>
> > I said "objections and suggestions". I meant these:
> >
> > https://lists.gnu.org/archive/html/emacs-devel/2025-01/msg00531.html
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74145#57
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74145#60
>
> These are about changing the default, which is not what the patch
> I pushed does.
>
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74145#36
>
> The patch I pushed does not include this change.
>
> The patch I pushed does not close this issue at all.
> It only contains the small subset of my original patch for which I did
> not see any objections!
>
> I wrote "I feel like I'm missing something", but I'm starting to think
> that you're the one who missed the fact that the patch I pushed is not
> the one you think.
No, I'm not missing anything, except some kind of response to those
posts.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Thu, 20 Feb 2025 20:01:03 GMT)
Full text and
rfc822 format available.
Message #126 received at 74145 <at> debbugs.gnu.org (full text, mbox):
>> I wrote "I feel like I'm missing something", but I'm starting to think
>> that you're the one who missed the fact that the patch I pushed is not
>> the one you think.
>
> No, I'm not missing anything, except some kind of response to those
> posts.
Then I'm still missing what is the connection with the patch I pushed.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Fri, 21 Feb 2025 06:57:02 GMT)
Full text and
rfc822 format available.
Message #129 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: stefankangas <at> gmail.com, 74145 <at> debbugs.gnu.org
> Date: Thu, 20 Feb 2025 15:00:30 -0500
>
> >> I wrote "I feel like I'm missing something", but I'm starting to think
> >> that you're the one who missed the fact that the patch I pushed is not
> >> the one you think.
> >
> > No, I'm not missing anything, except some kind of response to those
> > posts.
>
> Then I'm still missing what is the connection with the patch I pushed.
People suggested various roadmaps forward towards making
lexical-binding the default, with specific steps to be taken to let
users adjust to the change easier than in other roadmaps. In
response, we haven't produced any roadmap of our own, haven't
explained how the changes which are actually being installed fit into
that roadmap, and didn't even say whether we agree or disagree with
the proposed roadmaps.
That's what I'm missing, looking at the subject from the POV of those
people whose posts I mentioned, and that is the connection with the
patch you installed: what is the place of that patch in the roadmap
that we intend to use? I think we need to answer those questions, for
the benefit of those people, if not for our own.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Sat, 22 Feb 2025 04:49:02 GMT)
Full text and
rfc822 format available.
Message #132 received at 74145 <at> debbugs.gnu.org (full text, mbox):
>> >> I wrote "I feel like I'm missing something", but I'm starting to think
>> >> that you're the one who missed the fact that the patch I pushed is not
>> >> the one you think.
>> >
>> > No, I'm not missing anything, except some kind of response to those
>> > posts.
>>
>> Then I'm still missing what is the connection with the patch I pushed.
>
> People suggested various roadmaps forward towards making
> lexical-binding the default, with specific steps to be taken to let
> users adjust to the change easier than in other roadmaps. In
> response, we haven't produced any roadmap of our own, haven't
> explained how the changes which are actually being installed fit into
> that roadmap, and didn't even say whether we agree or disagree with
> the proposed roadmaps.
No changes are installed. None of the objections I've seen in this
bug-report were new and they've all been answered before, so I did not
reply because I have nothing new to say about it.
E.g. "why don't we start by warning when we load files
without the lexical-binding cookie?":
https://lists.gnu.org/r/emacs-devel/2024-05/msg00250.html
> That's what I'm missing, looking at the subject from the POV of those
> people whose posts I mentioned, and that is the connection with the
> patch you installed: what is the place of that patch in the roadmap
> that we intend to use?
It's a *very* small step that lets people try Emacs "as if
lexical-binding was enabled by default" but only if they specifically
ask for it. Maybe it's part of what you call a "roadmap", but AFAIK
it's not going to bring us much closer because those who'll be tempted
to try it out and most likely those who are interested in the subject so
they likely already converted their code.
> I think we need to answer those questions, for
> the benefit of those people, if not for our own.
I don't have any new answers to those questions.
I do think changing the default to t on `master` (at least on
a temporary basis) might give us some new feedback which may open up
space for new answers. I've also already said that several times.
But AFAICT you're scared to do that, even though we're talking about the
development version of our code (i.e. something which users should
expect to come with rough edges every once in a while) and it comes
with a trivial one-liner config to restore the previous behavior.
AFAICT the only option left for me is to wait for that fear to subside.
Maybe another 10 years or so will do?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Sat, 22 Feb 2025 22:01:02 GMT)
Full text and
rfc822 format available.
Message #135 received at 74145 <at> debbugs.gnu.org (full text, mbox):
Phil Sainty <psainty <at> orcon.net.nz> writes:
> I'm sure a majority of elisp programmers are aware of lexical-binding
> by this point, and (in a great many cases) have adapted to it; but,
> with the exception of those who are following current developments,
> nobody has had ANY time to adapt to the idea that lexical-binding is
> the DEFAULT. Users having time to adapt to THAT begins with the first
> release that warns that it's going to happen, and we haven't had one
> of those yet.
>
> Even the users who understand Emacs Lisp should have advance warning
> of such a change so that they can make the necessary changes in
> advance of that change coming into effect.
>
> Emacs is not only used by elisp programmers, though. Many users don't
> understand elisp; will not understand dynamic-vs-lexical binding; and
> will not know why the libraries they have been using for many years
> suddenly don't work properly.
>
> Those users should be informed that they need to change something
> before it has a chance to break things, so this should be sign-posted
> for a long time in advance of the actual change, so that users really
> do have time to adapt.
I believe the advance warning has been in place for over 10 years at
this point, and not just for ELisp developers.
For instance, while it may not have been entirely accurate, the release
announcement for Emacs 27.1 already stated that:
"Lexical-binding is used by default"[1]
Additionally, in the mode line, we display a warning if a file does not
use lexical-binding.
In the Info node `(elisp) Variable Scoping', we find the following
statement:
"The old dynamic-only Emacs Lisp dialect is still the default in
code loaded or evaluated from Lisp files that lack a dialect
declaration. Eventually the modern dialect will be made the
default. All Lisp files should declare the dialect used to ensure
that they keep working correctly in the future."
In Emacs 30.1, we warn when any files are byte-compiled without this
declaration. And the list goes on.
There are many more examples of this trend, as it has been a consistent
theme in our communication and documentation for quite some time. The
warning shots have been fired -- and more than once.
> Consider users who are running Ubuntu 24.04 GNU/Linux as their OS
> (being a popular OS with long-term support). That OS release is
> supported for 5 years as standard, and it provides Emacs 29. So a lot
> of those users will be running Emacs 29 with dynamic binding as the
> default until 2029, and when they update their OS in 2029 and acquire,
> say, Emacs 31, it would be beneficial if their Emacs config wasn't
> suddenly broken on account of something they'd had no prior warning
> about.
You're discussing this as though it's a major breaking change, but keep
in mind that it can be trivially reverted in at least two ways:
1. by adding a simple one-liner to your init file,
2. by adding "-*- lexical-binding:nil -*-" to the relevant ELisp files.
However, our experience with this issue suggests that the risks, as
they're perceived, are overstated. In most cases, neither of these will
be necessary, because things will just work. And for the cases where
they don't, well, the fix is trivial and will be plastered both online
and in our documentation.
It's true that the completely painless scenario is a pipe dream -- it
doesn't exist. Some things will break, whether we switch the default
now, or in twenty years. The goal of a reasonable and responsible
transition is not to avoid the inevitable, but to minimize and mitigate
the pain and ensure that we've done everything within our power to do
so. I believe that we have reached that point.
The counter-argument provided above is that the warnings have not been
backported. I agree that it would be better if they were. However,
this is up to distros and not us; if our downstreams want to, they can
easily backport it.
However, nothing about this is specific to lexical-binding. If we want
to substantially improve the current situation, I believe that we need
to start providing minimal support for older major versions. If we had
this in place, we could have backported this warning, as well as other
important fixes, such as security patches that are now only available in
the most recent version. This would encourage distro maintainers to
include this set of fixes in their point releases, with our official
endorsement. I can't speak for other maintainers, but I'm open to
discussing this myself.
> I'm not seeing a cost/benefit analysis in favour of making this change
> sooner.
I believe that we have made such a cost-benefit analysis many times in
the past. I don't mean to sound dismissive, but may I kindly suggest
reviewing the mailing list archives? We discussed this as recently as
November, where these issues were given a reasonably thorough treatment.
Waiting another ten years to switch the default, in my view, is not
realistic at this point. Keeping lexical-binding disabled does not come
without cost, regardless of how some may perceive it.
Footnotes:
[1] https://lists.gnu.org/r/emacs-devel/2020-08/msg00237.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Sun, 23 Feb 2025 10:23:02 GMT)
Full text and
rfc822 format available.
Message #138 received at 74145 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Sat 22 Feb 2025 at 10:00pm GMT, Stefan Kangas wrote:
> However, nothing about this is specific to lexical-binding. If we want
> to substantially improve the current situation, I believe that we need
> to start providing minimal support for older major versions. If we had
> this in place, we could have backported this warning, as well as other
> important fixes, such as security patches that are now only available in
> the most recent version. This would encourage distro maintainers to
> include this set of fixes in their point releases, with our official
> endorsement. I can't speak for other maintainers, but I'm open to
> discussing this myself.
Yes, currently in Debian we only backport security fixes.
It would be cool to be able to backport more.
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Tue, 25 Feb 2025 23:46:01 GMT)
Full text and
rfc822 format available.
Message #141 received at 74145 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > Those users should be informed that they need to change something
> > before it has a chance to break things, so this should be sign-posted
> > for a long time in advance of the actual change, so that users really
> > do have time to adapt.
> I believe the advance warning has been in place for over 10 years at
> this point, and not just for ELisp developers.
I think you're talking about a general, abstract warning, which says
thet code which works in certain ways will need to be changed somehow,
some day. That is better than nothing, but it some users would not
understand what they need to do.
> For instance, while it may not have been entirely accurate, the release
> announcement for Emacs 27.1 already stated that:
> "Lexical-binding is used by default"[1]
That is an nonspecific abstract warning -- it does tells users that
something will need to be changed, but does ot say what or where.
> Additionally, in the mode line, we display a warning if a file does not
> use lexical-binding.
That warning sounds more specific, but is it adequately clear? I am
not sure, because that would depend on details not stated here.
Does it warn about file FOO.el when you load it? Or when you visit it
to edit it? Or both? (I don't recall ever seeing it.)
Does the warning remain in a log that the user can easily visit, such
as the *Messages* buffer, or in a *Compile* buffer whne bootstrapping?
If this warning is very visible, and remains visible for a substantial
time, and tells the user contrtely what to change (Such as, "Give the
file a specifiction of `lexical-binding'"), maybe it is already good
enough now.
Let's actively help our users adapt to our changes. If this warning
not already visible and concrete enough, let's make it so!
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Thu, 27 Feb 2025 02:21:02 GMT)
Full text and
rfc822 format available.
Message #144 received at 74145 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> No changes are installed. None of the objections I've seen in this
> bug-report were new and they've all been answered before, so I did not
> reply because I have nothing new to say about it.
> E.g. "why don't we start by warning when we load files
> without the lexical-binding cookie?":
> https://lists.gnu.org/r/emacs-devel/2024-05/msg00250.html
> I don't have any new answers to those questions.
Are you ok with our implementing that warning now?
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Tue, 11 Mar 2025 22:29:01 GMT)
Full text and
rfc822 format available.
Message #147 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> > No changes are installed. None of the objections I've seen in this
> > bug-report were new and they've all been answered before, so I did not
> > reply because I have nothing new to say about it.
>
> > E.g. "why don't we start by warning when we load files
> > without the lexical-binding cookie?":
>
> > https://lists.gnu.org/r/emacs-devel/2024-05/msg00250.html
>
> > I don't have any new answers to those questions.
>
> Are you ok with our implementing that warning now?
Of course. For me, the purpose of this bug#74145 is not to see *if* we
can change the default but *how*, or rather under which conditions.
The point of introducing the change early on during the Emacs-31
development is to have ample time to implement (and tune) whichever
mitigating measure we find to be necessary.
And I doubt we'll figure what is necessary before we actually make the
change on `master`.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Tue, 11 Mar 2025 23:26:01 GMT)
Full text and
rfc822 format available.
Message #150 received at 74145 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:
>> > E.g. "why don't we start by warning when we load files
>> > without the lexical-binding cookie?":
>>
>> > https://lists.gnu.org/r/emacs-devel/2024-05/msg00250.html
>>
>> > I don't have any new answers to those questions.
>>
>> Are you ok with our implementing that warning now?
>
> Of course. For me, the purpose of this bug#74145 is not to see *if* we
> can change the default but *how*, or rather under which conditions.
>
> The point of introducing the change early on during the Emacs-31
> development is to have ample time to implement (and tune) whichever
> mitigating measure we find to be necessary.
>
> And I doubt we'll figure what is necessary before we actually make the
> change on `master`.
I agree with Stefan Monnier. Changing the default on `master` seems
like a good way to uncover any potential showstoppers early, so we can
base any mitigating measures on real and relevant issues, not just
hypotheticals.
Some things we can anticipate, of course, but without flipping the
default, I'm concerned that some of the proposed precautions rely too
heavily on hunches and guesswork. Prior experience is valuable and
important, but it's no substitute for observing how things actually
play out in practice.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Wed, 12 Mar 2025 13:23:02 GMT)
Full text and
rfc822 format available.
Message #153 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> Cc: 74145 <at> debbugs.gnu.org
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Tue, 11 Mar 2025 18:25:23 -0500
>
> Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs <at> gnu.org> writes:
>
> >> > E.g. "why don't we start by warning when we load files
> >> > without the lexical-binding cookie?":
> >>
> >> > https://lists.gnu.org/r/emacs-devel/2024-05/msg00250.html
> >>
> >> > I don't have any new answers to those questions.
> >>
> >> Are you ok with our implementing that warning now?
> >
> > Of course. For me, the purpose of this bug#74145 is not to see *if* we
> > can change the default but *how*, or rather under which conditions.
> >
> > The point of introducing the change early on during the Emacs-31
> > development is to have ample time to implement (and tune) whichever
> > mitigating measure we find to be necessary.
> >
> > And I doubt we'll figure what is necessary before we actually make the
> > change on `master`.
>
> I agree with Stefan Monnier. Changing the default on `master` seems
> like a good way to uncover any potential showstoppers early, so we can
> base any mitigating measures on real and relevant issues, not just
> hypotheticals.
>
> Some things we can anticipate, of course, but without flipping the
> default, I'm concerned that some of the proposed precautions rely too
> heavily on hunches and guesswork. Prior experience is valuable and
> important, but it's no substitute for observing how things actually
> play out in practice.
Please forgive me, but this again changes the subject. The original
issue was with adding a warning (and maybe other measures designed to
alert users to the change and prepare them for dealing with it), not
with when to change the default on the master branch. From where I
stand, we can make the change once these measures are implemented, but
not before.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Thu, 13 Mar 2025 07:28:02 GMT)
Full text and
rfc822 format available.
Message #156 received at 74145 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Please forgive me, but this again changes the subject. The original
> issue was with adding a warning (and maybe other measures designed to
> alert users to the change and prepare them for dealing with it), not
> with when to change the default on the master branch. From where I
> stand, we can make the change once these measures are implemented, but
> not before.
OK, then let's focus on that.
The idea is to warn is when a file is loaded without a lexical-binding
cookie. We don't have a patch yet, but it should be straightforward,
and we agree. Let's just do it.
Are there any other important measures that remain?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Thu, 13 Mar 2025 07:56:02 GMT)
Full text and
rfc822 format available.
Message #159 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Thu, 13 Mar 2025 00:27:20 -0700
> Cc: monnier <at> iro.umontreal.ca, rms <at> gnu.org, 74145 <at> debbugs.gnu.org
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Please forgive me, but this again changes the subject. The original
> > issue was with adding a warning (and maybe other measures designed to
> > alert users to the change and prepare them for dealing with it), not
> > with when to change the default on the master branch. From where I
> > stand, we can make the change once these measures are implemented, but
> > not before.
>
> OK, then let's focus on that.
>
> The idea is to warn is when a file is loaded without a lexical-binding
> cookie. We don't have a patch yet, but it should be straightforward,
> and we agree. Let's just do it.
SGTM.
> Are there any other important measures that remain?
I think there was a suggestion to make the mode-line indication more
prominent or something. Also, perhaps some prominent announcement in
NEWS could be in order.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Thu, 13 Mar 2025 09:55:02 GMT)
Full text and
rfc822 format available.
Message #162 received at 74145 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Thu, 13 Mar 2025 00:27:20 -0700
>> Cc: monnier <at> iro.umontreal.ca, rms <at> gnu.org, 74145 <at> debbugs.gnu.org
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > Please forgive me, but this again changes the subject. The original
>> > issue was with adding a warning (and maybe other measures designed to
>> > alert users to the change and prepare them for dealing with it), not
>> > with when to change the default on the master branch. From where I
>> > stand, we can make the change once these measures are implemented, but
>> > not before.
>>
>> OK, then let's focus on that.
>>
>> The idea is to warn is when a file is loaded without a lexical-binding
>> cookie. We don't have a patch yet, but it should be straightforward,
>> and we agree. Let's just do it.
>
> SGTM.
That's Bug#72672, I think, so let's use that reference.
>> Are there any other important measures that remain?
>
> I think there was a suggestion to make the mode-line indication more
> prominent or something. Also, perhaps some prominent announcement in
> NEWS could be in order.
We could also consider Bug#66706, in case your view has changed on that.
I'd still be in favor of making the change, but if nothing has changed
there, we should probably take the opportunity to close the bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Thu, 13 Mar 2025 14:18:02 GMT)
Full text and
rfc822 format available.
Message #165 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Thu, 13 Mar 2025 02:54:33 -0700
> Cc: monnier <at> iro.umontreal.ca, rms <at> gnu.org, 74145 <at> debbugs.gnu.org
>
> We could also consider Bug#66706, in case your view has changed on that.
> I'd still be in favor of making the change, but if nothing has changed
> there, we should probably take the opportunity to close the bug.
I don't think that suggestion will help the users who need to be
alerted to the change in default binding.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Fri, 14 Mar 2025 03:52:02 GMT)
Full text and
rfc822 format available.
Message #168 received at 74145 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > > E.g. "why don't we start by warning when we load files
> > > without the lexical-binding cookie?":
> >
> > > https://lists.gnu.org/r/emacs-devel/2024-05/msg00250.html
> >
> > > I don't have any new answers to those questions.
> >
> > Are you ok with our implementing that warning now?
> Of course. For me, the purpose of this bug#74145 is not to see *if* we
> can change the default but *how*, or rather under which conditions.
This chamge woud be good to make right away. Please go ahead.
However, to change the default value of `lexical-binding' would
cause cnfusion and problems. Please don't do that now.
Instead, we should do the other change that reminds users
to make their files set this variable. We could release 30.2
right away with that one change. Then users would start changing
their files to avoid future problems.
I have an idea for another change that will help with this too.
The idea is, whenever Emacs loads a file from a directory D,
it should look for other Emacs Lisp files in D which lack a binding
for lexical-binding, and if it sees any, it should
urge the user to add such bindings to all the Lisp files in D.
To make this easier for users, it could ask the qyestion,
Add a lexical-binding spec to each Emacs Lisp file in dir D?
If the user says yes, it could ask
Use lexical-binding t for all files, or lexical-binding nil for all,
or ask about each file?
This will encourage users to fix lots of files soon, even files
they won't actually have thought about.
This change could be extended in various ways.
For instance, it could record where there are files that lack
a spec for `lexical-binding', and ask about 20 files per day.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Fri, 14 Mar 2025 08:32:01 GMT)
Full text and
rfc822 format available.
Message #171 received at 74145 <at> debbugs.gnu.org (full text, mbox):
> Cc: 74145 <at> debbugs.gnu.org
> From: Richard Stallman <rms <at> gnu.org>
> Date: Thu, 13 Mar 2025 23:51:45 -0400
>
> > > > E.g. "why don't we start by warning when we load files
> > > > without the lexical-binding cookie?":
> > >
> > > > https://lists.gnu.org/r/emacs-devel/2024-05/msg00250.html
> > >
> > > > I don't have any new answers to those questions.
> > >
> > > Are you ok with our implementing that warning now?
>
> > Of course. For me, the purpose of this bug#74145 is not to see *if* we
> > can change the default but *how*, or rather under which conditions.
>
> This chamge woud be good to make right away. Please go ahead.
>
> However, to change the default value of `lexical-binding' would
> cause cnfusion and problems. Please don't do that now.
>
> Instead, we should do the other change that reminds users
> to make their files set this variable. We could release 30.2
> right away with that one change. Then users would start changing
> their files to avoid future problems.
We generally avoid making changes that aren't bugfixes in bugfix
releases such as 30.2. But we could make an exception in this case, I
guess.
> I have an idea for another change that will help with this too.
> The idea is, whenever Emacs loads a file from a directory D,
> it should look for other Emacs Lisp files in D which lack a binding
> for lexical-binding, and if it sees any, it should
> urge the user to add such bindings to all the Lisp files in D.
>
> To make this easier for users, it could ask the qyestion,
>
> Add a lexical-binding spec to each Emacs Lisp file in dir D?
>
> If the user says yes, it could ask
>
> Use lexical-binding t for all files, or lexical-binding nil for all,
> or ask about each file?
>
> This will encourage users to fix lots of files soon, even files
> they won't actually have thought about.
But it could slow down loading files, especially if D is a large
directory. We should also allow the user to opt out from these
questions and the check itself.
On balance, I'm not sure this feature will not be a nuisance more than
help. In any case, I think we should discuss this kind of change on
emacs-devel, not here.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Sat, 15 Mar 2025 03:32:02 GMT)
Full text and
rfc822 format available.
Message #174 received at 74145 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> Please forgive me, but this again changes the subject. The original
> issue was with adding a warning (and maybe other measures designed to
> alert users to the change and prepare them for dealing with it), not
> with when to change the default on the master branch.
I think that because people sppke of "making the change", which says
nothing at all about what change is in question, people could not tell
whether they were talking about the same thing.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Sun, 16 Mar 2025 03:39:03 GMT)
Full text and
rfc822 format available.
Message #177 received at 74145 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > I have an idea for another change that will help with this too.
> > The idea is, whenever Emacs loads a file from a directory D,
> > it should look for other Emacs Lisp files in D which lack a binding
> > for lexical-binding, and if it sees any, it should
> > urge the user to add such bindings to all the Lisp files in D.
> In any case, I think we should discuss this kind of change on
> emacs-devel, not here.
Thanks for raising that point.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Tue, 25 Mar 2025 19:28:02 GMT)
Full text and
rfc822 format available.
Message #180 received at 74145 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Are you ok with our implementing that warning now?
Apparently, noone's interested in doing that, so I suggest the patch below.
Stefan
[lexbindwarn.patch (text/x-diff, inline)]
diff --git a/lisp/files.el b/lisp/files.el
index 4e3aeeb9246..8bc9bba876c 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -4274,6 +4335,25 @@ hack-local-variables
(push elem file-local-variables-alist)))
(hack-local-variables-apply))))))
+(defun internal--get-default-lexical-binding-function (from)
+ (or (and (bufferp from) (zerop (buffer-size from)))
+ (and (stringp from) (eql 0 (file-attribute-size (file-attributes from))))
+ (display-warning
+ 'files
+ (format-message "Missing `lexical-binding' cookie in %S
+See `(elisp)Selecting Lisp Dialect' and `(elisp)Converting to Lexical Binding'
+for more information."
+ (if (not (and (bufferp from)
+ (equal (buffer-name from) " *load*")
+ load-file-name))
+ from
+ (abbreviate-file-name load-file-name)))
+ :warning))
+ (default-toplevel-value 'lexical-binding))
+
+(setq internal--get-default-lexical-binding-function
+ #'internal--get-default-lexical-binding-function)
+
(defun hack-local-variables--find-variables (&optional handle-mode)
"Return all local variables in the current buffer.
If HANDLE-MODE is nil, we gather all the specified local
diff --git a/src/lread.c b/src/lread.c
index add8deb3954..fd8f9e80ebd 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -1271,6 +1265,18 @@ close_file_unwind_android_fd (void *ptr)
#endif
+static Lisp_Object
+get_lexical_binding (Lisp_Object stream, Lisp_Object from)
+{
+ lexical_cookie_t lexc = lisp_file_lexical_cookie (stream);
+ return (lexc == Cookie_Lex ? Qt
+ : lexc == Cookie_Dyn ? Qnil
+ : (NILP (from) /* Loading a byte-compiled file. */
+ || NILP (Vinternal__get_default_lexical_binding_function)
+ ? Fdefault_toplevel_value (Qlexical_binding)
+ : calln (Vinternal__get_default_lexical_binding_function, from)));
+}
+
DEFUN ("load", Fload, Sload, 1, 5, 0,
doc: /* Execute a file of Lisp code named FILE.
First try FILE with `.elc' appended, then try with `.el', then try
@@ -1720,11 +1733,8 @@ DEFUN ("load", Fload, Sload, 1, 5, 0,
}
else
{
- lexical_cookie_t lexc = lisp_file_lexical_cookie (Qget_file_char);
Fset (Qlexical_binding,
- (lexc == Cookie_Lex ? Qt
- : lexc == Cookie_Dyn ? Qnil
- : Fdefault_toplevel_value (Qlexical_binding)));
+ get_lexical_binding (Qget_file_char, compiled ? Qnil : file));
if (! version || version >= 22)
readevalloop (Qget_file_char, &input, hist_file_name,
@@ -2609,11 +2619,7 @@ 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)));
- lexical_cookie_t lexc = lisp_file_lexical_cookie (buf);
- specbind (Qlexical_binding,
- lexc == Cookie_Lex ? Qt
- : lexc == Cookie_Dyn ? Qnil
- : Fdefault_toplevel_value (Qlexical_binding));
+ 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);
@@ -5169,7 +5175,7 @@ obarray_index (struct Lisp_Obarray *oa, const char *str, ptrdiff_t size_byte)
return knuth_hash (reduce_emacs_uint_to_hash_hash (hash), oa->size_bits);
}
-/* Return the symbol in OBARRAY whose names matches the string
+/* Return the symbol in OBARRAY whose name matches the string
of SIZE characters (SIZE_BYTE bytes) at PTR.
If there is no such symbol, return the integer bucket number of
where the symbol would be if it were present.
@@ -6145,6 +6151,11 @@ syms_of_lread (void)
DEFSYM (Qchar_from_name, "char-from-name");
+ DEFVAR_LISP ("internal--get-default-lexical-binding-function",
+ Vinternal__get_default_lexical_binding_function,
+ doc: /* Function to decide default lexical-binding. */);
+ Vinternal__get_default_lexical_binding_function = Qnil;
+
DEFVAR_LISP ("read-symbol-shorthands", Vread_symbol_shorthands,
doc: /* Alist of known symbol-name shorthands.
This variable's value can only be set via file-local variables.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#74145; Package
emacs.
(Tue, 08 Apr 2025 01:45:02 GMT)
Full text and
rfc822 format available.
Message #183 received at 74145 <at> debbugs.gnu.org (full text, mbox):
>> Are you ok with our implementing that warning now?
> Apparently, noone's interested in doing that, so I suggest the patch below.
Pushed with minor improvements,
Stefan
This bug report was last modified 67 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.