[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#66706: [PATCH] Automatic elisp dialect insertion
From: |
Eli Zaretskii |
Subject: |
bug#66706: [PATCH] Automatic elisp dialect insertion |
Date: |
Fri, 27 Oct 2023 09:26:06 +0300 |
> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: dmitry@gutov.dev, mattias.engdegard@gmail.com, 66706@debbugs.gnu.org,
> stefankangas@gmail.com, monnier@iro.umontreal.ca
> Date: Fri, 27 Oct 2023 05:14:11 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > > Short version of my reply: Emacs users are a different group than Elisp
> > > package developers. Let's help them by forcing a lexical binding cookie
> > > in the config file instead of simply making their Emacs potentially not
> > > starting up.
> >
> > If this is about init files, we could instead make processing init
> > files assume lexical-binding by default.
>
> That's exactly what we should avoid because it can make Emacs not start
> up for init files that require the current default of dynamical binding.
How many of init files do indeed require dynamic binding? And why?
If a new Emacs version refuses to start because something in the init
files goes against some new Emacs feature, we have --debug-init and
other facilities to debug and fix those. Why should lexical-binding
be considered different from any other backward-incompatible change
that we sometimes do?
In any case, how will injecting the cookie help those users, exactly?
If people who write init files don't understand the implications of
lexical-binding, their Emacs will fail to start, something that you
think is a catastrophe. And if they do understand it, their init
files are already compatible with lexical-binding.
> We also should not assume dynamical binding: lexical binding is the
> default. Emacs should not guess: it should ask the user and then add a
> cookie. That's my point.
Your point seems to be incompatible with our plan, which is to turn on
lexical-binding by default at some point. We don't want to have a
schism of two separate flavors of Lisp, we want only one. The current
situation is a transitional period, not the ideal. You seem to be
suggesting that we should keep this situation forever, and that is not
what we decided, AFAIU.
- bug#66706: [PATCH] Automatic elisp dialect insertion, (continued)
- bug#66706: [PATCH] Automatic elisp dialect insertion, Eli Zaretskii, 2023/10/24
- bug#66706: [PATCH] Automatic elisp dialect insertion, Stefan Monnier, 2023/10/24
- bug#66706: [PATCH] Automatic elisp dialect insertion, Stefan Kangas, 2023/10/24
- bug#66706: [PATCH] Automatic elisp dialect insertion, Eli Zaretskii, 2023/10/24
- bug#66706: [PATCH] Automatic elisp dialect insertion, Stefan Monnier, 2023/10/25
- bug#66706: [PATCH] Automatic elisp dialect insertion, Stefan Kangas, 2023/10/25
- bug#66706: [PATCH] Automatic elisp dialect insertion, Dmitry Gutov, 2023/10/25
- bug#66706: [PATCH] Automatic elisp dialect insertion, Michael Heerdegen, 2023/10/25
- bug#66706: [PATCH] Automatic elisp dialect insertion, Eli Zaretskii, 2023/10/26
- bug#66706: [PATCH] Automatic elisp dialect insertion, Michael Heerdegen, 2023/10/26
- bug#66706: [PATCH] Automatic elisp dialect insertion,
Eli Zaretskii <=
- bug#66706: [PATCH] Automatic elisp dialect insertion, Michael Heerdegen, 2023/10/27
- bug#66706: [PATCH] Automatic elisp dialect insertion, Eli Zaretskii, 2023/10/27
- bug#66706: [PATCH] Automatic elisp dialect insertion, Stefan Monnier, 2023/10/27
- bug#66706: [PATCH] Automatic elisp dialect insertion, Eli Zaretskii, 2023/10/29
- bug#66706: [PATCH] Automatic elisp dialect insertion, Po Lu, 2023/10/24
- bug#66706: [PATCH] Automatic elisp dialect insertion, Po Lu, 2023/10/24
- bug#66706: [PATCH] Automatic elisp dialect insertion, Stefan Monnier, 2023/10/24
- bug#66706: [PATCH] Automatic elisp dialect insertion, Po Lu, 2023/10/24
- bug#66706: [PATCH] Automatic elisp dialect insertion, Stefan Monnier, 2023/10/25
- bug#66706: [PATCH] Automatic elisp dialect insertion, Dmitry Gutov, 2023/10/25