bug#49731: 28.0.50; Filter xref results by filename

[Juri Linkov <juri@linkov.net>]

>> 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.

Then in your comparison with grep, this is similar to grep options
'grep-find-ignored-directories' and 'grep-find-ignored-files'.

>> 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.

Earlier you compared this to flush-lines/keep-lines, and these commands
are cumulative.  But maybe xref filtering doesn't need to be cumulative
when it will support specifying a regexp with alternatives '\|'.

> I've bound the new command to "f".  For simplicity, each time you press
> "f" you'll filter the entire list (filters are not cumulative).  As you
> said, pressing "p" and "n" navigate results that are folded, which is
> confusing.  Perhaps a new minor mode in xref could do the outline
> folding and also make sure that "p" and "n" skip results that are
> folded.

Thanks, I'll test your command for a while.