From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#49836: Support ripgrep in semantic-symref-tool-grep Date: Thu, 5 Aug 2021 06:03:08 +0300 Message-ID: References: <87sfzrbke1.fsf_-_@mail.linkov.net> <875ywn556i.fsf@mail.linkov.net> <87sfzo3nvm.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7100"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 Cc: 49836@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Aug 05 05:04:11 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 1mBTg2-0001ik-TL for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 05 Aug 2021 05:04:11 +0200 Original-Received: from localhost ([::1]:59714 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mBTg1-000869-Fh for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 04 Aug 2021 23:04:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48928) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mBTfu-00083c-5T for bug-gnu-emacs@gnu.org; Wed, 04 Aug 2021 23:04:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33986) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mBTft-0003tT-UW for bug-gnu-emacs@gnu.org; Wed, 04 Aug 2021 23:04:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mBTft-0002XT-N4 for bug-gnu-emacs@gnu.org; Wed, 04 Aug 2021 23:04:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Aug 2021 03:04: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.16281325999693 (code B ref 49836); Thu, 05 Aug 2021 03:04:01 +0000 Original-Received: (at 49836) by debbugs.gnu.org; 5 Aug 2021 03:03:19 +0000 Original-Received: from localhost ([127.0.0.1]:45532 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mBTfC-0002WH-SI for submit@debbugs.gnu.org; Wed, 04 Aug 2021 23:03:19 -0400 Original-Received: from mail-wr1-f42.google.com ([209.85.221.42]:38481) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mBTfB-0002W2-IR for 49836@debbugs.gnu.org; Wed, 04 Aug 2021 23:03:17 -0400 Original-Received: by mail-wr1-f42.google.com with SMTP id l18so4510813wrv.5 for <49836@debbugs.gnu.org>; Wed, 04 Aug 2021 20:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=HO8Kqm7btRWv67cz8Qzo3EeVq56p1GXqbo5XOZVNEoY=; b=DJSR5sC4vtabFPoOzsFSkm492+xqRnWAMhpW30jyV/uIlFMVUDoiuQZQxF82THj8Pa 5i4T+EDhc8GUs1avf6yaxy2rk5a7XX3TsyHmQCngxvi7qEk3QDvHOEoMsTEAFRBpgAQG nXIRXaFBKLQSrOO8SLwqJ3/bP7d04+ARBybW427PCfE5erJqqtCtoMlsZZv6CeWiFpTh 3wf5BwDFBR0FTxO6sej3a06cHZ8qU/yVAdgeMcJfQUL65sGCeIwK4q2EF5h+I9CARAY5 WbuWVc/jvnLovGb0t9bxT3Fs5U2WL4S2rIirgvb6SuFCiBwFuJvdNIWRmVbPpE3WOat/ VF+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HO8Kqm7btRWv67cz8Qzo3EeVq56p1GXqbo5XOZVNEoY=; b=pCESmfhH1YSS7yUNn17s7yq0aECXVzZyLZMb4xHKTfLHWy3hJtOpGb3uV2ih3czKu1 y/KKmu2Y2cBMDmcGU7dJq1ahqPIiNB1yOgXPvGs2DZlNvsJkapEfvH+6CB92DObO0yfa ggRHHm5boj+A6rkSloVx6Cs6OlB4IHaT3hBFLnNCSiKPozx5UwMKPWnEo1Qeajra7zHv fk0hjs7JdEQz0Qu6JUFYpxQp2k6J/wFXnG7Sh+Y+jw/ihI/pyGvO+Y9I9AwlYkM5eVlR GwE0fhJRIDd/KlX+LCLfWlTqbd5hCsmK0gZIaLRtpUixFb/jn4TjAtSYoDuuW/0eluPx 1EAw== X-Gm-Message-State: AOAM531OR652rr8sRQ6bs8ApLQfrLhNBUKgG8NBvcNR6G9/JPMgCPxK4 JP8OqG1HFtstiPJjsO3Uyvqdx78jxKk= X-Google-Smtp-Source: ABdhPJzj0SOy5zFUgD6DCp8JoKM6HKuZ6ztsAwlyR7/Qp0nS+QeZNpT9//NrN/kH4wCwmv684h77rA== X-Received: by 2002:a5d:6448:: with SMTP id d8mr2359033wrw.295.1628132591541; Wed, 04 Aug 2021 20:03:11 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id u11sm4402219wrp.26.2021.08.04.20.03.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Aug 2021 20:03:10 -0700 (PDT) In-Reply-To: <87sfzo3nvm.fsf@mail.linkov.net> Content-Language: en-US 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:211198 Archived-At: On 05.08.2021 00:23, Juri Linkov wrote: >> 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. > 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? 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. 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. 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. > The new user option is already used in many places in grep.el > in the previous patch, so it should be ok to use it in semantic-symref > as well: > > diff --git a/lisp/cedet/semantic/symref/grep.el b/lisp/cedet/semantic/symref/grep.el > index 180d779a78..b7d08409aa 100644 > --- a/lisp/cedet/semantic/symref/grep.el > +++ b/lisp/cedet/semantic/symref/grep.el > @@ -150,15 +150,22 @@ semantic-symref-perform-search > "-l ") > ((eq (oref tool searchtype) 'regexp) > "-nE ") > - (t "-n "))) > + (t (if (equal grep-program "rg") > + ;; TODO: remove this after ripgrep is fixed (bug#49836) > + (unless (string-search "rg -nH" grep-find-template) > + "-n ") > + "-n ")))) I'm actually fine with this part. > (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") > + (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.