From: Juri Linkov <juri@linkov.net>
To: 49836@debbugs.gnu.org
Subject: bug#49836: Support ripgrep in semantic-symref-tool-grep
Date: Tue, 03 Aug 2021 00:05:02 +0300 [thread overview]
Message-ID: <87sfzrbke1.fsf_-_@mail.linkov.net> (raw)
[-- Attachment #1: Type: text/plain, Size: 3642 bytes --]
Creating a separate bug report from bug#49731 because this is a real problem.
Now grep.el completely supports ripgrep when 'grep-find-template'
is customized to a command line that uses 'rg' such as e.g.
"find <D> <X> -type f <F> -print0 | sort -z | xargs -0 -e
rg <C> -nH --no-heading -j8 --sort path -M 200 --max-columns-preview -e <R>"
But such grep setting breaks the command 'xref-find-references':
>>>> 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.
Maybe like the existing option 'semantic-symref-grep-shell', e.g.:
(defcustom semantic-symref-grep-program 'grep
"The program to use for regexp search inside files."
:type `(choice
(const :tag "Use Grep" grep)
(const :tag "Use ripgrep" ripgrep)
(symbol :tag "User defined"))
:version "28.1")
But the problem is that for users it's hard to see the connection
between the broken 'xref-find-references' and the need to customize an option
with unrelated name 'semantic-symref-grep'.
>> 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.
A more general solution would be to add to grep.el the same options
that you added to xref:
xref-search-program grep/ripgrep
xref-search-program-alist
'((grep . "xargs -0 grep <C> -snHE -e <R>")
(ripgrep . "xargs -0 rg <C> -nH --no-messages -g '!*/' -e <R> | sort -t: -k1,1 -k2n,2"))
This means to turn the existing variable 'grep-program' into the user option
as the following patch does.
Also later grep.el could use the value "rg" of 'grep-program'
to create the corresponding grep-find-template in grep-compute-defaults.
But I don't know if it's ok to mention rigrep in grep.el?
Anyway, here is the patch that fixes 'xref-find-references':
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: grep-program.patch --]
[-- Type: text/x-diff, Size: 2029 bytes --]
diff --git a/lisp/progmodes/grep.el b/lisp/progmodes/grep.el
index 8f0a5acf70..aba4d59371 100644
--- a/lisp/progmodes/grep.el
+++ b/lisp/progmodes/grep.el
@@ -484,9 +484,13 @@ grep-mode-font-lock-keywords
This gets tacked on the end of the generated expressions.")
;;;###autoload
-(defvar grep-program (purecopy "grep")
+(defcustom grep-program (purecopy "grep")
"The default grep program for `grep-command' and `grep-find-command'.
-This variable's value takes effect when `grep-compute-defaults' is called.")
+This variable's value takes effect when `grep-compute-defaults' is called."
+ :type `(choice
+ (const :tag "Use Grep" "grep")
+ (string :tag "User defined"))
+ :version "28.1")
;;;###autoload
(defvar find-program (purecopy "find")
diff --git a/lisp/cedet/semantic/symref/grep.el b/lisp/cedet/semantic/symref/grep.el
index 180d779a78..e13c21bc07 100644
--- a/lisp/cedet/semantic/symref/grep.el
+++ b/lisp/cedet/semantic/symref/grep.el
@@ -150,15 +150,17 @@ semantic-symref-perform-search
"-l ")
((eq (oref tool searchtype) 'regexp)
"-nE ")
- (t "-n ")))
+ (t (if (equal grep-program "rg") "" "-n "))))
(greppat (cond ((eq (oref tool searchtype) 'regexp)
(oref tool searchfor))
(t
;; Can't use the word boundaries: Grep
;; doesn't always agree with the language
;; syntax on those.
- (format "\\(^\\|\\W\\)%s\\(\\W\\|$\\)"
- (oref tool searchfor)))))
+ (if (equal grep-program "rg")
+ (oref tool searchfor)
+ (format "\\(^\\|\\W\\)%s\\(\\W\\|$\\)"
+ (oref tool searchfor))))))
;; Misc
(b (get-buffer-create "*Semantic SymRef*"))
(ans nil)
next reply other threads:[~2021-08-02 21:05 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-02 21:05 Juri Linkov [this message]
2021-08-03 8:10 ` bug#49836: Support ripgrep in semantic-symref-tool-grep Juri Linkov
2021-08-04 3:14 ` Dmitry Gutov
2021-08-04 21:23 ` Juri Linkov
2021-08-05 3:03 ` Dmitry Gutov
2021-08-06 0:35 ` Juri Linkov
2021-08-07 14:12 ` Dmitry Gutov
2021-09-18 13:53 ` Mattias Engdegård
2021-09-18 14:14 ` Eli Zaretskii
2021-09-18 14:18 ` Mattias Engdegård
2021-09-18 14:25 ` Eli Zaretskii
2021-09-18 21:48 ` Dmitry Gutov
2021-09-18 23:53 ` Dmitry Gutov
2021-09-19 0:21 ` Jim Porter
2021-09-19 10:11 ` Mattias Engdegård
2021-09-20 0:14 ` Dmitry Gutov
2021-09-20 5:09 ` Jim Porter
2021-09-20 17:04 ` Dmitry Gutov
[not found] <83h7elbzo3.fsf@gnu.org>
[not found] ` <7b0409e3-fc88-b34e-9365-25356bb85859@yandex.ru>
[not found] ` <83bl4tbxyu.fsf@gnu.org>
[not found] ` <12215e07-af4e-2db7-1869-16ac92feb806@yandex.ru>
[not found] ` <8335q5bt9b.fsf@gnu.org>
[not found] ` <ee8b7d7f-abd1-42fc-a273-819ccef3c4e7@yandex.ru>
2021-09-17 16:07 ` Juri Linkov
2021-09-17 16:24 ` Lars Ingebrigtsen
2021-09-18 18:37 ` Juri Linkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sfzrbke1.fsf_-_@mail.linkov.net \
--to=juri@linkov.net \
--cc=49836@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).