Subject: Re: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil

From: Jimmy Yuen Ho Wong <[email-masked]>
Date: Sun, 15 Jun 2025 17:30:47 +0100

>
> I understand what you are saying, but not why you think it's a bug.
> Once again, the call to after-change-functions in this scenario is
> done not from insert-file-contents, but from the function that decodes
> the text read from the file.  That function runs in a temporary
> buffer, which has no associated file name.
>

Because the docstring of after-change-functions says the hooks are called
with the current buffer, and the current buffer at the time
insert-file-contents is called, is the file buffer, not the code conversion
buffer. The message printed out also indicated that the current buffer at
the time the after-change-functions lambda is called is indeed the file
buffer, not the code conversion buffer. The file buffer's buffer-file-name
should not be set to nil by insert-file-contents or any function it
calls. As far as I know, only `insert-file-contents` exhibits this
undocumented behavior for any functions that change buffer contents.

The guarantee of after-change-functions being called with the current
buffer isn't very useful if crucial variables of the current buffer such as
the buffer file name cannot also be guaranteed to remain the same. This use
case is illustrated by the tickets I linked to in my original report. There
exist many file formatter packages that replace the content of the current
buffer with a temporary file with the formatted file content inside a
before-save-hook due to slowness of replace-buffer-content. When these
packages are used in combination with lsp-mode, which has a function added
to after-change-functions that needs access to the current buffer's file
name in order to synchronize the document between the editor and the
language server.