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

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

[Bob Rogers]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 2020 bytes --]

   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).  If the buffer is modified, then it
could be that both have changed, but then it's a tossup which should go
first.

   Note that this doesn't affect the user experience of typing C-c C-c
in the resulting diff buffer; it still takes you to the same place in
the buffer.  (After asking if you want to revert, every single time.
Which could be the subject of another bug/enhancement.)

					-- Bob Rogers
					   http://www.rgrjr.com/

------------------------------------------------------------------------
In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.34, cairo version 1.16.0) of 2023-09-14 built on orion
Repository revision: 1442f4043a7
Repository branch: rgr-smtpmail-env-from
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: openSUSE Leap 15.5

Configured using:
 'configure --with-dbus=no --with-gsettings=no --with-gif=ifavailable
 --with-tiff=no --with-gnutls=yes --with-gconf=no'

Configured features:
ACL CAIRO FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ JPEG LIBSELINUX LIBXML2
MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS
TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix


[-- Attachment #2: Type: text/x-patch, Size: 854 bytes --]

diff --git a/lisp/vc/diff.el b/lisp/vc/diff.el
index a411d98da31..dfa44fc00d6 100644
--- a/lisp/vc/diff.el
+++ b/lisp/vc/diff.el
@@ -266,7 +266,13 @@ diff-buffer-with-file
     (with-current-buffer (or (buffer-base-buffer buf) buf)
       (unless buffer-file-name
         (error "Buffer is not visiting a file"))
-      (diff buffer-file-name (current-buffer) nil 'noasync))))
+      ;; If the buffer is unmodified, then the file version may be
+      ;; newer, so use the buffer as the old version.
+      (if (buffer-modified-p)
+          ;; Assume the buffer is newer (though both could be modified).
+          (diff buffer-file-name (current-buffer) nil 'noasync)
+        ;; Disk version may be newer.
+        (diff (current-buffer) buffer-file-name nil 'noasync)))))
 
 ;;;###autoload
 (defun diff-buffers (old new &optional switches no-async)

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.

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

[Bob Rogers]

   From: Eli Zaretskii <eliz@gnu.org>
   Date: Mon, 18 Sep 2023 13:47:39 +0300

   > From: Bob Rogers <rogers@rgrjr.com>
   > Date: Sun, 17 Sep 2023 16:54:41 -0700
   > 
   > . . .
   >
   > 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 thought of that, but figured this was a much less likely scenario, and
could be ignored for the sake of getting closer to the right thing.

   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.

Fair enough.  I suppose M-x diff-reverse-direction is not that much
extra trouble.  (I should probably find a keybinding for it.)

					-- Bob