From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings 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 13:18:22 +0000 Message-ID: References: <03aa81b5-6077-c35c-1a5f-ec4d867b59ac@yandex.ru> <63300a34-e487-02d1-c182-2b84438654d7@yandex.ru> <83k0j6trau.fsf@gnu.org> <838rzmtf00.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33731"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 50733@debbugs.gnu.org, dgutov@yandex.ru, mardani29@yahoo.es To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 24 15:19:12 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 1mTl6e-0008ch-Dk for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 24 Sep 2021 15:19:12 +0200 Original-Received: from localhost ([::1]:54300 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mTl6d-0007br-F7 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 24 Sep 2021 09:19:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56498) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mTl6U-0007Z6-QQ for bug-gnu-emacs@gnu.org; Fri, 24 Sep 2021 09:19:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45383) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mTl6U-0004Ry-Ia for bug-gnu-emacs@gnu.org; Fri, 24 Sep 2021 09:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mTl6U-0004XM-DJ for bug-gnu-emacs@gnu.org; Fri, 24 Sep 2021 09:19:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 24 Sep 2021 13:19: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.163248950617366 (code B ref 50733); Fri, 24 Sep 2021 13:19:02 +0000 Original-Received: (at 50733) by debbugs.gnu.org; 24 Sep 2021 13:18:26 +0000 Original-Received: from localhost ([127.0.0.1]:56929 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mTl5u-0004W0-Ci for submit@debbugs.gnu.org; Fri, 24 Sep 2021 09:18:26 -0400 Original-Received: from heytings.org ([95.142.160.155]:45976) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mTl5t-0004Vs-7x for 50733@debbugs.gnu.org; Fri, 24 Sep 2021 09:18:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1632489503; bh=hliP6yocegdMtgQTaX/ogGIiG8U9HDefrLGqlcKvc5Q=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=D/mIX9lhXTX2V9dwDzbekfyLlIpN0b9foe1UtEET+4HD5LruKn0QZ2PIl/Q67vDea WB8ktVppz78tDRgpJQpywXn8/xV2wFEBzZoccfiLWhasWdjOx67Y1Avb8WANcIHueN NbR9cRgbaiTtGEKgfu9hIK/eYa5fOaBWReqH9EbMh/HxgaQ30QzVgcKfy76Vzak1LC HHOT9TUELLd+DESQbQduQheaz9sQMgUrV2gQXwhhnxcpO94Jce01ApjoE7auI19Pk7 hfojepcMDB3lgx4kRiVrsEHyXx8hndYS0rb0HQHiuVyokodJWii/hy5ZNY8nLGNZFi Rn8s1u/n1rWaQ== In-Reply-To: <838rzmtf00.fsf@gnu.org> 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:215291 Archived-At: > > We are talking about project.el, so the focus should be on looking for > strings that are meaningful in the programming-language context, because > that is what we need when programming. Not looking for arbitrary > strings. > As Dmitry said, this isn't true. But let's assume that it is. The latter (arbitrary strings) is a superset of the former (identifiers). In practice if you search for some identifier, it's not a real problem to see a few more matches in, say, the README or a ChangeLog file. 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. > > If someone wants to look for arbitrary strings, they want "M-x grep" > (with or without ripgrep), not project-find-regexp. The meaning of > "word" or "symbol" is different in different PLs; a tool like Grep can > only approximate that, whereas ID Utils uses the correct definition for > each language. > 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. >> Moreover, incremental updates are not implemented in mkid. > > It doesn't matter, as it's fast enough, and putting it on some kind of > cron job is more than enough to allow forgetting that this step exists. > Five seconds to scan the whole Emacs trunk is IMO not fast enough (ripgrep does it in < 0.2 seconds). 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.