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