GNU bug report logs - #78777
30.1; insert-file-contents should not set buffer-file-name to nil

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jimmy Yuen Ho Wong <wyuenho <at> gmail.com>
Cc: 78777 <at> debbugs.gnu.org
Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil
Date: Mon, 16 Jun 2025 12:09:14 +0300

> From: Jimmy Yuen Ho Wong <wyuenho <at> gmail.com>
> Date: Sun, 15 Jun 2025 17:30:47 +0100
> Cc: 78777 <at> debbugs.gnu.org
> 
>  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.

OK, I see what happens.  insert-file-contents intentionally binds
buffer-file-name temporarily to nil when it is called with REPLACE
non-nil, during the deletion or insertion from the code-conversion
buffer.  It does that to avoid prompting the user via
ask-user-about-supersession-threat, which in this case will confuse.

So this is a feature, an intentional behavior.

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

I suggest that buffer-modification hooks use buffer-file-truename
instead, it will provide the correct file name in this (and other)
cases.

Previous Next

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