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

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> And furthermore, please exempt all generated files that are generated
> without lexical-binding cookies from such warnings.  The init file is
> one, the custom file is another, which I've not yet decided how to
> exempt, and which at any rate is indifferent to the state of lexical
> binding.

Not to mention .newsrc, Custom-theme.el etc.  It's a fair bet that
generated data files which behave identically in both binding modes are
never byte-compiled, from which it follows that this change, as it
stands, is more disruptive than it is helpful, except in relation to the
few _code_ files that are frequently loaded without being byte-compiled.

Presumably, users who fall victim to unmarked files do so through
require, not plain Fload, which is more the domain of packages that load
data files, such as custom, desktop, and Gnus.  If there are no serious
objections, I will modify the criteria for the warning accordingly, to
only emit them when the file concerned is loaded as a library.

It could subsequently be arranged that what few files are often loaded
without lexical binding cookies and otherwise than by require prompt
these warnings unconditionally.  Still, I'm not entirely satisfied with
the practice of emitting warnings in one release for prospective changes
in the next: it might reflect negatively on us if we should decide
against them, and how is it productive to enjoin users to update their
code years in advance, for a change that is far from a done deal, and
for an Emacs release that it is every right of theirs not to install?

One example: it's been 4 years since configure started to state that Xft
would be removed "in the next release of Emacs", yet two releases have
since run their course, with no end to Xft support in sight.  Nor will
it be removed, so long as I'm still around and the Cairo build continues
to generate problems in situations other than it was designed to solve.