From: Juri Linkov <juri@linkov.net>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: 49836@debbugs.gnu.org
Subject: bug#49836: Support ripgrep in semantic-symref-tool-grep
Date: Fri, 06 Aug 2021 03:35:02 +0300 [thread overview]
Message-ID: <87tuk38kq9.fsf@mail.linkov.net> (raw)
In-Reply-To: <ee3bb56a-7e2a-535a-a83e-c577ae35496a@yandex.ru> (Dmitry Gutov's message of "Thu, 5 Aug 2021 06:03:08 +0300")
>>> I think the original idea (surrounding with \W) is sound: after all, not
>>> every symbol boundary in Emacs sense is a word boundary in Grep or RG. If
>>> a method, say, ends with ?, then it won't be.
>> I tried to search for 'soap-type-is-array?' in the Emacs tree,
>> and ripgrep can find it with "\\b%s\\b", but Grep can't.
>
> Did you search through symref, or in console? If the former, it seems some
> regexp-quoting is missing somewhere (the question mark was no
> escaped). Because see what the console says:
>
> $ rg "\bsoap-type-is-array?\b"
> lisp/net/soap-client.el
> 950:(defun soap-type-is-array? (type)
> 990: (if (soap-type-is-array? type)
>
> ChangeLog.2
> 19080: * lisp/net/soap-client.el (soap-type-is-array?): new defun
>
> $ rg "\bsoap-type-is-array\?\b"
>
> ^^ no matches
>
> And
>
> $ rg "\bsoap-type-is-array\?"
>
> has matches, of course.
semantic-symref-grep-use-template constructs such command line:
"rg ... -e \\\\bsoap-type-is-array\\?\\\\b"
that finds matches.
>> It would be more preferable not to change the existing default logic
>> to avoid possible troubles. Since Grep with Basic syntax works fine,
>> then better not to switch to Extended syntax.
>
> See above. But also consider what happens if a user sees that grep-program
> is now customizable and ripgrep is an officially supported value. They
> change it to "rg", and then suddenly their 'M-x rgrep' input has to use the
> extended regexp format?
This difference could be explained in the documentation.
> Worse than that, any third-party package that uses grep-find-template will
> suddenly have a high chance of failing if they pass any nontrivial regexps
> to it, especially if those have groupings or alternations.
This already happened after trying to customize grep-find-template
to use rg broke xref-find-references, so the problem already exists
and needs to be solved.
> It's a hard problem: grep.el is not prepared for abstracting like that. If
> we at least standardized it internally on Extended format, that would at
> least remove one source of uncertainty and bugs. The user still can input
> basic regexps interactively, we can translate them easily.
Is there a package that can translate between them reliably?
> Further: seeing xref-search-program-alist, people asked for support for
> other similar programs, such as ag and pt. Any solution we end up with, we
> should try to ensure they are valid values of grep-program as well.
Why not, semantic-symref already supports alternative tools
such as cscope, global, idutils. So xref could support more too.
>> + (if (equal grep-program "rg")
>> + (format "(^|\\W)%s(\\W|$)"
>> + (oref tool searchfor))
>> + (format "\\(^\\|\\W\\)%s\\(\\W\\|$\\)"
>> + (oref tool searchfor))))))
>
> This can work. Except the comparison should be with "grep", I think: all
> other alternatives only work with the Extended format.
I'm worried about the case when the user customizes
'grep-program' to e.g. an absolute path "/bin/grep"
or "/usr/local/bin/grep", etc.
next prev parent reply other threads:[~2021-08-06 0:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-02 21:05 bug#49836: Support ripgrep in semantic-symref-tool-grep Juri Linkov
2021-08-03 8:10 ` 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 [this message]
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
-- strict thread matches above, loose matches on Subject: below --
2021-09-15 15:56 master 544db1e: Faster grep pattern for identifiers Eli Zaretskii
2021-09-15 16:25 ` Dmitry Gutov
2021-09-15 16:33 ` Eli Zaretskii
2021-09-15 18:06 ` Dmitry Gutov
2021-09-15 18:14 ` Eli Zaretskii
2021-09-15 18:39 ` Dmitry Gutov
2021-09-17 16:07 ` bug#49836: Support ripgrep in semantic-symref-tool-grep 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tuk38kq9.fsf@mail.linkov.net \
--to=juri@linkov.net \
--cc=49836@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.