|
From: | Dmitry Gutov |
Subject: | xref display and multiple locations, was: Re: Unified project interface |
Date: | Thu, 30 Jul 2015 02:11:25 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 |
On 07/29/2015 05:27 AM, Stephen Leake wrote:
Currently, 'grep-find' and 'compilation' share the same location API. Which is why I suggested that xref also share it. But I do like the current xref location display, so maybe there is a case for them to remain distinct. They serve different purposes; the xref display makes it easy to choose one location from a small list; the compilation display makes it easier to step through all of them in sequence, and it works even for very long lists.
I've come to believe that it's a mistake. The only xref command where we're likely to only be only in one location is xref-find-definitions, and in ideal implementations, it's likely not to show the xref buffer at all, jumping straight to the sole result.
So in the average case, pressing RET, or clicking on an xref element, should display the location, but keep the xref buffer displayed as well. We just need a way to use the current behavior in xref-find-definitions (or implement a yet-another selection interface for it).
There should at least there should be this choice of display; the location data structure could probably be shared (the compilation location structure contains more info).
The current customization point is xref-show-xrefs-function. There are no different implementations yet.
One nice feature of M-x grep, by the way, is that it shows the matches immediately as it finds them (whereas the current xref commands are forced to wait until the output ends, and collect the whole list).
One way to reach parity there would be to teach xref to accept generators (as implemented in generator.el), as well as regular lists.
(grep-find could eventually be made obsolete in favor of project-find-regexp).
Here's hoping.
[Prev in Thread] | Current Thread | [Next in Thread] |