Re: lexical-binding is turned on in more use cases

[Stefan Monnier]

> I do hope we're taking Alan's concern seriously here, all joking aside. This
> change pretty harshly violates the "principle of least surprise", and working
> with lexical-scope still isn't the norm for most old school Emacs Lispers. I'm
> not sure I wuold have ever discovered the solution to such a problem in my own
> debugging, had I not chanced on this discussion thread.
> What are we gaining, again, at the cost of this potential confusion?

The problem is real.  I don't think we can solve it without pain.

Basically, M-: doesn't easily know whether to use lexical-binding or not
because it's only connected to the buffer where the code will be
run but not to some source buffer where the "related" code might reside
(and which we could try and use to guess which mode to use).

You're probably right that "lexical-scope still isn't the norm for most
old school Emacs Lispers", so this change will irk those.  But my
impression is that the majority of *new* Elisp packages is using
lexical-binding nowadays, and the majority of Elisp snippets I see
quoted in StackExchange either work both ways or presume
lexical-binding (and then come with additional comments along the lines
of "I tried it and it didn't work ... indeed, you need to enable
lexical-binding by ... ah yes now it works").

It does remind me, tho, that we likely should introduce a `dlet` macro
to make it easy to do a dynamically scoped let-binding.  It'd be a much
cleaner solution than `(eval '...)` or `(progn (defvar ...) ...)`.
We already have it defined as `calendar-dlet*` and `mh-dlet*`.


        Stefan