From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.bugs Subject: bug#50906: xref-find-references blocks Emacs: asynchronous operation? Date: Tue, 05 Oct 2021 08:29:12 +0200 Message-ID: References: <152761c7-d793-2fa5-430f-d018c4957f89@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14207"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) To: 50906@debbugs.gnu.org Cancel-Lock: sha1:rD3sAER0vtY6bHOoIQPr46Qw6OM= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 05 08:30:44 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 1mXdyO-0003Tk-4H for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 05 Oct 2021 08:30:44 +0200 Original-Received: from localhost ([::1]:40158 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mXdyM-0007hd-75 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 05 Oct 2021 02:30:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54722) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mXdxj-0007hS-6u for bug-gnu-emacs@gnu.org; Tue, 05 Oct 2021 02:30:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55515) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mXdxi-0004sN-Vb for bug-gnu-emacs@gnu.org; Tue, 05 Oct 2021 02:30:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mXdxi-0000W0-Pe for bug-gnu-emacs@gnu.org; Tue, 05 Oct 2021 02:30:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Helmut Eller Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Oct 2021 06:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50906 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.16334153731919 (code B ref -1); Tue, 05 Oct 2021 06:30:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 5 Oct 2021 06:29:33 +0000 Original-Received: from localhost ([127.0.0.1]:38828 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXdxF-0000Ut-2v for submit@debbugs.gnu.org; Tue, 05 Oct 2021 02:29:33 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:43562) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXdxC-0000Uk-Q9 for submit@debbugs.gnu.org; Tue, 05 Oct 2021 02:29:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54682) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mXdxC-0007gn-Hg for bug-gnu-emacs@gnu.org; Tue, 05 Oct 2021 02:29:30 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:36494) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mXdxB-0004Oo-08 for bug-gnu-emacs@gnu.org; Tue, 05 Oct 2021 02:29:30 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1mXdx8-0001rd-4Y for bug-gnu-emacs@gnu.org; Tue, 05 Oct 2021 08:29:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geb-bug-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 5 X-Spam_score: 0.5 X-Spam_bar: / X-Spam_report: (0.5 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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:216412 Archived-At: On Tue, Oct 05 2021, Dmitry Gutov wrote: > What can be done here: > > - Design an "asynchronous" format for xref-show-xrefs-function to > consume. FETCHER of a different shape. Not sure how it's going to > work in the end -- maybe a simple-ish iterator (call a function > again for more results), but ideally it would look synchronous > somehow, and the concurrency would be achieved through the use of > threads. Not sure if that's realistic. > > - The new kind of fetcher would need to provide a way to abort the > search, since 'C-g' would not be available anymore. > > - Implement it for the common searches of course. I think promises, as used in the Javascript world, would be a good fit for this kind of problem. Something like this: https://github.com/chuntaro/emacs-promise. > Downsides: > > - No way to quickly 'C-g' out of a search, supposedly one would have > to switch to the results buffer (maybe it will be selected right > away) and type 'C-c C-c'. And then kill the buffer, I guess? Maybe we could have some "promise framework" that solves this problem more generally, e.g., a list-promises command that works like list-processes and offers a command to cancel promises. > - The size threshold of a project where the improvement will be > significant is pretty big -- for instance, searching across the > Emacs checkout takes about 100-200ms (just the time the external > process uses). If the search results in many matches (1000s or > 10000s) the results will take a while to display, but most of the > time is taken up by processing of results which is implemented in > Lisp. We might have Emacs which shows the first results soon, but > then remains sluggish until all search results are processed. This > problem could be worked around, however, by limiting the displayed > number of results and having buttons like the ones at the bottom of > vc-print-root-log output buffer. > > - Search results come in unsorted, and, in the case of ripgrep, sorted > randomly every time the search is performed (the files, at > least). We sort them now at the bottom of xref-matches-in-files, but > asynchronous search results would make that infeasible. This is a good point and probably quite difficult to solve. I'm wondering if it would be possible to build some kind of index, like search engines do. So instead of grepping, we'd use the index and maybe invest more effort in ranking the results? Helmut