Subject: Re: bug#65854: Multi-file replacement diff

From: Eli Zaretskii <[email-masked]>
Date: Sun, 24 Sep 2023 11:12:51 +0300

> From: Juri Linkov <[email-masked]>
> Cc: [email-masked],  [email-masked]
> Date: Sun, 24 Sep 2023 10:37:54 +0300
> 
> >> >> >> +                                                    However, when the file
> >> >> >> +is not visited in a buffer, or the buffer is not modified, still read
> >> >> >> +contents from the file."
> >> >> >
> >> >> > Seems to describe an implementation detail, and I don't think it
> >> >> > should be there.  E.g., what if the file visited by the buffer no
> >> >> > longer exists?
> >> >>
> >> >> If the file visited by the buffer no longer exists, then
> >> >> the standard error is signaled.
> >> >
> >> > Which means in that case it is better to use the buffer text, no?
> >>
> >> Since replacement diffs are not supported in non-file buffers,
> >> better to signal an error for heads up.
> >
> > But it _is_ a file-visiting buffer.  It's just that its file was
> > deleted meanwhile.
> 
> The generated diff could not be applied to the deleted file.
> So generating a diff to the deleted file makes no sense anyway.

I suggest not to second-guess what the user wants to do with the
generated diffs.  What if they just want to email it or something?

The basic rule of the least surprise is pertinent here: we have the
data, so why not generate the diffs when we can?

But if you feel strongly about signaling an error in that case, I
won't object.