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

Previous Next

Full log

Message #32 received at 78777 <at> debbugs.gnu.org (full text, mbox):

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

> From: Jimmy Yuen Ho Wong <wyuenho <at> gmail.com>
> Date: Sun, 15 Jun 2025 16:40:42 +0100
> Cc: 78777 <at> debbugs.gnu.org
> 
>  Yes, and that lone call is never made in your scenario.
> 
>  So I'm no longer sure what problem are we discussing here.
> 
> The lone call to insert-file-contents, as in step 5 of my reproduction. Calling insert-file-contents after typing in
> a file buffer runs the after-change-functions hooks. When these hooks are run, the current buffer's file name
> is seen to have been temporarily set to nil, which should not be the case.
> 
> Is this clear?

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.

The Subject of this bug says "insert-file-contents should not set
buffer-file-name yo nil", but what I found that insert-file-contents
doesn't set buffer-file-name to nil.  It's an illusion created by the
way you use after-change-functions.

Previous Next

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