GNU bug report logs - #64272
28.1; lisp_file_lexically_bound_p behavior mismatches file local variables

Previous Next

Package: emacs;

Reported by: LdBeth <andpuke <at> foxmail.com>

Date: Sat, 24 Jun 2023 18:24:02 UTC

Severity: normal

Tags: confirmed

Merged with 67321

Found in versions 28.1, 29.1.90

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: LdBeth <andpuke <at> foxmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 64272 <at> debbugs.gnu.org
Subject: Re: bug#64272: 28.1;
 lisp_file_lexically_bound_p behavior mismatches file local variables
Date: Sat, 24 Jun 2023 21:52:31 +0300
> Date: Sat, 24 Jun 2023 13:22:38 -0500
> From: LdBeth <andpuke <at> foxmail.com>
> 
> 
> Basically, if an emacs lisp source file starts with some whitespace
> 
> | ;; -*- lexical-binding: t -*-
> |(let ((x 1)) (setq foo (lambda () x)))
> |(funcall foo)
> 
> rather than
> 
> |;; -*- lexical-binding: t -*-
> |(let ((x 1)) (setq foo (lambda () x)))
> |(funcall foo)
> 
> that will cause `load' eval the file with `lexical-binding' set to nil,
> and would report `x' is a void variable.
> 
> This behavior is in contrast to how file local variables are applied
> when opening a file, that is, as long as the variable list is in
> the first line, it is applied.
> 
> Either the documentation should bring up this behavior, or the
> C function `lisp_file_lexically_bound_p' in `src/lread.c' should be fixed.

I think we should do the latter, because
hack-local-variables-prop-line is more lenient than
lisp_file_lexically_bound_p.

Stefan, any comments?




This bug report was last modified 1 year and 156 days ago.

Previous Next


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