Hi

that would be great. Maybe, just maybe, either start a discussion whether
we should assume lexical-binding as a default for the user configuration
(which was my understanding of a desirable future for Emacs) and, of
course, make sure this assumption holds. As stated somewhere recently,
*scratch* assumes lexical binding and many users test out their own code on
scratch before adding it to their configuration. In a list, options to
discuss would be:

1.- should init.el be assumed to use lexical binding?
2.- should files loaded by it be assumed to use lexical binding?
3.- should custom.el and early-init.el be assumed to use lexical binding?
4.- should we assume lexical binding by default and allow it to be disabled
with a mode line.

My .02 cents, /PA

On Sun, 5 May 2024 at 19:32, Jim Porter <jporterbugs@gmail.com> wrote:

> On 5/5/2024 1:43 AM, Mattias Engdegård wrote:
> > Angelo and Pedro, thank you for telling us! The warning hasn't been
> fine-tuned yet, but your reports may help us do that.
>
> Maybe warn only once about files under user-emacs-directory? Or only
> once for all files loaded before Emacs has fully-completed startup?
>
> As a bonus, we could offer a command that will add the lexical-binding
> cookie to all the files Emacs has noticed it's missing from. (Here, we
> could ask the user whether they want to keep lexical-binding off in
> those files for compatibility, or if they're prefer to upgrade to use
> lexical-binding, with the small risk of some breakage.)
>
> Getting spammed with warnings is surely annoying, but a single warning
> with a "fix it" button seems like it would be a lot better.
>
> And, as mentioned elsewhere in another thread, we could probably do with
> making it more obvious that you can suppress warnings. I was in a
> previous discussion about just that, and *still* forgot about it until
> someone reminded me.
>


-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet