[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#49836: Support ripgrep in semantic-symref-tool-grep
From: |
Juri Linkov |
Subject: |
bug#49836: Support ripgrep in semantic-symref-tool-grep |
Date: |
Fri, 06 Aug 2021 03:35:02 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) |
>>> 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.