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

Previous Next

To reply to this bug, email your comments to 66061 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Bob Rogers <rogers <at> rgrjr.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50;
 [PATCH] diff-buffer-with-file should reverse the order if the file is
 modified
Date: Sun, 17 Sep 2023 16:54:41 -0700

[Message part 1 (text/plain, inline)]

   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

[diff-buffer-with-file-rev-if-disk-changed-1.patch (text/x-patch, inline)]

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)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Bob Rogers <rogers <at> rgrjr.com>
Cc: 66061 <at> debbugs.gnu.org
Subject: Re: bug#66061: 30.0.50;
 [PATCH] diff-buffer-with-file should reverse the order if the file is
 modified
Date: Mon, 18 Sep 2023 13:47:39 +0300

> From: Bob Rogers <rogers <at> 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.

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

From: Bob Rogers <rogers <at> rgrjr.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 66061 <at> debbugs.gnu.org
Subject: Re: bug#66061: 30.0.50;
 [PATCH] diff-buffer-with-file should reverse the order if the file is
 modified
Date: Mon, 18 Sep 2023 09:03:37 -0700

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

   > From: Bob Rogers <rogers <at> 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

Previous Next

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