On Thu, Jun 19, 2025 at 6:30 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Cc: eliz@gnu.org,  wyuenho@gmail.com,  78777@debbugs.gnu.org
> > Date: Wed, 18 Jun 2025 15:49:07 -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.
>
> 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.
>
> 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.
>


I agree either of these approaches is better than binding buffer-file-name
to nil at any point in time during the execution of insert-file-contents.