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

[Tom Gillespie]

> Once lexical-binding becomes t by default, 'eval' will use
> lexical-binding.

So ultimately better not to rely on the default value of
lexical-binding at all. Is there a way to pass LEXICAL t unless a file
local variable explicitly sets lexical-binding to nil? This would be
equivalent to fast forwarding this particular part of the
implementation in time as if it were already in the future where
lexical-binding was true by default. Almost certainly not worth the
complexity.

> IOW, this change will be a backward-incompatible one no matter what we
> do.  IMO, it makes much more sense to make such a change when we
> switch to lexical-binding by default rather than now.

This makes sense. I don't think there is a particular hurry on this,
but if there were a simple way to make this subsystem behave as if
lexical-binding were t by default (sounds like the answer there will
be no) then the change could be made now and the breaking of the
default behavior would still happen only once. If the additional
changes needed to do that are too extensive, then it is probably
better just to wait.

The only outstanding question to me is whether users would be able to
control whether the eval local variable uses lexical binding at all
even in the future. I can imagine that when the switch to
lexical-binding being t by default happens there will be a need for an
escape hatch

> can use a special construct.

It crosses my mind that one potential solution would be lexical-eval:
and dynamic-eval: local variables, but this seems like it might not be
worth the added complexity. On the other hand, it would make it
completely unambiguous to a user inspecting a file what behavior will
be and make that behavior independent of any differences in local
settings or future changes to defaults. In the few cases where an
author knows lexical vs dynamic matters, it would definitely be
simpler for the author of the local variables to say "this always
needs to be dynamically evaluated" and then not have to worry about it
in the future.

Best,
Tom