Re: xref and displaying locations in appropriate window or frame

[Dmitry Gutov <dgutov@yandex.ru>]

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

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

They do it for the final destination, but not for buffers temporarily 
displayed when you press `n' or `p'. E.g.:

Press `C-x 4 .', type log-edit-menu, pick an element, press RET - and 
you'll see its location displayed in the "other" window. Same with `C-x 
5 .', though to see the expected effect the destination buffer must not 
be already displayed in the current frame.

But if we're not allowed to hide *xref* on RET either, xref-goto-xref 
and xref-show-location-at-point's behavior should be close to this, and 
only differ in which window ends up being selected.

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

I only mean that the original buffer will be hidden, and the user won't 
be able to look at its contents while making the choice. Which might be 
considered bad, for the default behavior. Maybe not too terrible, though.

(When there's only one option, jumping to it in the current window seems 
best to me, so changing M-. to be bound to 
xref-find-definitions-other-window instead doesn't seem like a good 
alternative.)