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

Previous Next

Package: emacs;

Reported by: Phil Sainty <psainty <at> orcon.net.nz>

Date: Sat, 17 Apr 2021 13:53:02 UTC

Severity: normal

Tags: fixed

Found in version 28.0.50

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47843 in the body.
You can then email your comments to 47843 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#47843; Package emacs. (Sat, 17 Apr 2021 13:53:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Phil Sainty <psainty <at> orcon.net.nz>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 17 Apr 2021 13:53:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Setting enable-local-variables to nil *appears* to inhibit
 lexical-binding (but doesn't)
Date: Sun, 18 Apr 2021 01:51:51 +1200
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?





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#47843; Package emacs. (Tue, 04 May 2021 10:23:02 GMT) Full text and rfc822 format available.

Message #8 received at 47843 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 47843 <at> debbugs.gnu.org
Subject: Re: bug#47843: 28.0.50; Setting enable-local-variables to nil
 *appears* to inhibit lexical-binding (but doesn't)
Date: Tue, 04 May 2021 12:22:29 +0200
Phil Sainty <psainty <at> 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




Added tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Tue, 04 May 2021 10:23:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#47843; Package emacs. (Tue, 04 May 2021 11:46:01 GMT) Full text and rfc822 format available.

Message #13 received at 47843 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 47843 <at> debbugs.gnu.org
Subject: Re: bug#47843: 28.0.50; Setting enable-local-variables to nil
 *appears* to inhibit lexical-binding (but doesn't)
Date: Tue, 4 May 2021 23:45:12 +1200
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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#47843; Package emacs. (Wed, 05 May 2021 08:57:02 GMT) Full text and rfc822 format available.

Message #16 received at 47843 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 47843 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#47843: 28.0.50; Setting enable-local-variables to nil
 *appears* to inhibit lexical-binding (but doesn't)
Date: Wed, 05 May 2021 10:56:47 +0200
Phil Sainty <psainty <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#47843; Package emacs. (Wed, 05 May 2021 12:47:02 GMT) Full text and rfc822 format available.

Message #19 received at 47843 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Phil Sainty <psainty <at> orcon.net.nz>, 47843 <at> debbugs.gnu.org
Subject: Re: bug#47843: 28.0.50; Setting enable-local-variables to nil
 *appears* to inhibit lexical-binding (but doesn't)
Date: Wed, 05 May 2021 08:46:42 -0400
>> 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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#47843; Package emacs. (Thu, 06 May 2021 09:06:01 GMT) Full text and rfc822 format available.

Message #22 received at 47843 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Phil Sainty <psainty <at> orcon.net.nz>, 47843 <at> debbugs.gnu.org
Subject: Re: bug#47843: 28.0.50; Setting enable-local-variables to nil
 *appears* to inhibit lexical-binding (but doesn't)
Date: Thu, 06 May 2021 11:04:56 +0200
Stefan Monnier <monnier <at> 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




Removed tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Thu, 06 May 2021 09:06:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#47843; Package emacs. (Thu, 06 May 2021 13:33:02 GMT) Full text and rfc822 format available.

Message #27 received at 47843 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Phil Sainty <psainty <at> orcon.net.nz>, 47843 <at> debbugs.gnu.org
Subject: Re: bug#47843: 28.0.50; Setting enable-local-variables to nil
 *appears* to inhibit lexical-binding (but doesn't)
Date: Thu, 06 May 2021 09:32:04 -0400
>> 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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#47843; Package emacs. (Mon, 10 May 2021 10:43:01 GMT) Full text and rfc822 format available.

Message #30 received at 47843 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Phil Sainty <psainty <at> orcon.net.nz>, 47843 <at> debbugs.gnu.org
Subject: Re: bug#47843: 28.0.50; Setting enable-local-variables to nil
 *appears* to inhibit lexical-binding (but doesn't)
Date: Mon, 10 May 2021 12:42:02 +0200
Stefan Monnier <monnier <at> 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




Added tag(s) fixed. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 10 May 2021 10:43:02 GMT) Full text and rfc822 format available.

bug marked as fixed in version 28.1, send any further explanations to 47843 <at> debbugs.gnu.org and Phil Sainty <psainty <at> orcon.net.nz> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 10 May 2021 10:43:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 07 Jun 2021 11:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 296 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.