bug#49731: 28.0.50; Filter xref results by filename

[Dmitry Gutov]

On 27.07.2021 20:08, Daniel Martín wrote:

> > 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.
>
> I think that kind of search scoping in advance can be specially useful
> when you are doing a grep-like search in the codebase, using either
> grep, rgrep, project-find-regexp, or xref-find-apropos.
>
> I see it less useful for example when you place the point in an
> identifier and press M-?.  You'll want to see all the references first,
> and then filter afterwards if they are too many.  But I think it's a
> matter of personal preferences and different workflows.

Agree on both counts. Except for xref-find-apropos: it usually works 
more similarly to xref-find-references.

Ultimately we should get both options.

> > 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.
>
> Yes, that's the direction that interests me the most, if it's actually a
> worthy feature for Emacs users.

I'm fairly certain there is a demand for this kind of functionality.

> > 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.
>
> I didn't have in mind implementing cumulative filters.  I don't know if
> people would need such advanced filtering of results.  FTR, I've
> researched how other tools and IDEs implement this feature, which is
> less common than what I initially thought:

I'm fine without that feature, or at least with it not being present in 
the first version (someone else could add it later, maybe as a separate 
command).

But if the filter is being replaced rather than added to, it's better we 
make that obvious. For instance, by putting the previous filter as 
initial input when the user invoked the filtering command a second time.

> <...>
>
> - Chromium Code Search: It offers a box to filter by file path.  It also
>    offers an option to exclude tests and generated files.

The ability to exclude or include certain categories of files (like 
generated ones and ones listed in .gitignore) seems to belong to the 
option 1 -- better executed when we have more information about the 
current project, which when the Xref buffer is rendered is mostly lost.

> > 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.
>
> Here's a first quick and dirty prototype based on Juri's code snippet:

It works, which is a good thing. Though it overrides the existing 'q' 
bindings (now you can't quit the Xref buffer).

But do we want it to be implemented using outline-mode? Because we want 
the corresponding visuals? Because otherwise a dedicated implementation 
shouldn't take much more code either (probably roughly the size of 
xref-truncation-width feature we added recently).

Speaking of 'f' and 'q', do we have a precedent for this kind of 
interaction somewhere else in Emacs? I'm not against those per se, but 
I'd really rather we try to follow one of the existing workflows, so 
that the users wouldn't have to remember yet one more thing. Hence the 
idea from package.el.

Or yet another approach: tack the ability to cancel the filter on top of 
a search history feature (accessed with C-c C-b/C-c C-f, like in Help 
buffers). But we'd actually need to implement that feature first.