[Top][All Lists]

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

xref and displaying locations in appropriate window or frame

From: Dmitry Gutov
Subject: xref and displaying locations in appropriate window or frame
Date: Sun, 24 Jan 2016 05:19:21 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0

On 01/21/2016 08:07 PM, Eli Zaretskii wrote:

I think having the *xref* buffer visible is _the_ reason we could get
rid of tags-loop-continue.

Here's where I'm currently stumped:

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.

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.

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

Compilation has no such contract, so there's nothing corresponding in there that I could borrow.

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

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. But maybe it's what we should do anyway until someone implements the second option (the previous paragraph).

No, I think all the matches that the user saw already, whether she
accepted the replacement or not, should be marked in some way, so that
continuing the replacement goes to the first unseen one.

Good, that should be easier to do.

reply via email to

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