[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: xref and displaying locations in appropriate window or frame

From: Eli Zaretskii
Subject: Re: xref and displaying locations in appropriate window or frame
Date: Sun, 24 Jan 2016 17:43:42 +0200

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


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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]