GNU bug report logs - #65854
Multi-file replacement diff

Previous Next

Full log

Message #67 received at 65854 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: me <at> eshelyaron.com, 65854 <at> debbugs.gnu.org
Subject: Re: bug#65854: Multi-file replacement diff
Date: Sun, 24 Sep 2023 11:12:51 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: me <at> eshelyaron.com,  65854 <at> debbugs.gnu.org
> 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.

Previous Next

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