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

I don't disagree.  My only concern was extra complexity and
performance of file-exists-p for such rare case.  But if this
is not a problem, here is a patch over the previous patch: