bug#66061: 30.0.50; [PATCH] diff-buffer-with-file should reverse the order if the file is modified

[Eli Zaretskii]

> From: Bob Rogers <rogers@rgrjr.com>
> Date: Sun, 17 Sep 2023 16:54:41 -0700
> 
>    If you use diff-buffer-with-file in an unmodified buffer after the
> file has changed on disk, the buffer and file are logically reversed;
> the modified file is treated as the old version, and the original buffer
> as the new one.  It may seem like this is inconsistent, but since I am
> expecting diff to show me what has changed but instead find myself
> looking at the reverse, I find reading the resulting diff awkward and
> somewhat jarring.
> 
>    The attached patch reverses the order of the arguments to diff only
> when the buffer is unmodified.  Either the file has changed on disk, in
> which case it is probably newer, or it hasn't, in which case the diff
> will be empty anyway so the order doesn't matter (and that saves
> checking the actual file mod time).

I don't think we can automatically always reverse them in this case.
Here's a simple case where we shouldn't:

  . visit a file
  . make some edits
  . save the buffer to the file
  . copy from the backup file (or some other previous version) over
    the edited file on disk

I think only the user knows what is "old" and what is "new".  We
should, of course, allow the user to reverse them, but we shouldn't
reverse automatically.