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