Re: xref and displaying locations in appropriate window or frame

[Eli Zaretskii]

> Cc: address@hidden, address@hidden, address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Sun, 24 Jan 2016 20:27:29 +0300
> 
> 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.

With RET, yes.  But this doesn't happen with '.'.  Isn't that
confusing?

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

RET runs xref-goto-xref, so whatever RET does, xref-goto-xref will do
the same, no?  What am I missing?

As for xref-show-location-at-point, it doesn't bury the *xref* buffer
when I try it now, so it looks like it already avoids hiding *xref*.

I have a terrible feeling that I'm missing something important here.

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

No, I don't think it's terrible.  There's always
xref-pop-marker-stack, right?

> (When there's only one option, jumping to it in the current window seems 
> best to me

I agree.