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

Previous Next

Full log

View this message in rfc822 format

From: Phil Sainty <psainty <at> orcon.net.nz>
To: dancol <at> dancol.org
Cc: 74145 <at> debbugs.gnu.org
Subject: bug#74145: 31.0.50; Default lexical-binding to t
Date: Wed, 19 Feb 2025 00:01:10 +1300

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

Previous Next

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