Re: xref and displaying locations in appropriate window or frame

[Dmitry Gutov <dgutov@yandex.ru>]

On 01/24/2016 05:43 PM, Eli Zaretskii wrote:

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

Having tried this, I don't think this is feasible.

First, if xref-show-location-at-point (called when ./,/n/p is pressed) 
tries to satisfy the "other frame" contract, if the user hasn't done 
some special frame-related configuration, doesn't use a tiling window 
manager, etc, we get the location buffer displayed in a new, selected 
frame on top of the current one. There's no way to keep pressing "n" or 
"p" to jump through the locations.

Second, we shouldn't use one strategy in xref-show-location-at-point, 
and another in xref-goto-xref: even if the user wanted to see the target 
in a new frame, they are unlikely to appreciate seeing it both in "some 
other" window in the current frame, and in the new frame as well after 
they press RET.

So, retaining the other-frame contract is out. other-window is easier, 
but, like Martin noted, the approach available to us (show in some 
window that's not the original one, and not the xref one) is also iffy, 
because it might be not _the_ "other window" respective to the original 
one. The xref buffer could very well be displayed in that window, so we 
can't use it.

Further, even though the user asked to display the destination using a 
particular approach, by the time they choose the location from the list, 
they might have forgotten their original request: several commands will 
have passed by that time.

Overall, when the xref buffer gets to be displayed, I think always using 
the "some other window" seems best after. We could also implement the 
this-window/other-frame modifiers for xref-goto-xref later.

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

The inconsistency is unfortunate, but it stems from our attempt to 
shoehorn the xref buffer into two different use cases.

Ultimately, I think the multiple-choice xref-find-definitions case would 
be better served by a selection UI that emphasizes its transitiveness, 
goes away as soon as the user made their choice, and itself has no 
long-term impact on the window configuration.

It's probably best implemented using an overlay of some sort on top of 
the current frame. See the similar feature in Atom (who inherited it 
from Sublime) on the screenshots here: 
https://atom.io/docs/latest/using-atom-moving-in-atom

I went in that direction in xref previously, when all changes made to 
the window configuration by ,/./n/p were being undone before the next 
command. But that was a half-measure anyway, and the "transient" 
interface doesn't serve other commands well (those where you usually 
want to operate on several locations from the list, and not just pick 
one and forget the other matches).

It's worth noting that SLIME uses its xref buffer exactly in a transient 
fashion, and Helmut's contribution had that behavior, but I've come to 
believe it's a mistake.