GNU bug report logs -
#49731
28.0.50; Filter xref results by filename
Previous Next
Reported by: Daniel Martín <mardani29 <at> yahoo.es>
Date: Sun, 25 Jul 2021 08:21:02 UTC
Severity: normal
Found in version 28.0.50
Fixed in version 30.0.50
Done: Juri Linkov <juri <at> linkov.net>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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.
This bug report was last modified 1 year and 49 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.