Re: Xref completion

[Daniel Martín]

Dmitry Gutov <dgutov@yandex.ru> writes:
>
> On the one hand, it feels kinda faster, on the other, it lacks the
> ability to "look around" when you really need it. In an ideal world, I 
> guess the UI would be somewhere in the middle.

One of the reasons I see people integrate Ivy/Helm with Xref is to have
fuzzy filtering of the results, but I don't see why we couldn't have
that in the *xref* buffer.

First I thought if we could implement this by extending an existing
Emacs command like flush-lines or occur to "teach" it about the
specificities of the *xref* buffer, but that doesn't seem very clean.

So perhaps we could add a new command that asks for a regexp in the
minibuffer and filters the results in the *xref* buffer to only contain
those items from a group that matches that regular expression.  With q
you will go back to show the complete list of xref items and groups.  Is
there any core Emacs package that performs a similar filtering?  We
could learn from its workflow, then.

Why matching the group exclusively? In my opinion, matching the group
only is better because the typical use case I have in mind is a big
codebase with thousands of xref results that are spread around hundreds
of files.  You usually want to filter by the string that varies the
most, which in most cases is the group (eg. if I only want to see
results from unit tests, then I'd filter the *xref* buffer by
"*Tests.cpp"; If I only want to see results from header files, I'd
filter by "*.h").

Thoughts?