xref "find references" and grouping

[Dmitry Gutov <dgutov@yandex.ru>]

On 05/02/2015 09:59 AM, Stefan Monnier wrote:

> I don't see much need for nesting.  I think the issue is mostly one of
> sorting in *xref* (or in the cycling, if we were to use a hypothetical
> other UI that provides functionality like the old etags.el).

Take a look at M-x semantic-symref output, and compare to what we have 
with M-x xref-find-references. Here's a screenshot of the former:

http://cedet.sourceforge.net/img-gen/symref.png

Note the grouping by the "current function", as well as by file name. It 
seems to me that it can be pretty valuable.

Here's how a similar interface looks in a popular proprietary IDE: 
https://www.jetbrains.com/img/webhelp/idea/findUsageField.png

Helmut, any suggestions? Does SLIME have anything related?

> So, let's focus on this.
> My suggestion would be either:
> - make xref-find-function return not just a list of locations, but also
>    an indication whether they're pre-sorted or not.
> - make xref-find-function return not a list of locations, but a list of
>    lists of locations (i.e. every location inside a sub-list is
>    considered to have the same "level/quality/likelihood", but the lists
>    are sorted by their "level/quality/likelihood").
> - let the backend provide its own sorting function to override the
>    current "group by file" sorting.

The question of sorting would need resolving indeed.

> Basically, I think the focus should be on making sure that we can
> re-implement the old behavior on top of the new API when using the
> xref/etags backend.

We also can't group xref-find-apropos matches by likelihood, I think. Or 
would you include file path on each line? That seems wasteful.