From: abq@bitrot.link
To: emacs-devel@gnu.org
Subject: Re: Why is lexical-binding's global value ignored?
Date: Tue, 31 Jan 2023 19:04:46 -0700 [thread overview]
Message-ID: <190bb3292292a8e5932f97220c2a36c5@bitrot.link> (raw)
In-Reply-To: <25094a24f891856fe0757fa34d80017b@bitrot.link>
Richard Stallman wrote:
> A year or two after that. all packages people use will explicitly
> specify lexical or not. At that point, we could safely change the
> default, if we want to.
Yes, and a great way to change the default would be specifically:
First, start honoring the global value of the lexical-binding variable.
At first, keep it nil by default, as it is now, so no behavior actually
changes, and nothing breaks. But announce that the default will change
in a future version. Of course, buffer local lexical-binding continues
to work as it does now.
Second, brave users can optionally setq-default lexical-binding t in the
init file to get the new behavior now, and report breakage they discover
in packages they use. Users who want the old behavior, or don't care
about the issue and have no desire to learn about it, can ignore it, and
nothing breaks. The default remains nil.
Third, as announced long in advance, change the default to t in a future
version, and announce that users can setq-default lexical-binding nil in
the init file if they still want the old behavior.
The key here is honoring the global value of lexical-binding. This makes
the transition as smooth as possible, and makes it trivially easy for
users to opt out even after the transition is complete and the default
is t.
The current problem is just that Emacs 24 through 28 ignores the global
value. When loading a file, Emacs pretends that the global value is
always nil even when it's actually t. (But of course, this entire
discussion is irrelevant whenever lexical-binding is set buffer
locally.)
Honoring the global value is arguably just a bug fix.
Or did you have another mechanism in mind for changing the default?
Another possibility would be to still ignore the global value, but start
pretending that it's always t even when it's actually nil. But surely
nobody is advocating that Emacs ever do that. It makes much more sense
to simply honor the global value (which could start right now, with no
harm), then change the global default to t sometime in the future.
There is a potential problem: Eli worries that “many people will not
understand the disastrous consequences” of doing (setq-default
lexical-binding t), and therefore he decided to delay honoring the
global value. But a prominent warning DO NOT TOUCH THIS GLOBAL VARIABLE
UNLESS YOU'RE AN EXPERT would be just as effective for Emacs 29 as it
would be for Emacs 30 or even 42; the delay accomplishes nothing. And
people who don't read the news at all, and just blindly upgrade and
continue using their init file and packages unmodified, will experience
no breakage, because the default remains nil. No adaptation is required,
by anybody.
There is another theoretical problem. Maybe somebody, somewhere,
irrationally already does (setq-default lexical-binding t) in his init
file, to no effect, and then (even more irrationally) subsequently
relies on dynamic binding despite explicitly trying to set lexical
binding. Any future version of Emacs that starts honoring the global
value will break his config. But abstaining on his behalf is as
unreasonable as total abstinence from ever adding any new global
variable to any future version of Emacs ever again, due to the risk that
the variable will conflict with somebody's private usage of it.
Eli's decision is final, but it's worthwhile to make the situation
clear.
prev parent reply other threads:[~2023-02-01 2:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-28 3:01 Why is lexical-binding's global value ignored? abq
2023-01-28 7:10 ` tomas
2023-01-29 9:36 ` Jean Louis
2023-01-31 4:19 ` Richard Stallman
2023-01-31 13:49 ` Eli Zaretskii
2023-01-28 16:11 ` abq
2023-01-28 18:44 ` tomas
2023-01-28 22:34 ` abq
2023-01-29 6:54 ` Eli Zaretskii
2023-01-30 3:53 ` abq
2023-01-30 12:32 ` Eli Zaretskii
2023-01-30 12:59 ` tomas
2023-01-30 13:45 ` Po Lu
2023-02-01 2:04 ` abq [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=190bb3292292a8e5932f97220c2a36c5@bitrot.link \
--to=abq@bitrot.link \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).