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


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 74145 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, rms <at> gnu.org
Subject: bug#74145: 31.0.50; Default lexical-binding to t
Date: Wed, 12 Mar 2025 15:21:42 +0200
> 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.




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.