GNU bug report logs -
#78777
30.1; insert-file-contents should not set buffer-file-name to nil
Previous Next
Full log
Message #26 received at 78777 <at> debbugs.gnu.org (full text, mbox):
> From: Jimmy Yuen Ho Wong <wyuenho <at> gmail.com>
> Date: Sun, 15 Jun 2025 16:17:43 +0100
> Cc: 78777 <at> debbugs.gnu.org
>
> 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?
>
> I was never able to set up GDB as I'm on a Mac, so I actually am not sure if the signal_after_change call is
> made directly inside insert-file-contents. Looking at it again, it can't possibly be called there as that line is
> under the notfound label, which is only jumped to when the file descriptor is invalid.
>
> It is possible that some other Emacs internal machinery set the current buffer-file-name to nil temporarily and
> invoke signal_after_change after insert-file-contents has replaced the buffer content, but I have not been
> able to identify where. What is sure is a lone call to insert-file-contents runs the after-change-functions.
Yes, and that lone call is never made in your scenario.
So I'm no longer sure what problem are we discussing here.
This bug report was last modified 56 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.