From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster) Date: Thu, 05 Mar 2020 02:04:38 +0200 Organization: LINKOV.NET Message-ID: <87r1y7odxt.fsf@mail.linkov.net> References: <505E43E1.9090801@yandex.ru> <505E4A57.5020305@yandex.ru> <871rzer8t2.fsf@mail.linkov.net> <8d51a8c9-6200-84c9-cadb-09576b060fe1@yandex.ru> <87o92h7fv1.fsf@mail.linkov.net> <878stissii.fsf@mail.linkov.net> <87muhtzh8z.fsf@mail.linkov.net> <875zfvzfvp.fsf@mail.linkov.net> <8772f3cb-5af2-f89a-db47-682d9feef125@yandex.ru> <87lfoqjr20.fsf@mail.linkov.net> <87y2slup32.fsf@mail.linkov.net> <318f40f9-78ae-d739-6ac8-b7bb04598aad@yandex.ru> <877e022uul.fsf@mail.linkov.net> <3c0c8d61-1df2-b481-655a-d0b610ee6324@yandex.ru> <8736ap10x9.fsf@mail.linkov.net> <3631ca1d-9a11-8ff6-08bb-6d18268e47d2@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="13857"; 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: 12492@debbugs.gnu.org, Lars Ingebrigtsen To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Mar 05 01:23:18 2020 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 1j9eIH-0003TJ-VM for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 05 Mar 2020 01:23:18 +0100 Original-Received: from localhost ([::1]:41642 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j9eIH-0003tS-0L for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 04 Mar 2020 19:23:17 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59753) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j9eI3-0003so-20 for bug-gnu-emacs@gnu.org; Wed, 04 Mar 2020 19:23:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j9eI1-0002Oe-PT for bug-gnu-emacs@gnu.org; Wed, 04 Mar 2020 19:23:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36049) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j9eI1-0002OX-Ld for bug-gnu-emacs@gnu.org; Wed, 04 Mar 2020 19:23:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j9eI1-0005YT-Ih for bug-gnu-emacs@gnu.org; Wed, 04 Mar 2020 19:23:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Mar 2020 00:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12492 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 12492-submit@debbugs.gnu.org id=B12492.158336774321292 (code B ref 12492); Thu, 05 Mar 2020 00:23:01 +0000 Original-Received: (at 12492) by debbugs.gnu.org; 5 Mar 2020 00:22:23 +0000 Original-Received: from localhost ([127.0.0.1]:42019 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j9eHO-0005XM-OX for submit@debbugs.gnu.org; Wed, 04 Mar 2020 19:22:23 -0500 Original-Received: from black.elm.relay.mailchannels.net ([23.83.212.19]:30807) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j9eHM-0005XC-Q3 for 12492@debbugs.gnu.org; Wed, 04 Mar 2020 19:22:21 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id AA767120FB4; Thu, 5 Mar 2020 00:22:19 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a3.g.dreamhost.com (100-96-1-27.trex.outbound.svc.cluster.local [100.96.1.27]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 116EF121043; Thu, 5 Mar 2020 00:22:19 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from pdx1-sub0-mail-a3.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Thu, 05 Mar 2020 00:22:19 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Lettuce-Attack: 6405ac7f23941062_1583367739508_3466173448 X-MC-Loop-Signature: 1583367739508:2037714732 X-MC-Ingress-Time: 1583367739507 Original-Received: from pdx1-sub0-mail-a3.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a3.g.dreamhost.com (Postfix) with ESMTP id 2DF197F78E; Wed, 4 Mar 2020 16:22:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=cEAUxSqBpvj6Lx7UV9+sia08MIk=; b= PMY/9/xBq48GvkDCPhhn6MZfYbt6c6SilrCdrO7ZuwHNeXFdfwy9+8xBCOV38pO+ TLUMjSgWJwnzwbLVzkzEMIbP8Amxkk8FS/CCJprngSLs0Vpb4tKlm9hxT9kpHF5S FlinuJyRb64piHudONmVKTIZaPeqjrGSqS8rxmci9SY= Original-Received: from mail.jurta.org (m91-129-103-27.cust.tele2.ee [91.129.103.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a3.g.dreamhost.com (Postfix) with ESMTPSA id A53417F795; Wed, 4 Mar 2020 16:22:11 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a3 In-Reply-To: <3631ca1d-9a11-8ff6-08bb-6d18268e47d2@yandex.ru> (Dmitry Gutov's message of "Wed, 4 Mar 2020 14:05:27 +0200") X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedruddtledgvddtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgesthdtredttdertdenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucffohhmrghinhepphgvthhtohhnrdhfrhenucfkphepledurdduvdelrddutdefrddvjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledruddtfedrvdejpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepughguhhtohhvseihrghnuggvgidrrhhu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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:176875 Archived-At: >>> project-find-regexp is both faster in most situations, works remotely, and >>> provides a decent UI. >> project-find-regexp is not asynchronous whereas vc-git-grep is. > > There's no project-agnostic asynchronous option on the table now. Only getting project file names should be synchronous and blocking, everything else (including grepping) could be asynchronous. >> UI of project-find-regexp is non-standard. A more familiar UI >> would be like in occur, for example, as used by noccur-project. > > It is standard enough, Xref commands use it. And they have both default key > bindings and menu items. > > noccur-project like this naive implementation? > https://nicolas.petton.fr/blog/mutli-occur-on-projects.html It works fine as a proof of concept. > How long does it take to search the Emacs project for an arbitrary string > on your machine? The result is almost instantaneous: 1 sec on Emacs repo. > Not to mention the unfortunate side-effect of having to visit 4000 buffers. It visits only matched buffers. >>> BTW, I wonder how such project-isearch using multi-isearch-files would work >>> in a non-toy project with a sufficiently-rare input. >>> >>> Even if we take the Emacs project itself, loading all 4000 files into >>> Emacs's memory to search through them all is likely to take a lot of time. >> No problem at all - trying on the Emacs project: >> (multi-isearch-files (project-files (project-current t))) >> is like project-search, but with more convenient UI: >> it's easier to type C-s to go to the next occurrence than >> to invoke the command M-x fileloop-continue that has no keybinding. > > "like project-search" also implies "to take a lot of time", that's where > I made that conclusion from. How long does it take for the UI to say "no > matches"? Depends on the search string. > The UI is probably better (the main thing I like about this idea), but the > downside is opening several buffers with intermediate matches for > incomplete input (while you're still typing the search string). Though I > don't know how serious of a problem that is. Probably multi-isearch-files could be useful for projects with small number of files. > And when I try this, I'm getting messages about uncompressing files, and > prompts about local variables, which I can't answer. OT1H, an ability to search in compressed files is an advantage - even grep can't search in compressed files. OTOH, it had to visit all files - this is its downside.