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: Sun, 15 Jun 2025 18:00:12 +0300

> From: Jimmy Yuen Ho Wong <wyuenho <at> gmail.com>
> Date: Sun, 15 Jun 2025 15:45:02 +0100
> Cc: 78777 <at> debbugs.gnu.org
> 
>  I think your after-change-function is called not due to
>  insert-file-contents inserting the text from the file, but from the
>  functions that decode the file's text.  To see if this is true, make
>  your after-change-function show the name of the current buffer.  If
>  I'm right, you will see something like " *code conversion works" as
>  the name of the buffer, in which case indeed buffer-filename is
>  expected to be nil, and I don't see a bug here.
> 
>  I have suspected the same as the only call to set a buffer's name to nil is found in the implementation of
> insert-file-contents near the code conversion buffer, but that's a red herring. As you can see from my
> report, the after-change-function does contain a call to (current-buffer), and the message prints out the file
> buffer's name correctly.

That's not what I see.  The only call to after-change-functions that
insert-file-contents does is not done in your recipe: if I set a
breakpoint there, it is never hit.

So I have no doubt that what you see is an unrelated call to
after-change-functions.  The evidence that current-buffer returns the
buffer name you expect is not enough: the actual current buffer can be
different, and I saw it in GDB.

So, given what I see under a debugger, there's no bug here.

Why did you think insert-file-contents should at all call
after-change-functions in this scenario?

Previous Next

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