[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: |
Mon, 2 Aug 2021 05:09:30 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 |
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,
Dmitry Gutov <=