Subject: bug#74361: [PATCH] New option xref-navigation-display-window-action

From: martin rudalics <[email-masked]>
Date: Wed, 27 Nov 2024 09:58:03 +0100

> Just to note - in the patch that I've just pushed for Xref the
 > category ('xref-jump') doesn't describe the destination buffer but
 > only the command that is currently being executed. The destination
 > buffers are regular file buffers, usually not distinct from the other
 > file buffers belonging to the same project.

As I understand it, both 'xref--switch-to-buffer' and
'xref--display-buffer-in-window' prefer the selected window.  Only if
the selected window is not suitable, 'display-buffer-use-some-window'
could prefer a window with a 'xref-jump' 'category' parameter instead of
using the 'lru' window.  I don't think anyone would even notice the
difference.

If a user does

+  (setq display-buffer-alist '(((category . xref)
+                                (display-buffer-reuse-window
+                                 display-buffer-use-some-window)
+                                (some-window . mru))))

the 'some-window' entry on the last line would override any automagic in
'display-buffer-use-some-window' as I envision it anyway.

Is there any other 'display-buffer' call in xref.el that would set up a
category and prefer any other but the selected window?  IIUC
'xref--display-buffer-in-other-window' doesn't.  How would a user
customize its behavior?  Note that I'm completely ignorant of the
'xref--with-dedicated-window' trick - is there any reason why
'inhibit-same-window' is not sufficient here?

Personally, I think that a window parameter based choice could be even
better than 'mru' but Juri who uses 'mru' on a regular basis seems to be
fine with it.  For some users 'mru' might not DTRT when they temporarily
pop up a third window they use for showing some other, unrelated buffer
in between jumping to a sequence of references.

martin