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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: LdBeth <andpuke <at> foxmail.com>
Cc: 64272 <at> debbugs.gnu.org, andpuke <at> foxmail.com, monnier <at> iro.umontreal.ca
Subject: bug#64272: 28.1; lisp_file_lexically_bound_p behavior mismatches file local variables
Date: Sun, 25 Jun 2023 21:16:53 +0300

> Date: Sun, 25 Jun 2023 12:17:40 -0500
> From: LdBeth <andpuke <at> foxmail.com>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,
> 	andpuke <at> foxmail.com,
> 	64272 <at> debbugs.gnu.org
> 
> >>>>> In <83mt0ny47z.fsf <at> gnu.org> 
> >>>>>	Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> Eli> I'm not sure we want to support this outside of a Lisp comment.
> Eli> Stefan, WDYT?  Could false positives cause harm?
>  
> Stefan> I'd much rather we try and stay as close as possible to the behavior of
> Stefan> `hack-local-variables-prop-line`
> 
> Eli> The fact that most -*- lines are in comments is because they are in
> Eli> program source files, so we need to hide them from the compiler or the
> Eli> interpreter.
> 
> Eli> Am I missing something?
> 
> Ok I find the reason the `lisp_file_lexically_bound_p' would give
> up if the first line isn't a comment is, it said:
> 
>  Return true if the lisp code read using READCHARFUN defines a non-nil
>  `lexical-binding' file variable.  After returning, the stream is
>  positioned following the first line, if it is a comment or #! line,
>  otherwise nothing is read.
> 
> So this function assumes the first line is discarded if file local
> variables would have been read.
> 
> If first line is lisp code, and we want to keep the similar
> behavior of `hack-local-variables-prop-line`, there needs a mean
> to buffer the content of the first line. (Or reset file position
> but I don't think there is a way to do that without
> substantially change lread.c)

There isn't.  We can only unread one character at a time.

> But it would be easier to only handle the extra whitespace at
> beginning of file.

So now let me turn the table and ask: if we are only going to support
whitespace before the semicolon, then what exactly are we gaining
here?

Previous Next

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