Re: xref and displaying locations in appropriate window or frame

[Eli Zaretskii]

> Cc: address@hidden, martin rudalics <address@hidden>,
>  Helmut Eller <address@hidden>
> From: Dmitry Gutov <address@hidden>
> Date: Sun, 24 Jan 2016 05:19:21 +0300
> 
> 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.

But AFAICS they only do that if there's a single candidate for the
definition, i.e. if the *xref* buffer is not displayed at all.  Which
confused the heck out of me the first time I tried "C-x 5 .", btw.

> 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.

Yes, I think so.  It will also fix the above confusion, IMO.

> - xref-find-definitions-other-frame seems easiest: just bind 
> pop-up-frames to t and call pop-to-buffer like before.

Right.

> - 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?

Yes, I think so.

> 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?

I don't think I understand you here.  By "obscure the original code"
do you mean the code will be harder to read?  Or do you mean something
else?

And what do you mean by "consult" -- consult what?

> - 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.

Probably, yes.

> 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?

I hope Martin will help you out here.

> 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).

I think we should try the former route first, it sounds simpler.

> 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.

I think this should change, it's a confusing inconsistency if the user
asked for another window/frame.

Thanks.