xref and displaying locations in appropriate window or frame

[Dmitry Gutov]

On 01/21/2016 08:07 PM, Eli Zaretskii wrote:

> I think having the *xref* buffer visible is _the_ reason we could get
> rid of tags-loop-continue.

Here's where I'm currently stumped:

xref-find-definitions has a family of commands (namely -other-window and 
-other-frame) which promise to display the location somewhere else than 
the current window.

If we're allowed to quit the *xref* buffer before jumping to the "final 
destination", we can nominally satisfy the contract by using 
switch-to-buffer or pop-to-buffer (maybe with pop-up-frames bound to t) 
after that. The *xref* buffer and its window are out of the picture by 
that point.

However, now we have the *xref* buffer back in the picture. I think that 
means we have to satisfy the this-window/other-window/other-frame 
contract while *xref* is displayed.

- xref-find-definitions-other-frame seems easiest: just bind 
pop-up-frames to t and call pop-to-buffer like before.
- xref-find-definitions promises to show the destination buffer in the 
current window. What will RET in *xref* do? Show the buffers in the 
window xref-find-definitions was called from? That seems to make the 
most sense, but it will obscure the original code. Maybe we'd want to 
consult it while picking the exact option among the suggested definitions?
- xref-find-definitions-other-window should, apparently, pick some 
window which isn't the original one, nor the one which displays the 
*xref* buffer. Or create a new one, in a pop-to-buffer fashion. Is there 
a function in window.el I can reuse, and/or display-buffer alist 
argument that would make it ignore whole two buffers, and not just the 
currently selected one?

Compilation has no such contract, so there's nothing corresponding in 
there that I could borrow.

Alternatively, we *do* treat xref-find-definitions differently, and 
don't keep the *xref* buffer visible after the user made their choice. 
But if the *xref* buffer looks the same as in other cases, it would be 
confusing. So ideally, we'd have a different choice-picking mechanism in 
this case (not *xref* buffer like it works and looks right now), but I 
really don't know where to start writing it (and don't want to do it now).

Yet alternatively, as soon as we find out that there are several 
definitions of the given function, we abandon all that 
other-window/other-frame business, and simply make RET always behave the 
same in *xref*. That seems like a cop-out. But maybe it's what we should 
do anyway until someone implements the second option (the previous 
paragraph).

> No, I think all the matches that the user saw already, whether she
> accepted the replacement or not, should be marked in some way, so that
> continuing the replacement goes to the first unseen one.

Good, that should be easier to do.