From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#50733: 28.0.1; project-find-regexp can block Emacs for a long time Date: Fri, 24 Sep 2021 17:20:32 +0300 Message-ID: <83sfxurr67.fsf@gnu.org> References: <03aa81b5-6077-c35c-1a5f-ec4d867b59ac@yandex.ru> <63300a34-e487-02d1-c182-2b84438654d7@yandex.ru> <83k0j6trau.fsf@gnu.org> <838rzmtf00.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31296"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 50733@debbugs.gnu.org, dgutov@yandex.ru, mardani29@yahoo.es To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 24 16:21:18 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 1mTm4j-0007y4-UG for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 24 Sep 2021 16:21:17 +0200 Original-Received: from localhost ([::1]:44832 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mTm4h-0003cU-0h for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 24 Sep 2021 10:21:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40032) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mTm4U-0003bS-SQ for bug-gnu-emacs@gnu.org; Fri, 24 Sep 2021 10:21:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47434) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mTm4U-0004zW-KC for bug-gnu-emacs@gnu.org; Fri, 24 Sep 2021 10:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mTm4U-0000sR-Cq for bug-gnu-emacs@gnu.org; Fri, 24 Sep 2021 10:21:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 24 Sep 2021 14:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50733 X-GNU-PR-Package: emacs Original-Received: via spool by 50733-submit@debbugs.gnu.org id=B50733.16324932523327 (code B ref 50733); Fri, 24 Sep 2021 14:21:02 +0000 Original-Received: (at 50733) by debbugs.gnu.org; 24 Sep 2021 14:20:52 +0000 Original-Received: from localhost ([127.0.0.1]:58980 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mTm4G-0000rX-St for submit@debbugs.gnu.org; Fri, 24 Sep 2021 10:20:52 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51150) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mTm4E-0000rG-Tr for 50733@debbugs.gnu.org; Fri, 24 Sep 2021 10:20:47 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54864) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mTm48-0004jp-E2; Fri, 24 Sep 2021 10:20:40 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3970 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mTm47-0005AZ-17; Fri, 24 Sep 2021 10:20:39 -0400 In-Reply-To: (message from Gregory Heytings on Fri, 24 Sep 2021 13:18:22 +0000) 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:215308 Archived-At: > Date: Fri, 24 Sep 2021 13:18:22 +0000 > From: Gregory Heytings > cc: 50733@debbugs.gnu.org, dgutov@yandex.ru, mardani29@yahoo.es > > IMO, the one and only case where a specialized tool beats ripgrep (or just > plain grep) is when you just want the place(s) where the identifier is > defined. No, a specialized tool that uses a DB will scale much better than any tool which searches the filesystem. _And_ it will be more accurate (if used correctly). > That's not correct, mkid only supports a limited number of programming > languages. And it's not even precise: rg O_CREAT on the Emacs trunk for > example returns 45 matches, gid O_CREAT returns 33 matches. I'm sorry, but this has NIH written all over it. Am I right guessing that you aren't an active user of ID Utils, and perhaps didn't even know about it before I mentioned it? More to the point: are you saying that a tool that returns more matches is necessarily better? That'd fly in the face of our switching to the Xref package, whose explicit goal was to provide _fewer_ matches, the ones that matter. Look closer at those matches which gid "missed", and you will see why it didn't show them to you. Oh, and if ripgrep finds only 45 matches, then something is wrong with it, because there are actually no less than 119 literal matches for O_CREAT in the tree (not counting many binary files that also match). So by this measure, ripgrep is also not the right tool for the job. > Five seconds to scan the whole Emacs trunk is IMO not fast enough (ripgrep > does it in < 0.2 seconds). Those 5 sec are invested only when needed, while the time it takes Grep/ripgrep to scan the files is invested every search. Do this enough times, and you paid too much time. > And without incremental updates, updating the database would be > necessary before each invocation of gid, because what users expect > when they search for something are accurate results corresponding to > the current state of the project, not results from, say, an hour > ago. It is very easy to trigger a new mkid run from a file-notification that watches the project tree, so that it runs in the background without the user noticing when needed. Puff! the problem's gone.