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: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: handa <at> gnu.org, wyuenho <at> gmail.com, 78777 <at> debbugs.gnu.org
Subject: bug#78777: 30.1; insert-file-contents should not set buffer-file-name to nil
Date: Thu, 19 Jun 2025 13:10:30 -0400

>> Ah, you're talking about something else: I'm talking about "when should
>> we inhibit ask-supersession" whereas you're talking about "how".
> Yes, because I see no reason to change the "when".  We had zero
> problems with it since it was introduced long ago.

Oh, well for me the reason is: to make the code understandable.

Also, I think the code as it stands is wrong (which is part of the
reason why it's hard to understand) in the reformatter-case
(where we (well, they) use `insert-file-contents` to REPLACE the
buffer's content with that of another file (which, in that case,
contains a reformatted version of the buffer's contents)), because it
will fail to prompt the user about the change you're performing
this way.  E.g.

- Start with:

      % src/emacs -Q BUGS &
      % echo foo >>BUGS

- In the Emacs session type:

      a

  Notice how Emacs prompts about "changed on disk, really edit".
  Hit `C-g` so we don't actually edit the buffer.

- In the Emacs session do:

      M-: (insert-file-contents "README" nil nil nil t) RET

  Notice how Emacs just blindly changed the contents of the buffer
  without prompting about "changed on disk, really edit".

I think this last step is an error, we should be prompted just as we are
with any other buffer modification that diverges from the file's contents.

>> > IMO, any of these alternatives is better than your proposal, because
>> > it solves the problem completely, not partially, and because it
>> > doesn't run any risks of regressions due to the VISIT case which until
>> > now did not matter.
>> 
>> IOW, at least in my mind, the code as it stands is mysterious, whereas
>> with the `!NILP (visit)` it makes perfect sense.  This is orthogonal to
>> whether we want to inhibit ask-supersession by binding
>> `buffer-file-name` or via some other (new) mechanism.
>
> But then this bug report is not the right place to discuss your
> suggestions, right?

Except that it's where I discovered the problem and that it happens to
make the OP's problem disappear.  IOW, we have now 3 ways to fix the
PS's problem, all of which have other benefits.  I don't think we need
to choose: we should apply all three (except that the third needs to
be done in `lsp-mode` so it's not under our control).


        Stefan

Previous Next

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