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 10:56:03 -0400

>> I'm not a great fan of this `specbind` and maybe we could/should
>> inhibit the ask-supersession prompt in a more direct way, but I think
>> the patch below is an improvement (and should fix the "lsp-mode +
>> reformatter" case that triggered the current bug report).
>> 
>> Any objection to pushing it to `master`?
>
> TBH, I don't like this, because it just makes the issue more subtle.

Does it?  To me it makes the "inhibit ask-supersession" more clear:
`ask-supersession` is about warning when a buffer modification risks
creating a "fork" of the file, but when VISIT is non-nil
`insert-file-contents` actually erases local changes and brings the
buffer in-sync with the file so it cannot risk creating a fork (on the
contrary, it tends to undo a fork if there was one).

> IMO, if we want to solve this cleanly, we should introduce a variable
> which, when bound, causes ask-user-about-supersession-threat to do
> nothing and return.  Then insert-file-contents could bind that
> variable instead of buffer-file-name.  Alternatively, the test for
> this new variable could be in prepare_to_modify_buffer, here:
>
>   if (!NILP (BVAR (base_buffer, file_truename))
>       /* Make binding buffer-file-name to nil effective.  */
>       && !NILP (BVAR (base_buffer, filename))
>       && SAVE_MODIFF >= MODIFF)
>     Flock_file (BVAR (base_buffer, file_truename));
>
> As yet another alternative, we could add to the test above some other
> internal knob C variable that insert-file-contents could use, so that
> the above condition is not satisfied.

Ah, you're talking about something else: I'm talking about "when should
we inhibit ask-supersession" whereas you're talking about "how".

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


        Stefan

Previous Next

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