bug#49731: 28.0.50; Filter xref results by filename

[Dmitry Gutov <dgutov@yandex.ru>]

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