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#50733: 28.0.1; project-find-regexp can block Emacs for a long time Date: Fri, 24 Sep 2021 15:22:39 +0300 Message-ID: <4c2be3c4-52f5-00c2-9c31-eafa0df5bfd9@yandex.ru> References: <03aa81b5-6077-c35c-1a5f-ec4d867b59ac@yandex.ru> <63300a34-e487-02d1-c182-2b84438654d7@yandex.ru> <83k0j6trau.fsf@gnu.org> <5679c01b-51d0-903d-039a-8102f64fdb37@yandex.ru> <8335putc4z.fsf@gnu.org> 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="39847"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 Cc: 50733@debbugs.gnu.org, 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 14:44:49 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 1mTkZN-000AAT-Eo for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 24 Sep 2021 14:44:49 +0200 Original-Received: from localhost ([::1]:49680 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mTkZM-0005D1-9c for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 24 Sep 2021 08:44:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46018) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mTkEI-0006yj-LY for bug-gnu-emacs@gnu.org; Fri, 24 Sep 2021 08:23:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45355) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mTkEI-00071k-9K for bug-gnu-emacs@gnu.org; Fri, 24 Sep 2021 08:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mTkEI-0000Z0-2H for bug-gnu-emacs@gnu.org; Fri, 24 Sep 2021 08:23:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 24 Sep 2021 12:23: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.16324861712132 (code B ref 50733); Fri, 24 Sep 2021 12:23:02 +0000 Original-Received: (at 50733) by debbugs.gnu.org; 24 Sep 2021 12:22:51 +0000 Original-Received: from localhost ([127.0.0.1]:56901 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mTkE6-0000YK-QQ for submit@debbugs.gnu.org; Fri, 24 Sep 2021 08:22:51 -0400 Original-Received: from mail-wr1-f46.google.com ([209.85.221.46]:33666) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mTkE5-0000Y2-HU for 50733@debbugs.gnu.org; Fri, 24 Sep 2021 08:22:49 -0400 Original-Received: by mail-wr1-f46.google.com with SMTP id t18so27035169wrb.0 for <50733@debbugs.gnu.org>; Fri, 24 Sep 2021 05:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=kpskrbAadRsxUY8i0fy8g7pyixeQZ4FzsKZGDiLXTjc=; b=ohd/VvU3Zg6sC9jMKgp+YOagaDjwazmE2X/XsWlq++Hm8lqw7wJoV/DuZYge9kkRtW qcyvtnXKWgpQc1ZacB44BZExOKQgEq0273rBU+Qh8h0ZeE9Y5NRZToZpFg8xb2zBtOh5 WyIhanhmw6WFWSIraV0d4RmV6xSjyA2kyE1fZ/MBfgWNhlxOZk+zuYL/phYcgSpF41YG GAWKArgDPQXXfKXS8YywW1VJTxhFZksx507XQBuPq+cuEm1a5R7zQGJ6J3Rr/v+R9vme 77l7XtjRMAA9t4kQoJ2eh0ilYw2C24ulENGYH/RtI79s5CYv5qNdHmTorqI5bFRmbDx4 Hqfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=kpskrbAadRsxUY8i0fy8g7pyixeQZ4FzsKZGDiLXTjc=; b=MgKGWHDrKlgBE2AG61wAhylsUuTb3qfpUILsUL5d95HFeSdf5bOBOIXn0Usq7JjoXn RcTBthckBxC7kBJvXWqg1mudA+5KKhuAZsIEir3B2uexXpAy1PJayMXg24aUnSr5FBnE AAAY1y+wannHKYXHJ+FDJ4puI26fc34RPfwAKuwX2a3D83uJG0pohDm7z93n2zTr4YvO DSBDhaeqYQf/5plVEnNRBkJywWadxT2PShi9wnpVfDTMy+bd3QboVQG/C8o4F2Cm7Usq bXQrFDibBH7eDr39h0xFiE8s1RL/R8aghKsv/X6kVuue7ybisUnThNH6PXrP1gLChRzh 2abA== X-Gm-Message-State: AOAM5309ZQ4jQ8t/SoPTaKcnEaPnPhE1h3ZNdzfSfFdUkXKI+imRR+4P MMNENX5uu0oQahrO6V7yLThLbJTvunA= X-Google-Smtp-Source: ABdhPJywN0oFcIykHs8ezbcaCROg1SIHhhkW71U0ALqA3B/1oKdho+NXnEwOXfiyWg725zFHRrjM4w== X-Received: by 2002:a5d:4f06:: with SMTP id c6mr11133635wru.384.1632486163669; Fri, 24 Sep 2021 05:22:43 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id c77sm8264938wme.46.2021.09.24.05.22.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Sep 2021 05:22:42 -0700 (PDT) In-Reply-To: <8335putc4z.fsf@gnu.org> 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:215288 Archived-At: On 24.09.2021 15:02, Eli Zaretskii wrote: > You don't need to convince me, I have all of those installed, and > couldn't do without them. The difficulties are practical, not > principal. Bundling extra tools affects the size of the distribution, for example. I figured that's something you might have an opinion on. >> What is the concern about the presence of the current maintainer? Would >> we do something different if he leaves? We'd probably need to find >> another maintainer, no? > > Yes, and the question is: will we succeed, and how quickly? We > already had a period of time without one, which means having no one is > not a theoretical danger. I'm not sure how that affects our opinion on bundling, though. >>> Btw, I don't understand why we focus on general-purpose text-searching >>> tools for these features. Why not focus on packages like ID Utils >>> instead, they are so much faster. Daniel, could you time the same >>> search in that large tree when xref-search-program is 'gid'? (You'd >>> need to run 'mkid' first, to create the ID database, but that is >>> one-time, and is very fast.) >> >> There is no such option in xref-search-program. > > Hmm... I'm sure this worked in the past, at least for > xref-find-references? Or does that use a different variable? Different variable, yes: semantic-symref-tool. It affects xref-find-references. >> If you can suggest an >> appropriate invocation for xref-search-program-alist, I can try and add it. > > Just "gid -r ". But if this could run in an arbitrary directory, > there should also be a "-f .../ID" argument, telling it where to find > the ID database (usually, in the project's root). Anyway, it seems the most pressing problem is not the performance of the external tool (ripgrep is quite fast, for example). But our post-processing of the results, when there are a lot of them. id-tools (or alternatives) could help avoid the "fetch all project files" step, though. At the cost of extra manual management, which I personally don't like much. >> But I thought id-tools are for scanning for identifiers, not for >> arbitrary regexp searches? > > They can scan for identifiers that match regular expressions, where > "identifier" is defined by each file's PL. > >> > As I told many times, I think this is >> > the future: program language sensitive tools that use a precomputed >> > DB. >> >> xref-find-references implies some language-awareness. >> project-find-regexp does not. > > Are you sure people indeed use project-find-regexp _only_ for > language-agnostic searches? Oh, I use it for all kinds of searches. The point is not being limited in the search input or the choice of files to search. Instead, we can and will add UI for specifying extra filters for the results. > Anyway, maybe we need a separate command, or a different (but similar) > tool, one that indexes the tokens in the project files instead of > scanning all of the files each time anew. "Tokens" implies searching only for identifiers, no?