bug#49731: 28.0.50; Filter xref results by filename

[Dmitry Gutov <dgutov@yandex.ru>]

Hi Daniel,

On 25.07.2021 11:19, Daniel Martín via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> 
> I plan to implement a new feature for xref, but I'd like to get some
> opinions first:
> 
> Sometimes an xref backend returns a lot of results spread over several
> files.  This usually happens in huge projects and for certain operations
> like "search references".  To make them more manageable, I propose a new
> command that can filter xref result groups (typically filenames) by a
> regular expression.  A user could filter by "tests/", or something like
> that, to only get results from unit tests.  If you want to see a similar
> feature in action, go to
> https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/background/background_contents.cc;bpv=1;bpt=1
> and type on "Type to filter by file path", under the "References" tab.

This is going to be quite welcome.

> Right now the only approach I know for this use case is to use Isearch,
> but Isearch searches the entire xref buffer, including xref matches.
> 
> What do you think about this new feature? Do you have any suggestions
> about how it should work?

We've discussed this sort of functionality before. Here are some 
approaches (not mutually exclusive):

1. Add the possibility to add filtering by file names, types, etc, 
before the search is done. This should fit 'project-find-regexp' well. I 
can point you to a previous discussion with some ideas. The main upside 
is you can speed up the search. And store such settings as a history.

2. Filter in the resulting Xref buffer. The best part is it can work 
with the output from any command that uses Xref. The "filtering" is 
temporary. I'm assuming this is the direction you want to work in.

3. Do some sort of "editable Xref buffer" feature where you can kill the 
lines you don't want to see/use, with an undo history. This would 
probably fit better together with another requested feature (wdired-like 
editing).

I've never exactly considered the option 2., but I'd be happy to talk 
the details. WRT UI, maybe something along the lines of 
package-menu-filter-* commands, bound inside a '/' prefix. One command 
could add "inclusion filter", another - "exclusion filter", and the 
third one - reset all filters. '/ /' be bound to the last one.

The 'q' binding sounds iffy to be in that regard.

Another thing to keep an eye out for - is how the filtering will affect 
n/p navigation and the xref-query-replace-in-results command. I think 
they should respect the filtering as well.