bug#47843: 28.0.50; Setting enable-local-variables to nil *appears* to inhibit lexical-binding (but doesn't)

bug#47843: 28.0.50; Setting enable-local-variables to nil *appears* to inhibit lexical-binding (but doesn't)

[Phil Sainty]

With enable-local-variables set to nil, when editing an elisp buffer
using lexical-binding it can *seem* as though lexical-binding is not
enabled, as -*- lexical-binding: t -*- is being inhibited along with
any others.

Experimentally, Emacs appears to do the right thing, still evaluating
the code using lexical-binding.  I tested loading compiled and
uncompiled code, as well as `eval-buffer', and all of those seemed
to work correctly.

So, as far as I can, see the *only* issue is that inspecting the
local variable suggests differently.  This includes Emacs 28
displaying "elisp/d" (for dynamic binding) in the mode line instead
of "elisp/l".

Should an exception be made for this specific case, so that the
file-local variable is processed even if enable-local-variables
is nil?

bug#47843: 28.0.50; Setting enable-local-variables to nil *appears* to inhibit lexical-binding (but doesn't)

[Lars Ingebrigtsen]

Phil Sainty <psainty@orcon.net.nz> writes:

> With enable-local-variables set to nil, when editing an elisp buffer
> using lexical-binding it can *seem* as though lexical-binding is not
> enabled, as -*- lexical-binding: t -*- is being inhibited along with
> any others.
>
> Experimentally, Emacs appears to do the right thing, still evaluating
> the code using lexical-binding.  I tested loading compiled and
> uncompiled code, as well as `eval-buffer', and all of those seemed
> to work correctly.

enable-local-variables doesn't affect byte-compiling or loading the
file -- only the current buffer settings.

So I tried visiting this file, with enable-local-variables set to nil:

;; -*- lexical-binding: t; -*-

(defun foo ()
  (let ((a 1))
    (lambda ()
      (message "%s" a))))

(funcall (foo))

And `C-M-x' on the two forms failed, as expected.  (When enabling the
variable, they are successful.)

So I think everything works as expected here?  That is, the buffer
doesn't use lexical mode if you set enable-local-variables to nil.

Are you seeing something different?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#47843: 28.0.50; Setting enable-local-variables to nil *appears* to inhibit lexical-binding (but doesn't)

[Phil Sainty]

On 4/05/21 10:22 pm, Lars Ingebrigtsen wrote:
> `C-M-x' on the two forms failed, as expected.  (When enabling the
> variable, they are successful.)
> 
> So I think everything works as expected here?  That is, the buffer
> doesn't use lexical mode if you set enable-local-variables to nil.
> 
> Are you seeing something different?

I see the same thing.  I also note that `eval-region' produces the
same result as `eval-defun'.  (I'd only tested `eval-buffer' initially,
and that respects the `lexical-binding' setting.)

My main point was that I'm dubious that enable-local-variables should
be allowed to affect lexical-binding in any situation.

While it's strictly true that the lexical-binding implementation
utilises a file-local variable, I feel like this particular variable
should be guaranteed to be respected when set, because it fundamentally
changes how the code will be interpreted.

Are there are any other file-local variables in that same category?
I couldn't think of any offhand, and so this seemed worthy of having
an exception made.


-Phil

bug#47843: 28.0.50; Setting enable-local-variables to nil *appears* to inhibit lexical-binding (but doesn't)

[Lars Ingebrigtsen]

Phil Sainty <psainty@orcon.net.nz> writes:

> I see the same thing.  I also note that `eval-region' produces the
> same result as `eval-defun'.  (I'd only tested `eval-buffer' initially,
> and that respects the `lexical-binding' setting.)

Ah, right.  Hm...  well, I guess that's kinda logical?  But it's a bit
confusing; yes...

> My main point was that I'm dubious that enable-local-variables should
> be allowed to affect lexical-binding in any situation.
>
> While it's strictly true that the lexical-binding implementation
> utilises a file-local variable, I feel like this particular variable
> should be guaranteed to be respected when set, because it fundamentally
> changes how the code will be interpreted.
>
> Are there are any other file-local variables in that same category?
> I couldn't think of any offhand, and so this seemed worthy of having
> an exception made.

Hm...  can't think of any other variables like this, either.

I don't really have an opinion here -- I can see arguments for both
sides.  Perhaps Stefan has an opinion here (added to the CCs).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#47843: 28.0.50; Setting enable-local-variables to nil *appears* to inhibit lexical-binding (but doesn't)

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> Are there are any other file-local variables in that same category?
>> I couldn't think of any offhand, and so this seemed worthy of having
>> an exception made.
>
> Hm...  can't think of any other variables like this, either.
>
> I don't really have an opinion here -- I can see arguments for both
> sides.  Perhaps Stefan has an opinion here (added to the CCs).

Indeed, an exception would be welcome for that var, otherwise there will
be bad surprises.  We could probably have a variable holding a list of
vars that always obey file-local settings.


        Stefan

bug#47843: 28.0.50; Setting enable-local-variables to nil *appears* to inhibit lexical-binding (but doesn't)

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Indeed, an exception would be welcome for that var, otherwise there will
> be bad surprises.  We could probably have a variable holding a list of
> vars that always obey file-local settings.

Poking around for a couple of minutes, would the right way to implement
this be to always call `hack-local-variables' in `set-auto-mode' here?

    ;; hack-local-variables checks local-enable-local-variables etc, but
    ;; we might as well be explicit here for the sake of clarity.
    (and (not done)
	 enable-local-variables
	 local-enable-local-variables
	 try-locals
	 (setq mode (hack-local-variables t))

But then filter out all variables except the ones in this new list in
`hack-local-variables-filter' (if `enable-local-variables' is nil)?

The new list could be called...  uhm...
`permanently-enabled-local-variables'?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#47843: 28.0.50; Setting enable-local-variables to nil *appears* to inhibit lexical-binding (but doesn't)

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> Indeed, an exception would be welcome for that var, otherwise there will
>> be bad surprises.  We could probably have a variable holding a list of
>> vars that always obey file-local settings.
>
> Poking around for a couple of minutes, would the right way to implement
> this be to always call `hack-local-variables' in `set-auto-mode' here?
>
>     ;; hack-local-variables checks local-enable-local-variables etc, but
>     ;; we might as well be explicit here for the sake of clarity.
>     (and (not done)
> 	 enable-local-variables
> 	 local-enable-local-variables
> 	 try-locals
> 	 (setq mode (hack-local-variables t))
>
> But then filter out all variables except the ones in this new list in
> `hack-local-variables-filter' (if `enable-local-variables' is nil)?

Sounds about right.

> The new list could be called...  uhm...
> `permanently-enabled-local-variables'?

I like mine pink with grey octagons.


        Stefan

bug#47843: 28.0.50; Setting enable-local-variables to nil *appears* to inhibit lexical-binding (but doesn't)

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> But then filter out all variables except the ones in this new list in
>> `hack-local-variables-filter' (if `enable-local-variables' is nil)?
>
> Sounds about right.

I've now done something along these lines.  `hack-local-variables' was a
long and convoluted function, though, so hopefully I didn't mess
something up too badly.  I refactored it greatly, though, so it should
now be somewhat clearer.

>> The new list could be called...  uhm...
>> `permanently-enabled-local-variables'?
>
> I like mine pink with grey octagons.

If somebody wants to repaint it a different colour, that's fine by me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no