[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#49731: 28.0.50; Filter xref results by filename

From: Dmitry Gutov
Subject: bug#49731: 28.0.50; Filter xref results by filename
Date: Tue, 27 Jul 2021 02:28:58 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]