bug#64272: 28.1; lisp_file_lexically_bound_p behavior mismatches file local variables

[Eli Zaretskii]

> Date: Sun, 25 Jun 2023 12:17:40 -0500
> From: LdBeth <andpuke@foxmail.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>       andpuke@foxmail.com,
>       64272@debbugs.gnu.org
> 
> >>>>> In <83mt0ny47z.fsf@gnu.org> 
> >>>>> Eli Zaretskii <eliz@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?