bug#49731: 28.0.50; Filter xref results by filename

bug#49731: 28.0.50; Filter xref results by filename

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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.

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?

bug#49731: 28.0.50; Filter xref results by filename

[Lars Ingebrigtsen]

Daniel Martín <mardani29@yahoo.es> writes:

> What do you think about this new feature? Do you have any suggestions
> about how it should work?

This was recently discussed in bug#2544...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49731: 28.0.50; Filter xref results by filename

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Daniel Martín <mardani29@yahoo.es> writes:
>
>> What do you think about this new feature? Do you have any suggestions
>> about how it should work?
>
> This was recently discussed in bug#2544...

(Well, as sorting instead of filtering, so it's not quite the same.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49731: 28.0.50; Filter xref results by filename

[Eli Zaretskii]

> Date: Sun, 25 Jul 2021 10:19:52 +0200
> From:  Daniel Martín via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> 
> 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.

I cannot see anything useful at that URL for some reason, so couldn't
get a clear idea of what would be the result of the proposed feature.
Can you describe it in more detail?

In particular, does "filtering by file names" mean you'd leave only
some of the matches in the XREF buffer, or does it mean something
else?

More generally, I wonder what are the purposes of this feature.
Filtering is a means, but what are the ends here?  Can you describe a
couple of use cases that would provide the context for the feature and
its projected uses?

Thanks.

bug#49731: 28.0.50; Filter xref results by filename

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>
> I cannot see anything useful at that URL for some reason, so couldn't
> get a clear idea of what would be the result of the proposed feature.
> Can you describe it in more detail?

For example, go to
https://source.chromium.org/chromium/chromium/src/+/main:net/http/http_version.h;l=13;bpv=1;bpt=1
and click on "HttpVersion".  That'll open a lower pane with references
to the HttpVersion type in the Chromium codebase.  Imagine that you are
only interested in references from third party (vendor) libraries.  You
can click on "Type to filter by file path", type "third_party" in the
search box and you'll only see references from files that are in the
"third_party" directory, or one of its subdirectories.

Another use case is that you only want to see references to a symbol
from unit tests.  You can type "unittest" to filter the results
accordingly.  Or, if you only want to see references from header files,
you could type "\.h$".

>
> In particular, does "filtering by file names" mean you'd leave only
> some of the matches in the XREF buffer, or does it mean something
> else?

Yes, it means two things (although how the feature would work can be
discussed further):

- Only xref groups (and their items) whose title matches the regular
  expression will be preserved in the buffer.

- The part of the title that matches the regexp could be highlighted
  using a face derived from the "highlight" face, for example.

Of course, we need to make it clear that the xref buffer is being
filtered, and provide a way to return to the full list of results
(pressing "q", maybe?).

bug#49731: 28.0.50; Filter xref results by filename

[Juri Linkov]

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

I have exactly the same problem while using xref on the Emacs source tree:
most of the time I'm not interested in the results found in ChangeLog files,
so I want to ignore all ChangeLog files, and only ChangeLog files.

This problem was solved by enabling outline-minor-mode on the xref output,
then collapsing all ChangeLog entries automatically:

#+begin_src emacs-lisp
(add-hook 'xref-after-update-hook
          (lambda ()
            (setq-local outline-regexp
              (if (eq xref-file-name-display 'abs) "/" "[^ 0-9]"))
            (outline-minor-mode +1)
            (save-excursion
              (goto-char (point-min))
              (while (search-forward "ChangeLog" nil t)
                (outline-cycle)))))
#+end_src

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

You can use isearch-filter-predicate to match only on file names.
There is an example of this feature in dired-isearch-filenames-mode.

bug#49731: 28.0.50; Filter xref results by filename

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Juri Linkov <juri@linkov.net> writes:

>
> I have exactly the same problem while using xref on the Emacs source tree:
> most of the time I'm not interested in the results found in ChangeLog files,
> so I want to ignore all ChangeLog files, and only ChangeLog files.
>
> This problem was solved by enabling outline-minor-mode on the xref output,
> then collapsing all ChangeLog entries automatically:
>
> #+begin_src emacs-lisp
> (add-hook 'xref-after-update-hook
>           (lambda ()
>             (setq-local outline-regexp
>               (if (eq xref-file-name-display 'abs) "/" "[^ 0-9]"))
>             (outline-minor-mode +1)
>             (save-excursion
>               (goto-char (point-min))
>               (while (search-forward "ChangeLog" nil t)
>                 (outline-cycle)))))
> #+end_src

This is similar to what I have in mind.  Instead of hardcoding
"ChangeLog", the proposed command would ask the user for the regular
expression.  Your command hides entries that match the pattern, but I
think that for the new command the opposite interpretation is more
common (only show those entries that match the pattern, and hide
everything else).  Does it make sense to offer both behaviors? (Like
flush-lines/keep-lines.)

Another xref-mode-map command bound to "q", for example, would disable
outline-minor-mode to present the xref buffer with full visibility.

bug#49731: 28.0.50; Filter xref results by filename

[Juri Linkov]

>> (add-hook 'xref-after-update-hook
>>           (lambda ()
>>             (setq-local outline-regexp
>>               (if (eq xref-file-name-display 'abs) "/" "[^ 0-9]"))
>>             (outline-minor-mode +1)
>>             (save-excursion
>>               (goto-char (point-min))
>>               (while (search-forward "ChangeLog" nil t)
>>                 (outline-cycle)))))
>
> This is similar to what I have in mind.  Instead of hardcoding
> "ChangeLog", the proposed command would ask the user for the regular
> expression.  Your command hides entries that match the pattern, but I
> think that for the new command the opposite interpretation is more
> common (only show those entries that match the pattern, and hide
> everything else).  Does it make sense to offer both behaviors? (Like
> flush-lines/keep-lines.)

Indeed, both include/exclude make sense.  In your example
of using "tests/" to get results only from unit tests,
actually in most projects I need exactly the inverse:
to ignore all results from unit tests, because when I need
to get results only from "tests/", then it's easy to run
'C-x p g' (project-find-regexp) with the prefix C-u
and specify the directory to search such as "tests/".

> Another xref-mode-map command bound to "q", for example, would disable
> outline-minor-mode to present the xref buffer with full visibility.

There is 'outline-cycle-buffer' bound to 'S-TAB' that can
enable full visibility, or just 'outline-show-all'.

bug#49731: 28.0.50; Filter xref results by filename

[Dmitry Gutov]

On 25.07.2021 11:33, Lars Ingebrigtsen wrote:
> (Well, as sorting instead of filtering, so it's not quite the same.)

And it's etags-specific.

bug#49731: 28.0.50; Filter xref results by filename

[Dmitry Gutov]

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.

bug#49731: 28.0.50; Filter xref results by filename

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Dmitry Gutov <dgutov@yandex.ru> writes:

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

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.

>
> 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'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:

- Xcode: In the references panel there is a filter box on the bottom so
  that you type and filter the results to keep those that match the
  pattern.

- IntelliJ IDEA: I haven't seen a similar functionality.  There is a
  button to remove references from automatically generated code, but
  that's all.

- Sourcegraph: It doesn't seem to offer a similar functionality.

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

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

diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el
index e2cd904a6c..27ff08f7ce 100644
--- a/lisp/progmodes/xref.el
+++ b/lisp/progmodes/xref.el
@@ -665,6 +665,36 @@ xref-goto-xref
       ;; Emacs < 27
       (setq next-error-last-buffer buffer))))
 
+(declare-function outline-show-entry "outline" ())
+(declare-function outline-hide-body "outline" ())
+
+(defun xref-filter-results-by-file (pattern)
+  "Filter xref results to only include those in files that match PATTERN."
+  (interactive (list (read-string
+                      "Filter results in files that match pattern (regexp): "
+                      nil nil)))
+  (require 'outline)
+  (setq-local outline-regexp
+              (if (eq xref-file-name-display 'abs) "/" "[^ 0-9]"))
+  (outline-minor-mode +1)
+  (outline-hide-body)
+  (save-excursion
+    (goto-char (point-min))
+    (let ((count 0))
+      (while (progn
+             (when (re-search-forward pattern (line-end-position) t)
+               (outline-show-entry)
+               (setq count (1+ count)))
+             (xref--search-property 'xref-group)))
+      (when (zerop count)
+        (message "No match")
+        (xref-exit-results-filter)))))
+
+(defun xref-exit-results-filter ()
+  "Remove any xref filter and show the full list of results."
+  (interactive)
+  (outline-minor-mode -1))
+
 (defun xref-quit-and-goto-xref ()
   "Quit *xref* buffer, then jump to xref on current line."
   (interactive)
@@ -824,6 +854,8 @@ xref--xref-buffer-mode-map
     (define-key map (kbd ",") #'xref-prev-line)
     (define-key map (kbd "g") #'xref-revert-buffer)
     (define-key map (kbd "M-,") #'xref-quit-and-pop-marker-stack)
+    (define-key map (kbd "f") #'xref-filter-results-by-file)
+    (define-key map (kbd "q") #'xref-exit-results-filter)
     map))
 
 (define-derived-mode xref--xref-buffer-mode special-mode "XREF"

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.

bug#49731: 28.0.50; Filter xref results by filename

[Juri Linkov]

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

bug#49731: 28.0.50; Filter xref results by filename

[Dmitry Gutov]

On 27.07.2021 23:51, Juri Linkov wrote:

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

Except in reverse (inclusion, not exclusion) and tweakable at runtime 
rather that through Customize.

>> 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 think ultimately it depends on the mental model the UI produces. In 
the examples we've seen in other programs, you usually modify an input 
field containing the previous search terms, so that makes it obvious the 
existing filter would be replaced, rather than added to.

If the new prompt did that as well, it could work similarly.

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.

bug#49731: 28.0.50; Filter xref results by filename

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 925 bytes --]

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

Thanks for mentioning xref-find-references and xref-find-apropos.
I tried them out, but they are broken:

1. while xref-find-references works fine in `emacs -Q`,
I don't know why with my customization typing e.g.
'M-? isearch-lazy-highlight RET' reports
"No references found for: isearch-lazy-highlight".

2. xref-find-apropos doesn't offer the identifier at point as its
default, and after using it e.g. from the buffer isearch.el with
'C-M-. isearch-lazy-highlight RET' all its lines are concatenated
on the same line in `emacs -Q`:


[-- Attachment #2: xref-find-apropos.png --]
[-- Type: image/png, Size: 18419 bytes --]

[-- Attachment #3: Type: text/plain, Size: 455 bytes --]


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

I see no reason to be different from package-menu-filter where
'/ /' resets all filters.  Then maybe add '/ i' to include, and
'/ e' to exclude.

bug#49731: 28.0.50; Filter xref results by filename

[Dmitry Gutov]

On 28.07.2021 19:12, Juri Linkov wrote:

> Thanks for mentioning xref-find-references and xref-find-apropos.
> I tried them out, but they are broken:
> 
> 1. while xref-find-references works fine in `emacs -Q`,
> I don't know why with my customization typing e.g.
> 'M-? isearch-lazy-highlight RET' reports
> "No references found for: isearch-lazy-highlight".

Try and see which of the "tools" semantic-symref-perform-search ends up 
using.

If you have an index generated by Global, idutils or CScope, it could be 
missing this symbol and have the search fail because of that.

Otherwise the search falls back to Grep, see 
lisp/cedet/semantic/symref/grep.el. You can edebug it there.

> 2. xref-find-apropos doesn't offer the identifier at point as its
> default, and after using it e.g. from the buffer isearch.el with
> 'C-M-. isearch-lazy-highlight RET' all its lines are concatenated
> on the same line in `emacs -Q`:

Thanks for the report, should be fixed now.

bug#49731: 28.0.50; Filter xref results by filename

[Juri Linkov]

>> 1. while xref-find-references works fine in `emacs -Q`,
>> I don't know why with my customization typing e.g.
>> 'M-? isearch-lazy-highlight RET' reports
>> "No references found for: isearch-lazy-highlight".
>
> Try and see which of the "tools" semantic-symref-perform-search ends
> up using.

Thanks for the pointers to semantic-symref-perform-search.
It prepends "-n " to my customized pattern "rg -nH",
so the arg "-n" is duplicated on the command line:

  `rg -n -nH`

and signals the error:

  error: The argument '--line-number' was provided more than once, but cannot be used multiple times

This error is caused by the bug in the command line parser used by ripgrep:

  https://github.com/clap-rs/clap/issues/2171

that was fixed only 6 months ago, so it will take much time
before this fix will reach ripgrep, and this bug will be closed:

  https://github.com/BurntSushi/ripgrep/issues/1701

But even without duplicated "-n" semantic-symref-perform-search
doesn't work with ripgrep because it doesn't find such pattern:

  \\\\\\(\\^\\\\\\|\\\\W\\\\\\)isearch-lazy-highlight\\\\\\(\\\\W\\\\\\|\\$\\\\\\)

Maybe semantic-symref-perform-search could be improved to support ripgrep?
Because without these two problems it works fine with ripgrep.

>> 2. xref-find-apropos doesn't offer the identifier at point as its
>> default, and after using it e.g. from the buffer isearch.el with
>> 'C-M-. isearch-lazy-highlight RET' all its lines are concatenated
>> on the same line in `emacs -Q`:
>
> Thanks for the report, should be fixed now.

I confirm it's fixed, thanks.  I suppose xref-find-apropos doesn't offer
the identifier at point as its default because 'apropos' doesn't offer
the default?  But this is not a big problem.

bug#49731: 28.0.50; Filter xref results by filename

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Dmitry Gutov <dgutov@yandex.ru> writes:

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

Yes, I think implementing the feature using outline-mode is not a good
idea.  It'll load a library that is not small, and more importantly, it
is confusing from a UI point of view: It's strange that the xref output,
which is initally non-foldable, becomes foldable when you want to filter
the output (one may think that why the output can't just be foldable by
default).

I'd like to take a spin at option 1). How do you think the filtering
should happen? At the xref backend level, or at the xref frontend level?
I think the filtering can happen in the frontend, provided that the
backend provides the necessary information (file path, and symbol type,
if we offer to filter by symbol type).

Is there any thread where this feature was discussed? Thanks.

bug#49731: 28.0.50; Filter xref results by filename

[Eli Zaretskii]

> Cc: 49731@debbugs.gnu.org
> Date: Sat, 31 Jul 2021 18:45:35 +0200
> From:  Daniel Martín via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
> >
> > 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).
> >
> 
> Yes, I think implementing the feature using outline-mode is not a good
> idea.

How about using selective-display?

bug#49731: 28.0.50; Filter xref results by filename

[Dmitry Gutov]

On 29.07.2021 20:43, Juri Linkov wrote:
>>> 1. while xref-find-references works fine in `emacs -Q`,
>>> I don't know why with my customization typing e.g.
>>> 'M-? isearch-lazy-highlight RET' reports
>>> "No references found for: isearch-lazy-highlight".
>>
>> Try and see which of the "tools" semantic-symref-perform-search ends
>> up using.
> 
> Thanks for the pointers to semantic-symref-perform-search.
> It prepends "-n " to my customized pattern "rg -nH",
> so the arg "-n" is duplicated on the command line:
> 
>    `rg -n -nH`
> 
> and signals the error:
> 
>    error: The argument '--line-number' was provided more than once, but cannot be used multiple times
> 
> This error is caused by the bug in the command line parser used by ripgrep:
> 
>    https://github.com/clap-rs/clap/issues/2171
> 
> that was fixed only 6 months ago, so it will take much time
> before this fix will reach ripgrep, and this bug will be closed:
> 
>    https://github.com/BurntSushi/ripgrep/issues/1701

The above might be worked around with creating a symref-grep specific 
user option for grep-find-template which would default to the "global" 
value of that variable.

> But even without duplicated "-n" semantic-symref-perform-search
> doesn't work with ripgrep because it doesn't find such pattern:
> 
>    \\\\\\(\\^\\\\\\|\\\\W\\\\\\)isearch-lazy-highlight\\\\\\(\\\\W\\\\\\|\\$\\\\\\)
> 
> Maybe semantic-symref-perform-search could be improved to support ripgrep?
> Because without these two problems it works fine with ripgrep.

...but the above tells us (I think) that semantic-symref-perform-search 
is trying to use the basic regexp syntax, and ripgrep doesn't support 
that (only Extended, or PCRE).

For your personal consumption, perhaps the best approach is to create a 
separate "tool", like Grep (by copying symref/grep.el and tweaking some 
of its definitions), and then register it in semantic-symref-tool-alist.

I don't know if ripgrep is that much faster for this particular purpose. 
So maybe it's too much work for little benefit.

>>> 2. xref-find-apropos doesn't offer the identifier at point as its
>>> default, and after using it e.g. from the buffer isearch.el with
>>> 'C-M-. isearch-lazy-highlight RET' all its lines are concatenated
>>> on the same line in `emacs -Q`:
>>
>> Thanks for the report, should be fixed now.
> 
> I confirm it's fixed, thanks.  I suppose xref-find-apropos doesn't offer
> the identifier at point as its default because 'apropos' doesn't offer
> the default?  But this is not a big problem.

Maybe because of that, or because one usually searches for a word or 
several (right?), rather than some identifier name.

Providing a default wouldn't break anything, though. Perhaps some people 
will find it easier to extract the key words they wanted from the symbol 
name at point. Try this patch:

diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el
index b7a926f82e..4b73f3715a 100644
--- a/lisp/progmodes/xref.el
+++ b/lisp/progmodes/xref.el
@@ -1353,7 +1353,9 @@ xref-find-apropos
  The argument has the same meaning as in `apropos'."
    (interactive (list (read-string
                        "Search for pattern (word list or regexp): "
-                      nil 'xref--read-pattern-history)))
+                      nil 'xref--read-pattern-history
+                      (xref-backend-identifier-at-point
+                       (xref-find-backend)))))
    (require 'apropos)
    (let* ((newpat
            (if (and (version< emacs-version "28.0.50")

bug#49731: 28.0.50; Filter xref results by filename

[Juri Linkov]

>> I suppose xref-find-apropos doesn't offer
>> the identifier at point as its default because 'apropos' doesn't offer
>> the default?  But this is not a big problem.
>
> Maybe because of that, or because one usually searches for a word or
> several (right?), rather than some identifier name.
>
> Providing a default wouldn't break anything, though. Perhaps some people
> will find it easier to extract the key words they wanted from the symbol
> name at point.

Indeed, such as removing the suffix and leaving a common prefix
to search all functions under the same package namespace, etc.

> Try this patch:

Thanks, this makes it more useful.

bug#49731: 28.0.50; Filter xref results by filename

[Dmitry Gutov]

On 02.08.2021 23:58, Juri Linkov wrote:
>> Try this patch:
> Thanks, this makes it more useful.

Now installed, thanks for the suggestion.

bug#49731: 28.0.50; Filter xref results by filename

[Juri Linkov]

>> #+begin_src emacs-lisp
>> (add-hook 'xref-after-update-hook
>>           (lambda ()
>>             (setq-local outline-regexp
>>               (if (eq xref-file-name-display 'abs) "/" "[^ 0-9]"))
>>             (outline-minor-mode +1)
>>             (save-excursion
>>               (goto-char (point-min))
>>               (while (search-forward "ChangeLog" nil t)
>>                 (outline-cycle)))))
>> #+end_src
>
> This is similar to what I have in mind.  Instead of hardcoding
> "ChangeLog", the proposed command would ask the user for the regular
> expression.  Your command hides entries that match the pattern, but I
> think that for the new command the opposite interpretation is more
> common (only show those entries that match the pattern, and hide
> everything else).  Does it make sense to offer both behaviors? (Like
> flush-lines/keep-lines.)

Now a new feature was implemented in bug#51809 that allows
easy customization of the new options outline-default-state
and outline-default-rules, for example:

#+begin_src emacs-lisp
(add-hook 'xref-after-update-hook
          (lambda ()
            (setq-local outline-regexp
                        (if (eq xref-file-name-display 'abs) "/" "[^ 0-9]")
                        outline-default-state 1
                        outline-default-rules '((match-regexp . "ChangeLog")))
            (outline-minor-mode +1)))
#+end_src

bug#49731: 28.0.50; Filter xref results by filename

[Juri Linkov]

>> This is similar to what I have in mind.  Instead of hardcoding
>> "ChangeLog", the proposed command would ask the user for the regular
>> expression.  Your command hides entries that match the pattern, but I
>> think that for the new command the opposite interpretation is more
>> common (only show those entries that match the pattern, and hide
>> everything else).  Does it make sense to offer both behaviors? (Like
>> flush-lines/keep-lines.)
>
> Now a new feature was implemented in bug#51809 that allows
> easy customization of the new options outline-default-state
> and outline-default-rules, for example:
>
> #+begin_src emacs-lisp
> (add-hook 'xref-after-update-hook
>           (lambda ()
>             (setq-local outline-regexp
>                         (if (eq xref-file-name-display 'abs) "/" "[^ 0-9]")

And now a new feature implemented in bug#53981 allows to replace
the unreliable line above with using outline-search-function:

```
diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el
index 89a090ae932..1ef2ea74e26 100644
--- a/lisp/progmodes/xref.el
+++ b/lisp/progmodes/xref.el
@@ -927,7 +911,12 @@ xref--xref-buffer-mode
   (setq imenu-prev-index-position-function
         #'xref--imenu-prev-index-position)
   (setq imenu-extract-index-name-function
-        #'xref--imenu-extract-index-name))
+        #'xref--imenu-extract-index-name)
+  (setq-local outline-search-function
+              (lambda (&optional bound move backward looking-at)
+                (outline-search-text-property
+                 'xref-group nil bound move backward looking-at))
+              outline-level (lambda () 1)))
 
 (defvar xref--transient-buffer-mode-map
   (let ((map (make-sparse-keymap)))
```

bug#49731: 28.0.50; Filter xref results by filename

[Juri Linkov]

> And now a new feature implemented in bug#53981 allows to replace
> the unreliable line above with using outline-search-function:

Now pushed to master in the commit 3573ebfa6d (it seems this is
backward-compatible since it only sets buffer-local variables).

bug#49731: 28.0.50; Filter xref results by filename

[Dmitry Gutov]

On 23/11/22 10:39, Juri Linkov wrote:
>> And now a new feature implemented in bug#53981 allows to replace
>> the unreliable line above with using outline-search-function:
> Now pushed to master in the commit 3573ebfa6d (it seems this is
> backward-compatible since it only sets buffer-local variables).

Nice.

Do you plan on adding an outline-[minor-]mode command to hide/show by 
regexp?

bug#49731: 28.0.50; Filter xref results by filename

[Juri Linkov]

>>> And now a new feature implemented in bug#53981 allows to replace
>>> the unreliable line above with using outline-search-function:
>> Now pushed to master in the commit 3573ebfa6d (it seems this is
>> backward-compatible since it only sets buffer-local variables).
>
> Nice.
>
> Do you plan on adding an outline-[minor-]mode command to hide/show by
> regexp?

Do you mean enabling outline-minor-mode in the xref buffer?
Currently to enable it, the users need to add to the init file:

  (add-hook 'xref-after-update-hook 'outline-minor-mode)

that is not too self-evident.  Maybe a new option could help?

bug#49731: 28.0.50; Filter xref results by filename

[Dmitry Gutov]

On 23/11/22 19:50, Juri Linkov wrote:
>>>> And now a new feature implemented in bug#53981 allows to replace
>>>> the unreliable line above with using outline-search-function:
>>> Now pushed to master in the commit 3573ebfa6d (it seems this is
>>> backward-compatible since it only sets buffer-local variables).
>> Nice.
>>
>> Do you plan on adding an outline-[minor-]mode command to hide/show by
>> regexp?
> Do you mean enabling outline-minor-mode in the xref buffer?
> Currently to enable it, the users need to add to the init file:
> 
>    (add-hook 'xref-after-update-hook 'outline-minor-mode)
> 
> that is not too self-evident.  Maybe a new option could help?

No, I mean suppose I have enabled outline-minor-mode manually.

How do I filter the groups by name/regexp?

bug#49731: 28.0.50; Filter xref results by filename

[Juri Linkov]

>>> Do you plan on adding an outline-[minor-]mode command to hide/show by
>>> regexp?
>> Do you mean enabling outline-minor-mode in the xref buffer?
>> Currently to enable it, the users need to add to the init file:
>>    (add-hook 'xref-after-update-hook 'outline-minor-mode)
>> that is not too self-evident.  Maybe a new option could help?
>
> No, I mean suppose I have enabled outline-minor-mode manually.
>
> How do I filter the groups by name/regexp?

Ah, now I see.  This is easy as well, for example,
this is what I use for the Emacs source repo:

#+begin_src emacs-lisp
(add-hook 'xref-after-update-hook
          (lambda ()
            (setq-local outline-default-state 1
                        outline-default-rules
                        '((match-regexp . "ChangeLog\\|test/manual/etags")))
            (outline-minor-mode +1)))
#+end_src

where "ChangeLog" and "test/manual/etags" are not interesting groups.

bug#49731: 28.0.50; Filter xref results by filename

[Dmitry Gutov]

On 23/11/22 20:20, Juri Linkov wrote:
> Ah, now I see.  This is easy as well, for example,
> this is what I use for the Emacs source repo:
> 
> #+begin_src emacs-lisp
> (add-hook 'xref-after-update-hook
>            (lambda ()
>              (setq-local outline-default-state 1
>                          outline-default-rules
>                          '((match-regexp . "ChangeLog\\|test/manual/etags")))
>              (outline-minor-mode +1)))
> #+end_src
> 
> where "ChangeLog" and "test/manual/etags" are not interesting groups.

Makes sense.

But IME the files you currently want to filter out depend on your 
current activity: sometimes you want to show the tests, and sometimes 
not. Sometimes you want to see the tests only.

So it might be generally useful to have an interactive command to filter 
out whatever one might prefer. If you agree, of course.

bug#49731: 28.0.50; Filter xref results by filename

[Dmitry Gutov]

On 27/7/21 20:08, Daniel Martín via Bug reports for GNU Emacs, the Swiss 
army knife of text editors wrote:
> and also make sure that "p" and "n" skip results that are
> folded

This is now fixed on master, commit c38f3b1ce1.

bug#49731: 28.0.50; Filter xref results by filename

[Juri Linkov]

>> (add-hook 'xref-after-update-hook
>>            (lambda ()
>>              (setq-local outline-default-state 1
>>                          outline-default-rules
>>                          '((match-regexp . "ChangeLog\\|test/manual/etags")))
>>              (outline-minor-mode +1)))
>> where "ChangeLog" and "test/manual/etags" are not interesting groups.
>
> Makes sense.
>
> But IME the files you currently want to filter out depend on your current
> activity: sometimes you want to show the tests, and sometimes
> not. Sometimes you want to see the tests only.
>
> So it might be generally useful to have an interactive command to filter
> out whatever one might prefer. If you agree, of course.

This would be a nice addition to outline.el.  For example, new commands
outline-hide-by-regexp and outline-show-by-regexp that could use
existing code extracted from outline--show-headings-up-to-level:

  (outline-map-region
   (lambda ()
     (when (let ((beg (point))
                 (end (progn (outline-end-of-heading) (point))))
             (string-match-p heading-regexp (buffer-substring beg end)))
       ;; hide entry when heading match regexp
       (outline-hide-entry))))

bug#49731: 28.0.50; Filter xref results by filename

[Kévin Le Gouguec]

Juri Linkov <juri@linkov.net> writes:

>> So it might be generally useful to have an interactive command to filter
>> out whatever one might prefer. If you agree, of course.
>
> This would be a nice addition to outline.el.  For example, new commands
> outline-hide-by-regexp and outline-show-by-regexp that could use
> existing code extracted from outline--show-headings-up-to-level:
>
>   (outline-map-region
>    (lambda ()
>      (when (let ((beg (point))
>                  (end (progn (outline-end-of-heading) (point))))
>              (string-match-p heading-regexp (buffer-substring beg end)))
>        ;; hide entry when heading match regexp
>        (outline-hide-entry))))

(Hi 👋  Nothing much to add, just thought I'd express my wholehearted
agreement about this being a useful addition to outline.el; I've missed
Org's "sparse tree" feature in other outline contexts, and I look
forward to using it in more than just xref buffers, e.g. Diff or
prog-mode.

(info "(org) Sparse Trees")

C-x p f ORG-NEWS TAB RET
C-c / / export RET

Not saying that outline-show-by-regexp should be a 1:1 reimplementation,
e.g. highlighting matches or searching section bodies might not be
essential; still, thought it'd be worth mentioning this bit of "prior
art")

bug#49731: 28.0.50; Filter xref results by filename

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]

>> Now pushed to master in the commit 3573ebfa6d (it seems this is
>> backward-compatible since it only sets buffer-local variables).
>
> Nice.
>
> Do you plan on adding an outline-[minor-]mode command to hide/show by
> regexp?

So now here are these two commands:

  / s   outline-show-by-heading-regexp
  / h   outline-hide-by-heading-regexp

Also there is an additional helper function that is needed
to keep hidden outlines and restore them after reverting the
xref buffer with 'g' (xref-revert-buffer).
This is an example of advice that does this.
Later when xref will use revert-buffer-function,
this advice could be replaced by a simple hook call:

#+begin_src emacs-lisp
(define-advice xref-revert-buffer (:around (ofun &rest args) keep-outlines)
  "Keep hidden outlines after xref revert."
  (let ((regexp (outline-hidden-headings-regexp))
        (value (apply ofun args)))
    (outline-hide-by-heading-regexp regexp)
    value))
#+end_src


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: outline-by-regexp.patch --]
[-- Type: text/x-diff, Size: 2155 bytes --]

diff --git a/lisp/outline.el b/lisp/outline.el
index 5ac0f0707f1..d933bd4a444 100644
--- a/lisp/outline.el
+++ b/lisp/outline.el
@@ -92,6 +92,8 @@ outline-mode-prefix-map
     (define-key map "\C-o" 'outline-hide-other)
     (define-key map "\C-^" 'outline-move-subtree-up)
     (define-key map "\C-v" 'outline-move-subtree-down)
+    (keymap-set map "/ s" #'outline-show-by-heading-regexp)
+    (keymap-set map "/ h" #'outline-hide-by-heading-regexp)
     (define-key map [(control ?<)] 'outline-promote)
     (define-key map [(control ?>)] 'outline-demote)
     (define-key map "\C-m" 'outline-insert-heading)
@@ -1661,6 +1663,42 @@ outline--show-headings-up-to-level
          beg end)))
     (run-hooks 'outline-view-change-hook)))
 
+(defun outline-show-by-heading-regexp (regexp)
+  (interactive (list (read-regexp "Regexp to show outlines")))
+  (let (outline-view-change-hook)
+    (outline-map-region
+     (lambda ()
+       (when (string-match-p regexp (buffer-substring (pos-bol) (pos-eol)))
+         (outline-show-branches) ;; To reveal all parent headings
+         (outline-show-entry)))
+     (point-min) (point-max)))
+  (run-hooks 'outline-view-change-hook))
+
+(defun outline-hide-by-heading-regexp (regexp)
+  (interactive (list (read-regexp "Regexp to hide outlines")))
+  (let (outline-view-change-hook)
+    (outline-map-region
+     (lambda ()
+       (when (string-match-p regexp (buffer-substring (pos-bol) (pos-eol)))
+         (outline-hide-subtree)))
+     (point-min) (point-max)))
+  (run-hooks 'outline-view-change-hook))
+
+(defun outline-hidden-headings-regexp ()
+  (let ((headings))
+    (outline-map-region
+     (lambda ()
+       (when (save-excursion
+               (outline-end-of-heading)
+               (seq-some (lambda (o) (eq (overlay-get o 'invisible)
+                                         'outline))
+                         (overlays-at (point))))
+         (push (buffer-substring (pos-bol) (pos-eol)) headings)))
+     (point-min) (point-max))
+    (mapconcat (lambda (heading)
+                 (regexp-quote heading))
+               (nreverse headings) "\\|")))
+
 \f
 ;;; Visibility cycling
 

bug#49731: 28.0.50; Filter xref results by filename

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Juri Linkov <juri@linkov.net> writes:

>>> Now pushed to master in the commit 3573ebfa6d (it seems this is
>>> backward-compatible since it only sets buffer-local variables).
>>
>> Nice.
>>
>> Do you plan on adding an outline-[minor-]mode command to hide/show by
>> regexp?
>
> So now here are these two commands:
>
>   / s   outline-show-by-heading-regexp
>   / h   outline-hide-by-heading-regexp
>

Thanks.  Does it make sense for these commands to follow similar
semantics as Org Mode's sparse trees?  With C-c / / in an Org file, the
entire buffer is folded as much as possible, but the matching items are
made visible.  Here's a practical example:

* 1
abc
* 2
def
* 3
ghi

M-x org-mode
C-c / / ghi RET
(Only ghi section is visible.)
C-c / / abc RET
(Only abc section is visible.)
C-u C-c / / ghi RET <- Current folding status is kept.
(abc and ghi sections are visible.)

The main difference is that outline-show-by-heading-regexp would match
only headings, but that is clear given the name of the command.

bug#49731: 28.0.50; Filter xref results by filename

[Juri Linkov]

>>   / s   outline-show-by-heading-regexp
>>   / h   outline-hide-by-heading-regexp
>
> Thanks.  Does it make sense for these commands to follow similar
> semantics as Org Mode's sparse trees?  With C-c / / in an Org file, the
> entire buffer is folded as much as possible, but the matching items are
> made visible.

We don't have a goal to copy all Org Mode's features to Outline mode.
Only when someone really needs some Org Mode's feature, then patches
are welcome.

For example, very often I have the need to hide a large group of bodies
whose headings contain the same substring.  I guess you have the same need
since you created this feature request.  So this is implemented now.

> The main difference is that outline-show-by-heading-regexp would match
> only headings, but that is clear given the name of the command.

Indeed, the word 'heading' is added to the command names above
to distinguish them from possible future additions of more commands
that will hide by body regexps, or by both body and headings regexps.

Also the key prefix '/' will allow adding more related commands later
under the same key prefix like '/ /' for 'outline-occur', etc.

bug#49731: 28.0.50; Filter xref results by filename

[Juri Linkov]

close 49731 30.0.50
thanks

>>>   / s   outline-show-by-heading-regexp
>>>   / h   outline-hide-by-heading-regexp
>>
>> Thanks.  Does it make sense for these commands to follow similar
>> semantics as Org Mode's sparse trees?  With C-c / / in an Org file, the
>> entire buffer is folded as much as possible, but the matching items are
>> made visible.
>
> We don't have a goal to copy all Org Mode's features to Outline mode.
> Only when someone really needs some Org Mode's feature, then patches
> are welcome.

So now these commands are pushed, and this request is closed.

If you have a real need for more features, it's easy to reopen this
or create a new request.

bug#49731: 28.0.50; Filter xref results by filename

[Juri Linkov]

> Also there is an additional helper function that is needed
> to keep hidden outlines and restore them after reverting the
> xref buffer with 'g' (xref-revert-buffer).
> This is an example of advice that does this.
> Later when xref will use revert-buffer-function,
> this advice could be replaced by a simple hook call:
>
> #+begin_src emacs-lisp
> (define-advice xref-revert-buffer (:around (ofun &rest args) keep-outlines)
>   "Keep hidden outlines after xref revert."
>   (let ((regexp (outline-hidden-headings-regexp))
>         (value (apply ofun args)))
>     (outline-hide-by-heading-regexp regexp)
>     value))
> #+end_src

So here is the patch for xref:

diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el
index 0025f1f9479..0a5c9243027 100644
--- a/lisp/progmodes/xref.el
+++ b/lisp/progmodes/xref.el
@@ -1277,13 +1277,18 @@ xref-revert-buffer
   "Refresh the search results in the current buffer."
   (interactive)
   (let ((inhibit-read-only t)
-        (buffer-undo-list t))
+        (buffer-undo-list t)
+        restore-functions)
+    (when (boundp 'revert-buffer-restore-functions)
+      (run-hook-wrapped 'revert-buffer-restore-functions
+                        (lambda (f) (push (funcall f) restore-functions) nil)))
     (save-excursion
       (condition-case err
           (let ((alist (xref--analyze (funcall xref--fetcher)))
                 (inhibit-modification-hooks t))
             (erase-buffer)
-            (xref--insert-xrefs alist))
+            (prog1 (xref--insert-xrefs alist)
+              (mapc #'funcall (delq nil restore-functions))))
         (user-error
          (erase-buffer)
          (insert

bug#49731: 28.0.50; Filter xref results by filename

[Juri Linkov]

>> Also there is an additional helper function that is needed
>> to keep hidden outlines and restore them after reverting the
>> xref buffer with 'g' (xref-revert-buffer).
>> This is an example of advice that does this.
>> Later when xref will use revert-buffer-function,
>> this advice could be replaced by a simple hook call:
>>
>> #+begin_src emacs-lisp
>> (define-advice xref-revert-buffer (:around (ofun &rest args) keep-outlines)
>>   "Keep hidden outlines after xref revert."
>>   (let ((regexp (outline-hidden-headings-regexp))
>>         (value (apply ofun args)))
>>     (outline-hide-by-heading-regexp regexp)
>>     value))
>> #+end_src
>
> So here is the patch for xref:

This is pushed now as well.