GNU bug report logs -
#74361
[PATCH] New option xref-navigation-display-window-action
Previous Next
Full log
Message #176 received at 74361 <at> debbugs.gnu.org (full text, mbox):
> 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
This bug report was last modified 171 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.