Re: missing lexical-binding cookie warning when loading .el files

[Po Lu <luangruo@yahoo.com>]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> Thanks for raising this concern. For now I settled on warning about
> *.el and .emacs only, on the grounds that it would eliminate at least
> some of the false positives.

But not all, not even all the packages in core, let alone ELPA.  It's
really not acceptable for Emacs to become a patchwork of warring
features, where no sooner does one feature save a file than does the
next feature proceed to pester the user to delete it.

> I do think it is appropriate to warn about the user init files because
> they tend to gather a lot of actual Lisp code, not just data. (New
> Emacs-generated init files should have a lexical cookie.)

That's a matter of opinion.

> Not sure how common pure data-as-code files are in reality; most Lisp
> data files aren't evaluated. Those that are are probably just
> sequences of function calls with constant arguments and thus rarely
> affected by lexical-binding.

newsrc.eld, desktop files (which do bear lexical-binding cookies), the
URL cookie list, generated custom themes, and the like.

> Now if data-as-code files turn out to be just too common and detecting
> them systematically too difficult, then I'd rather get rid of the
> warning altogether; it's not important enough to build an elaborate
> suppression system for, much less have endless discussions about.
>
> It's quite common to see other actual code files under ~/.emacs.d/,
> but maybe they are not worth warning about if it means too many false
> positives?
>
> Some options:
>
> A. Add a suppression system. We could add the variable
> `lisp-source-load-missing-lexical-binding-declaration-warning-suppression-regexp-list`.

I hope this is in jest.

> B. Strong-arm package maintainers into writing a lexical cookie when
> saving data-as-code.

Strong-arming users is hardly a laudable action on our part, or that of
any software developers at that.

> C. Don't warn about ~/.emacs.d/**/*.el, except init.el.

I thought the purpose of this warning was to detect bodies of Lisp code
of which the user might be unaware, to give him an opportunity to
futureproof them in time for Emacs 31.

> Z. Remove the warning.

Not the worst proposal I've heard.