GNU bug report logs -
#47843
28.0.50; Setting enable-local-variables to nil *appears* to inhibit lexical-binding (but doesn't)
Previous Next
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.
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):
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):
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):
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):
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):
>> 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):
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):
>> 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):
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.