Re: [PATCH] hack-one-local-variable use lexical-binding

[Tom Gillespie <tgbugs@gmail.com>]

> > > This would be a backward-incompatible change, wouldn't it?
> >
> > I've made exactly this kind of incompatible change many times over
> > between Emacs-24 and now.  I don't think we should worry about it.
> >
> > > I'd prefer a backward compatible solution.  For example, how about
> > > a separate lexical-eval clause, which will do this leaving eval to
> > > work as it did before?
> >
> > As I said, that's over-engineering.
>
> We disagree.

After reflecting on this I think that there is an important difference
between the local variables list and the other special evaluation
contexts which might make this not over-engineered. In the M-:, ielm,
and scratch cases, there isn't an existing file, this is particularly
relevant where it would be important to always have the same behavior
in the minibuffer regardless of file. However, there is a file in the
case of an eval local variable. For consistency this means that the
file should have control over whether lexical or dynamic bindings is
used. As noted in my original email, the current implementation would
also allow users to control the lexical binding of the local variables
independent of the rest of the file. While I personally have never
encountered a case where someone explicitly sets lexical-binding: nil,
I imagine that it would be surprising if elisp code in a file with
that set was irreversibly forced into lexical mode despite the fact
that the configuration option already must be present in the file.
Obviously this would not be the case for non-elisp files, but since
the prop line lexical-binding infrastructure is going to be around for
the foreseeable future I'm not sure what there is to lose by simply
passing lexical-binding instead of t. Best,
Tom