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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Phil Sainty <psainty <at> orcon.net.nz>, dancol <at> dancol.org
Cc: 74145 <at> debbugs.gnu.org
Subject: bug#74145: 31.0.50; Default lexical-binding to t
Date: Sat, 22 Feb 2025 22:00:37 +0000

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

Previous Next

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