unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Richard Stallman <rms@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: Default lexical-binding to t
Date: Mon, 04 Nov 2024 00:34:25 -0500	[thread overview]
Message-ID: <E1t7pjN-0003ks-GM@fencepost.gnu.org> (raw)
In-Reply-To: <jwv34kbf79m.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Fri, 01 Nov 2024 08:55:56 -0400)

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > - Don't have a `lexical-binding` cookie.
  > - Have code which happens to behave differently under the new dialect
  >   (such code is not rare, but a lot of code works identically in the
  >   two dialects).

  > I believe by the time Emacs-31 will be released, such files will be
  > uncommon, and it is easy to fix them (either by adjusting he code, or
  > by slapping a `lexical-binding` cookie).

It seems that people are forming ideas of how frequent dynamic binding
files are by looking at code in active development.  Of course it is
rare there.  But user have a lot of old Lisp files that they haven't
used for a while.  Some of them, someone will try to use someday.

So we should never expect the user commnity to quickly eliminate
constructs that we plan to break.  We should never rush to break it.

Many users upgrade Emacs only occasionally, and often skip one or more
versions.  And people have Lisp code they have not run in some years
-- but that doesn't mean they never will.  Those disused files may be
more numerous than the files people regularly use.

I think we should prepare for the change in Emacs 31, and go the rest
of the way in Emacs 33 or 34.  Emacs 31 should go all out to urge
users to fix their Lisp files to specify lexical-binding.

For now, we should improve the warning given for a file that fails to
specify lexical-binding.  Let's make it explicitly say what we want
users to do.  "To avoid confusion later, add lexical-binding to the
file's local variables now."

For warning when visiting a file, instead of a cryptic "/d", it whould
show clear instructions.

Can we add that trivial change to 31.2?

The more cases in which we notify users, and the more explicitly we do
so, the sooner users will follow that advice.  With this
encouragement, I think we can expect that few programs that don't
specify lexical-binding will remain after a few more years.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





  parent reply	other threads:[~2024-11-04  5:34 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-01 12:55 Default lexical-binding to t Stefan Monnier
2024-11-01 14:42 ` Gerd Möllmann
2024-11-01 17:03 ` Karl Fogel
2024-11-02 10:48 ` Visuwesh
2024-11-02 12:08   ` Eli Zaretskii
2024-11-02 13:21     ` Visuwesh
2024-11-02 16:24   ` Stefan Monnier
2024-11-02 20:42     ` Jim Porter
2024-11-02 21:38       ` Stefan Kangas
2024-11-03  2:32         ` Stefan Kangas
2024-11-03 13:58           ` Stefan Monnier
2024-11-03 14:34             ` Stefan Kangas
2024-11-04  8:35             ` Jean Louis
2024-11-04  8:43               ` tomas
2024-11-03  1:46       ` Stefan Monnier
2024-11-03  2:30         ` Stefan Kangas
2024-11-03  7:47         ` Jim Porter
2024-11-03 13:53           ` Stefan Monnier
2024-11-03  6:44       ` Sean Whitton
2024-11-03 14:59         ` lexical-binding in paredit Stefan Monnier
2024-11-03 18:32           ` Stefan Kangas
2024-11-03 21:44             ` Taylor R Campbell
2024-11-04  1:54               ` Stefan Monnier
2024-11-03 15:26 ` Default lexical-binding to t Andrea Corallo
2024-11-07  3:46   ` Richard Stallman
2024-11-07 23:00     ` Andrea Corallo
2024-11-08 15:53       ` Sebastián Monía
2024-11-08 16:23         ` Eli Zaretskii
2024-11-08 17:28           ` Sebastián Monía
2024-11-08 17:37             ` Joost Kremers
2024-11-08 18:51             ` Eli Zaretskii
2024-11-08 20:18               ` Sebastián Monía
2024-11-08 20:57                 ` [External] : " Drew Adams
2024-11-11  5:13             ` Richard Stallman
2024-11-04  5:34 ` Richard Stallman [this message]
2024-11-04  9:39   ` Po Lu
2024-11-04 13:19     ` Eli Zaretskii
2024-11-04 17:06     ` Alfred M. Szmidt
2024-11-04 18:24       ` [External] : " Drew Adams
2024-11-06  4:44       ` Richard Stallman
2024-11-07 23:07     ` Andrea Corallo
2024-11-04 12:51   ` Eli Zaretskii
2024-11-05 20:24     ` Stefan Monnier
2024-11-06 12:11       ` Eli Zaretskii
2024-11-06 12:50         ` Stefan Monnier
2024-11-06 13:36           ` Eli Zaretskii
2024-11-06 16:32             ` Stefan Monnier
2024-11-06 17:20               ` Eli Zaretskii
2024-11-06 17:42               ` Alan Mackenzie
2024-11-06 20:48                 ` Joost Kremers
2024-11-06 22:50                   ` Alan Mackenzie
2024-11-07  0:46                     ` Stefan Kangas
2024-11-07 21:03                       ` Alan Mackenzie
2024-11-08  0:44                         ` Stefan Kangas
2024-11-10  4:04                         ` Richard Stallman
2024-11-07  6:14                     ` Eli Zaretskii
2024-11-07  8:07                       ` Joost Kremers
2024-11-07  8:45                         ` Eli Zaretskii
2024-11-07 11:09                           ` tomas
2024-11-07 21:23                       ` Alan Mackenzie
2024-11-07 22:37                         ` Dmitry Gutov
2024-11-08  6:58                         ` Eli Zaretskii
2024-11-08 14:01                           ` Alan Mackenzie
2024-11-08 15:19                             ` Eli Zaretskii
2024-11-08 19:07                               ` Alan Mackenzie
2024-11-08 20:01                                 ` Stefan Monnier
2024-11-07 22:10                     ` Andrea Corallo
2024-11-08 18:38                     ` Stefan Monnier
2024-11-07  2:55                 ` Sean Whitton
2024-11-06 17:54       ` Jim Porter
2024-11-06 19:26         ` Stefan Monnier
2024-11-06 20:23           ` John Yates
2024-11-08 18:43             ` Stefan Monnier
2024-11-06 19:53         ` Jose A. Ortega Ruiz
2024-11-08 18:42           ` Stefan Monnier
2024-11-07  3:46     ` Richard Stallman
2024-11-07  7:09       ` Eli Zaretskii
2024-11-07  3:46     ` Richard Stallman
  -- strict thread matches above, loose matches on Subject: below --
2024-11-07 22:28 Christopher Howard
2024-11-08  0:38 ` Stefan Kangas
2024-11-08  6:29   ` tomas
2024-11-10  4:04     ` Richard Stallman
2024-11-08  7:27   ` Eli Zaretskii
2024-11-08 12:11     ` Stefan Kangas
2024-11-08 13:12       ` Suhail Singh
2024-11-08 13:24         ` Stefan Kangas
2024-11-08 13:45       ` Eli Zaretskii
2024-11-08  7:01 ` Eli Zaretskii

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=E1t7pjN-0003ks-GM@fencepost.gnu.org \
    --to=rms@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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).