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