GNU bug report logs - #74145
31.0.50; Default lexical-binding to t

Previous Next

Package: emacs;

Reported by: Stefan Monnier <monnier <at> iro.umontreal.ca>

Date: Thu, 31 Oct 2024 20:59:02 UTC

Severity: wishlist

Tags: patch

Found in version 31.0.50

Full log


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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: 74145 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>, Andrea Corallo <acorallo <at> gnu.org>,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#74145: 31.0.50; Default lexical-binding to t
Date: Thu, 31 Oct 2024 16:31:49 -0700
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?




This bug report was last modified 68 days ago.

Previous Next


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