From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#49836: Support ripgrep in semantic-symref-tool-grep Date: Fri, 06 Aug 2021 03:35:02 +0300 Organization: LINKOV.NET Message-ID: <87tuk38kq9.fsf@mail.linkov.net> References: <87sfzrbke1.fsf_-_@mail.linkov.net> <875ywn556i.fsf@mail.linkov.net> <87sfzo3nvm.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35415"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) Cc: 49836@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Aug 06 02:51:10 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mBo4s-0008zt-1x for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 06 Aug 2021 02:51:10 +0200 Original-Received: from localhost ([::1]:43538 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mBo4q-0005Vv-FC for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 05 Aug 2021 20:51:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49172) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mBo4k-0005Vf-03 for bug-gnu-emacs@gnu.org; Thu, 05 Aug 2021 20:51:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37159) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mBo4j-0000wV-Pj for bug-gnu-emacs@gnu.org; Thu, 05 Aug 2021 20:51:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mBo4j-0004ci-Ml for bug-gnu-emacs@gnu.org; Thu, 05 Aug 2021 20:51:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Aug 2021 00:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49836 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 49836-submit@debbugs.gnu.org id=B49836.162821101617711 (code B ref 49836); Fri, 06 Aug 2021 00:51:01 +0000 Original-Received: (at 49836) by debbugs.gnu.org; 6 Aug 2021 00:50:16 +0000 Original-Received: from localhost ([127.0.0.1]:48702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mBo40-0004ba-CR for submit@debbugs.gnu.org; Thu, 05 Aug 2021 20:50:16 -0400 Original-Received: from relay8-d.mail.gandi.net ([217.70.183.201]:51303) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mBo3x-0004bF-AJ for 49836@debbugs.gnu.org; Thu, 05 Aug 2021 20:50:15 -0400 Original-Received: (Authenticated sender: juri@linkov.net) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 16F6B1BF207; Fri, 6 Aug 2021 00:50:05 +0000 (UTC) In-Reply-To: (Dmitry Gutov's message of "Thu, 5 Aug 2021 06:03:08 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:211282 Archived-At: >>> 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.