Why does byte-compile-file copy the input file to a different buffer?

Why does byte-compile-file copy the input file to a different buffer?

[Alan Mackenzie]

Hello, Emacs.

On executing a byte-compile-file command, rather than working on the
file's buffer directly, the byte compiler first copies the buffer/file
into another buffer with a boring name like " *Compiler Input*" or "
*Compiler Input*-1".

Why does it do this?  It makes it difficult, in the reader, to determine
the identity of the actual source buffer.  (Yes, I have reasons for
wanting to do this.)

Would it not be simpler just to compile directly from the source buffer,
thus avoiding a needless copying and making it clear what the actual
source buffer is?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Why does byte-compile-file copy the input file to a different buffer?

[Eli Zaretskii]

> Date: Sun, 17 Dec 2023 16:06:44 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> On executing a byte-compile-file command, rather than working on the
> file's buffer directly, the byte compiler first copies the buffer/file
> into another buffer with a boring name like " *Compiler Input*" or "
> *Compiler Input*-1".
> 
> Why does it do this?  It makes it difficult, in the reader, to determine
> the identity of the actual source buffer.  (Yes, I have reasons for
> wanting to do this.)
> 
> Would it not be simpler just to compile directly from the source buffer,
> thus avoiding a needless copying and making it clear what the actual
> source buffer is?

The command uses insert-file-contents to insert the file into the
input buffer, and works on that, so that looks very natural to me.
I'm not sure what is bothering you in that, or why.

Re: Why does byte-compile-file copy the input file to a different buffer?

[Alan Mackenzie]

Hello, Eli.

On Sun, Dec 17, 2023 at 18:48:32 +0200, Eli Zaretskii wrote:
> > Date: Sun, 17 Dec 2023 16:06:44 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > On executing a byte-compile-file command, rather than working on the
> > file's buffer directly, the byte compiler first copies the buffer/file
> > into another buffer with a boring name like " *Compiler Input*" or "
> > *Compiler Input*-1".

> > Why does it do this?  It makes it difficult, in the reader, to determine
> > the identity of the actual source buffer.  (Yes, I have reasons for
> > wanting to do this.)

> > Would it not be simpler just to compile directly from the source buffer,
> > thus avoiding a needless copying and making it clear what the actual
> > source buffer is?

> The command uses insert-file-contents to insert the file into the
> input buffer, and works on that, so that looks very natural to me.
> I'm not sure what is bothering you in that, or why.

From inside the reader, the buffer " *Compiler Input*" is effectively
anonymous: it gives no clue as to what the actual file or buffer is.  If
the byte compiler actually loaded the source file into a buffer with the
normal name (e.g. bytecomp.el), that name would be available for use in
the reader.

Identifying the source presented to the reader is a difficult business.
Quite bluntly, the code in lread.c is showing its age.  Sometimes a file
is loaded (and thus also read) by fragmented direct file access
routines.  Other times the reader is invoked from a file's buffer, other
times from an anonymous buffer such as " *Compiler Input*".

All I want is the name of the real buffer, or failing that, the name of
the real file.  When the reader sees " *Compiler Input*" does it have to
assume that byte-compile-current-file is bound and use that?  Even
recognising " *Compiler Input*-1" in C code is difficult - there're no
string functions in Emacs which can test that a given string is a prefix
of another string.  There's string-match, but it only works with a
regular expression, not a plain string.  By the time I put that sort of
code into a C routine, it is so bulky, it drowns out the prime purpose
of the routine.

It's difficult.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Why does byte-compile-file copy the input file to a different buffer?

[Eli Zaretskii]

> Date: Sun, 17 Dec 2023 17:09:28 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > The command uses insert-file-contents to insert the file into the
> > input buffer, and works on that, so that looks very natural to me.
> > I'm not sure what is bothering you in that, or why.
> 
> >From inside the reader, the buffer " *Compiler Input*" is effectively
> anonymous: it gives no clue as to what the actual file or buffer is.

This doesn't appear to be true, since byte-compile-file binds
buffer-file-name to the name of the file whose contents it inserted.
It does that only temporarily, for calling normal-mode, but maybe we
could just do that for the entire duration of the compilation.

> All I want is the name of the real buffer, or failing that, the name of
> the real file.  When the reader sees " *Compiler Input*" does it have to
> assume that byte-compile-current-file is bound and use that?  Even
> recognising " *Compiler Input*-1" in C code is difficult - there're no
> string functions in Emacs which can test that a given string is a prefix
> of another string.  There's string-match, but it only works with a
> regular expression, not a plain string.  By the time I put that sort of
> code into a C routine, it is so bulky, it drowns out the prime purpose
> of the routine.
> 
> It's difficult.

If all you need is to have buffer-file-name set to the file's name, I
think that can be arranged relatively easily.

Re: Why does byte-compile-file copy the input file to a different buffer?

[Alan Mackenzie]

Hello, Eli.

On Sun, Dec 17, 2023 at 19:18:08 +0200, Eli Zaretskii wrote:
> > Date: Sun, 17 Dec 2023 17:09:28 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > The command uses insert-file-contents to insert the file into the
> > > input buffer, and works on that, so that looks very natural to me.
> > > I'm not sure what is bothering you in that, or why.

> > >From inside the reader, the buffer " *Compiler Input*" is effectively
> > anonymous: it gives no clue as to what the actual file or buffer is.

> This doesn't appear to be true, since byte-compile-file binds
> buffer-file-name to the name of the file whose contents it inserted.
> It does that only temporarily, for calling normal-mode, but maybe we
> could just do that for the entire duration of the compilation.

> > All I want is the name of the real buffer, or failing that, the name of
> > the real file.  When the reader sees " *Compiler Input*" does it have to
> > assume that byte-compile-current-file is bound and use that?  Even
> > recognising " *Compiler Input*-1" in C code is difficult - there're no
> > string functions in Emacs which can test that a given string is a prefix
> > of another string.  There's string-match, but it only works with a
> > regular expression, not a plain string.  By the time I put that sort of
> > code into a C routine, it is so bulky, it drowns out the prime purpose
> > of the routine.

> > It's difficult.

> If all you need is to have buffer-file-name set to the file's name, I
> think that can be arranged relatively easily.

I've worked out what I need.  And that's to be able to identify the text
source of a call to the reader on the basis of the parameter STREAM
(also know as READCHARFUN).

I put a printf into one of read's subroutines, printing out the buffer
name for each call where STREAM was a buffer.  All it output was *load*
and  *Compiler Input*.  :-(

It's all very well binding buffer-file-name for some reader calls, but
then for other reader calls it will be load-file-name, and I'd be
surprised if there weren't more dynamic variables holding file and
buffer names which would need to be examined.

If we're loading or compiling a .el file, and it gets fetched into a
buffer for that purpose, why can't that buffer be called "bytecomp.el"
(or even "bytecomp.el<2>"), rather than "*load*" or " *Compiler Input*"?
That way, the source for the read operation would be identified by the
buffer name.

-- 
Alan Mackenzie (Nuremberg, Germany).