GNU bug report logs -
#74361
[PATCH] New option xref-navigation-display-window-action
Previous Next
Full log
View this message in rfc822 format
On 27/11/2024 10:58, martin rudalics wrote:
> > 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.
It does seem like it will switch to the "mru" kind of placement though:
as soon as "some" other window is used for xref-jump once, all the
following similar calls will follow it.
Might be an improvement, but definitely an incompatible change.
> 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.
Sure.
> Is there any other 'display-buffer' call in xref.el that would set up a
> category and prefer any other but the selected window?
By default, you mean?
> 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?
We want to select the new window in relation the "original" window (with
a file-visiting buffer), while avoiding touching the "results list"
window as well. E.g. when the original command was
xref-find-definitions-other-window.
It's probably not an ideal solution, but one settled on over several tries.
> 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.
Either seems reasonable to me, just as long as the choices can be
anticipated in advance by the user.
This bug report was last modified 170 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.