unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#47843: 28.0.50; Setting enable-local-variables to nil *appears* to inhibit lexical-binding (but doesn't)
@ 2021-04-17 13:51 Phil Sainty
  2021-05-04 10:22 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 7+ messages in thread
From: Phil Sainty @ 2021-04-17 13:51 UTC (permalink / raw)
  To: 47843

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?






^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#47843: 28.0.50; Setting enable-local-variables to nil *appears* to inhibit lexical-binding (but doesn't)
  2021-04-17 13:51 bug#47843: 28.0.50; Setting enable-local-variables to nil *appears* to inhibit lexical-binding (but doesn't) Phil Sainty
@ 2021-05-04 10:22 ` Lars Ingebrigtsen
  2021-05-04 11:45   ` Phil Sainty
  0 siblings, 1 reply; 7+ messages in thread
From: Lars Ingebrigtsen @ 2021-05-04 10:22 UTC (permalink / raw)
  To: Phil Sainty; +Cc: 47843

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#47843: 28.0.50; Setting enable-local-variables to nil *appears* to inhibit lexical-binding (but doesn't)
  2021-05-04 10:22 ` Lars Ingebrigtsen
@ 2021-05-04 11:45   ` Phil Sainty
  2021-05-05  8:56     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 7+ messages in thread
From: Phil Sainty @ 2021-05-04 11:45 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 47843

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#47843: 28.0.50; Setting enable-local-variables to nil *appears* to inhibit lexical-binding (but doesn't)
  2021-05-04 11:45   ` Phil Sainty
@ 2021-05-05  8:56     ` Lars Ingebrigtsen
  2021-05-05 12:46       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 7+ messages in thread
From: Lars Ingebrigtsen @ 2021-05-05  8:56 UTC (permalink / raw)
  To: Phil Sainty; +Cc: 47843, Stefan Monnier

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#47843: 28.0.50; Setting enable-local-variables to nil *appears* to inhibit lexical-binding (but doesn't)
  2021-05-05  8:56     ` Lars Ingebrigtsen
@ 2021-05-05 12:46       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2021-05-06  9:04         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-05-05 12:46 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Phil Sainty, 47843

>> 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






^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#47843: 28.0.50; Setting enable-local-variables to nil *appears* to inhibit lexical-binding (but doesn't)
  2021-05-05 12:46       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2021-05-06  9:04         ` Lars Ingebrigtsen
  2021-05-06 13:32           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 7+ messages in thread
From: Lars Ingebrigtsen @ 2021-05-06  9:04 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Phil Sainty, 47843

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#47843: 28.0.50; Setting enable-local-variables to nil *appears* to inhibit lexical-binding (but doesn't)
  2021-05-06  9:04         ` Lars Ingebrigtsen
@ 2021-05-06 13:32           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 7+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-05-06 13:32 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Phil Sainty, 47843

>> 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






^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2021-05-06 13:32 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-17 13:51 bug#47843: 28.0.50; Setting enable-local-variables to nil *appears* to inhibit lexical-binding (but doesn't) Phil Sainty
2021-05-04 10:22 ` Lars Ingebrigtsen
2021-05-04 11:45   ` Phil Sainty
2021-05-05  8:56     ` Lars Ingebrigtsen
2021-05-05 12:46       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-05-06  9:04         ` Lars Ingebrigtsen
2021-05-06 13:32           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors

unofficial mirror of bug-gnu-emacs@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/emacs-bugs/0 emacs-bugs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 emacs-bugs emacs-bugs/ https://yhetil.org/emacs-bugs \
		bug-gnu-emacs@gnu.org
	public-inbox-index emacs-bugs

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.emacs.bugs
	nntp://news.gmane.io/gmane.emacs.bugs


code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/emacs.git

AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git