From unknown Fri Jun 20 07:27:33 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#50906 <50906@debbugs.gnu.org> To: bug#50906 <50906@debbugs.gnu.org> Subject: Status: xref-find-references blocks Emacs: asynchronous operation? Reply-To: bug#50906 <50906@debbugs.gnu.org> Date: Fri, 20 Jun 2025 14:27:33 +0000 retitle 50906 xref-find-references blocks Emacs: asynchronous operation? reassign 50906 emacs submitter 50906 Stefan Kangas severity 50906 wishlist thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 29 18:49:46 2021 Received: (at submit) by debbugs.gnu.org; 29 Sep 2021 22:49:46 +0000 Received: from localhost ([127.0.0.1]:50923 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mViOX-0001dc-W4 for submit@debbugs.gnu.org; Wed, 29 Sep 2021 18:49:46 -0400 Received: from lists.gnu.org ([209.51.188.17]:39998) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mViOF-0001d9-Mj for submit@debbugs.gnu.org; Wed, 29 Sep 2021 18:49:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49098) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mViOB-0006EC-P2 for bug-gnu-emacs@gnu.org; Wed, 29 Sep 2021 18:49:27 -0400 Received: from mail-pf1-f174.google.com ([209.85.210.174]:33540) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mViOA-00012b-7X for bug-gnu-emacs@gnu.org; Wed, 29 Sep 2021 18:49:23 -0400 Received: by mail-pf1-f174.google.com with SMTP id s16so3275548pfk.0 for ; Wed, 29 Sep 2021 15:49:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=kNx69T3FOlCn3k97V44WSq9oqsZpVKEPlD5dOu3Hj6Y=; b=fVPeS3Yf21fBw5YLfkrmMnnz0jHm9I8SlytA53+vU6gq4Lq2fRceKvzxgefOpod78l cgWbybwLbunHJkL3VaHxk5EyOWlrTrVy1X/C7Iur+b4f9V9zommZpuTyeEg2wJ7QHVOM j3aMtcNnwyAQYxbFqIZv1OZYSXGgWGQEXlrYXjMztdf75UCP5w1aWK0t7wUltuM9FCRs ROtIMQqLiJ/f5FxT3qH7USsPyuPalT9a9qFxIjeb4QexLH9etXYFI+ps6eycBztlC0jv 72/EDOl+t6W5MbEafVa8O5/iiwlxP9Yn+tc4cri4yeNA78eK8f30lpp3o63T9DRM4B/1 w0Cw== X-Gm-Message-State: AOAM530eQS1SL4tBC4FlesyY4G7iJplIS5RIp9eUysJJMmVKKshVHUEW JfvAQb77pUcRSgdjdrWESyoRhdb5Uja+DYIPpqUcvIe8 X-Google-Smtp-Source: ABdhPJxVLwn3jaMjIl9ghfMktqFf2yEg9HxOeEdO4K05BxMMjf3OFDQvcYyNAeTbG9jstMflEMRGSldqRrm0OY02HFs= X-Received: by 2002:a62:cd0f:0:b0:447:b8fe:d6c2 with SMTP id o15-20020a62cd0f000000b00447b8fed6c2mr2208475pfg.70.1632955760662; Wed, 29 Sep 2021 15:49:20 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Wed, 29 Sep 2021 15:49:20 -0700 From: Stefan Kangas MIME-Version: 1.0 Date: Wed, 29 Sep 2021 15:49:20 -0700 Message-ID: Subject: xref-find-references blocks Emacs: asynchronous operation? To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=209.85.210.174; envelope-from=stefankangas@gmail.com; helo=mail-pf1-f174.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) Severity: wishlist `xref-find-references' blocks Emacs while searching for matches. This can take a long time to complete in large repositories. It would be nice if it could work asynchronously, like e.g. `M-x rgrep'. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 30 03:44:28 2021 Received: (at 50906) by debbugs.gnu.org; 30 Sep 2021 07:44:28 +0000 Received: from localhost ([127.0.0.1]:51356 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVqk0-00059A-A2 for submit@debbugs.gnu.org; Thu, 30 Sep 2021 03:44:28 -0400 Received: from sonic307-53.consmr.mail.ir2.yahoo.com ([87.248.110.30]:44688) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mVqjx-00058v-Vm for 50906@debbugs.gnu.org; Thu, 30 Sep 2021 03:44:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.es; s=s2048; t=1632987858; bh=dOZbI+rrLscgbrdFs21uswrAGSyydQk40bggavsaFbY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=ZFo1VVLrTsruLSsfHs44EvvAK5+wetyYahTBJXILBOzVdIZDzemiZ9v4XsvquMLzI9Uc7UIWT7p4npSMs+Wqe/yhaphTuq9NxmiZxskmX4ZgOzveBmQcHoNUSKZF5RiDDniV9I1IWyM2UeFiGtM0DiB2e3xtkhgC45CmyfMbDueFtIuSmTsYz44T765p4oswZnYE+1Xu0w65hKVZMOjG2qTh+mZa5kyZqgNbA3BrK8P/1AqCA95ZsaScIQt1CzQbdZyv62fx0KN/C/ZlydHuuJlPHP45RyfnnZx+aEsXt4XcvUcibMTuXI1F+xO+dK8WyyBadQjSFVSRWTxbD3QX8g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1632987858; bh=sxxBupeUvERZXWxiiR8teJDhMZQ+IOx2jaGoFnXR92N=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=Ps4DaZo1QPCYPjCD+IhGM2LuQfzXoTc8sYY9vUAhVcdT5CQpvk3Mmt2W6BeZNC3NKdJkr7BYo8cZP/27G63itPMy2DksvlbTDtJKhoubkdFoYfgmDNvGNCeMK3vdXK6L1R30NmfBEEWHsdrYTFmJP9OjPgjo3saU+XhRCgP4vwSa2OL6MAtLpFC/HM7w5KXpZsbGr0xD5+gSbMshpe3wA74h78tEJwnBm5kLwGYW9ZEMOUML6X7fDq6JL2t1qFwP+bp1DcGHQ3S3WnQGPu+dlWSwX3c9lZZVUf0CdRH5n4/SyIz3MP6dNdSn3y1G1Zi8QZb3MOQSk2e9o/h1qzAj+w== X-YMail-OSG: hIy2aZQVM1mO47pySepTqPhG7Q9PwB3i9sKSvWvkcbVS7RtWDIYtHcRgkgE2f_m swTSW.AiQKsuiCoXHqm790zQ_8.goe30my18g_APNzAwdx4fhGULtabwhmTTMfrjUXdusaIqHa6o LGJpbt187AZNCZWrMzR2Emo1oS0FhZTbmdvGM1jGhF_0GAKUXtKba5XMMkDQRuLs.omoHF2SHSCX lF.6X0fdHMZtgdNWAB1dCW01JKvN8nKqOsxWYGFim28sO5r7zJU_c2t3K2Ai2imVjeNqNLY6Igw6 Thd4qS3D30d1Xz.7xNycFY9vHjnxcv5nPbBN8pzfe2OJTzeLoHydMbygUDGjS6X6.mcvMufdOhqq gIFFWkne_cLU3Lc6oKIzF0UFWXjZ7Vh0y.YPe9WiDzRpUTqO_UBwPEUDt_kbzg6hPG4hYWUC.XSR oeBVvCDSUMEKFrgxfL3K9JdmwZ9nISg7jbuM4sFt9v4NSYWsgR1JRpK7SuT1WLNM6nleYfNlRuQE zX.kmzNzcbOpo_36l3jM.0wlRj89cy1jj4G6HpJWjrbgkF5k1skeS.1AeMS62jMarBzbIzEzZDfG S1rGbzwYf.FmQU_cm__piKZbridnbNYfdMZvwrTd5Jn8JCljDF5HdOTMPvQ681PJYdeOi7qCKA0x AhcIYMFuriRq9YFeaf6Wk51B4PIQnKOtNwzaM9xc2WGiKEW_YC0qtGKDepqIG08b4ervIyHTCl84 cD4B.AQ0yuCn7ksyOVCmo3iV_VFdyagqYpUWcd8liWZIt9..Wb7jV4cN_XhhyWIy0BkRVpRTjF7m .6XjINX8xPWWAXI5ZnEw3FASq5Q1vPB8glVzcgp37mRiDl3KMOIYypzqf.QBlAEycJnohjjLwYe1 HJHbGFjDbOHYD9DRyVkypMaV6R3HKoMmcOgNTm10ImqESfRhuhl.UFTCnXQlMomV5fZoHOxFaocU TYZrf7qgW7isx16iM9dBX94WO4BbaqsJDXHQSSgk9EjuVdKzUFCu.ntHITZksjidiomRQu_v_5Qf cEZbTFJ3q3BVGxcWJdARGHMsn2B2sAw_ZIodZyjjm6DJ2W4nWCbwIPnZKHftCGzNsSc8qTutlnKQ 3RQMkVUOEy9IEL5JvFVI4gqJ6OwVJYACGgqySoOuVU2CMd3qXZkhsXfrWg_2BLB7Zx24PSkvlMK8 0O2N7pgVcPhlqMa.XbEQZbH44anCv.fHqZgwwvnKt4HkiKtGKGoUlQJrIm1Zi0VQonWj5uBUbJX7 thhhVexx578N5E.0w6OOj4ph3uGL8gN4umeLX4H7cv4yaDNPWZMpLqyLrWZ3q4WvpKhyKWhhvS6n _YDRWqqjlZlaSX98AtCMhFixisreILa1olLyDTZSjlVeX.1Xl84FjjY4f0vqXbhFrmJvTLoVbIFs ISmEjHRFE3XDrbu60MvrPSUVSDeOO98MI4Nkzx84fepaP9nBWAHQYOTiHlRhqHa9WoCg1INu1UtT nWDNsR1pC5Ik_eyBUkhbsk4ifmUonm_P0QtMgR51dbuyhSGtMxKcOBxbeH1rX0CJA4enh8xOTpI. XJgKRBTO.78WBMxg86.gBa9QSIxj.HEmkxaajGD0Cidr82nR0gsfPSjbnH6FV58j2QKkyNKjcrhC WKz73On.wrBNaXOFMFNfCDcajWIUvHCYp9mag1bfVBVrouvqjEmJYVU8odBvhN41MmhW03Vr5ueg RoJJtM7gTuBai7kWp6eDcZk9m5MbEa1rXZSpKgT2grIXj2dOIIZRFEJ7nikWG9wdYng_Kn.ioKNW dIeu_V8TXyH2A2aMim8Sxnb67bc_11kx_GSuxBPJpVkOh_ysOO6WMX4e1XKBYoZUgBJw6zFIXuXx ZO8hHQrI._z.iB2LSY668IIBN5OhkYRsHvFrPcGnO23_S3OEgT5Z5n3m9ZKS8GSBVEyoUfTOAKG6 Nx6z6eP.penwwqNBJJw8OvbsXiGxKZuq5VJ_3lvg_6Vs_GwZwa_TR_GJtNsuldCsBOG8hvha5iJp 7DasP3A_C_BUAwF.r.RLmw42QSuX062wz9i.nKdq2HUZ.2BlCS3rtwZh94FZw7WBlRJin8olPU8g 1BW0Kxl.MDzZChIlPHroJF0uN2gufvFx5vgiueE.C1X6d5x0hh2PrtjsqDf8LscR5rdWwa3wavGH DI1amkqRY6Pv7308Dex_KbXCYmScVsgXvKytt0omNJGDS.UkR7YWIsAoQJ5E_7rSq6bH_WQRQ3Kh oOEWTTrrB4f7nZTUz_9Db1CT3in3q3LJYraXR6A6R98vuVCdAtpijxC7d2NFS X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ir2.yahoo.com with HTTP; Thu, 30 Sep 2021 07:44:18 +0000 Received: by kubenode511.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 36083418e4708861f558d4b702bdb30e; Thu, 30 Sep 2021 07:44:14 +0000 (UTC) From: =?utf-8?Q?Daniel_Mart=C3=ADn?= To: Stefan Kangas Subject: Re: bug#50906: xref-find-references blocks Emacs: asynchronous operation? References: Date: Thu, 30 Sep 2021 09:44:12 +0200 In-Reply-To: (Stefan Kangas's message of "Wed, 29 Sep 2021 15:49:20 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.19076 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 355 X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 50906 Cc: 50906@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Stefan Kangas writes: > Severity: wishlist > > `xref-find-references' blocks Emacs while searching for matches. > This can take a long time to complete in large repositories. > > It would be nice if it could work asynchronously, like e.g. `M-x rgrep'. Here's a related bug report: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50733 From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 04 21:59:42 2021 Received: (at 50906) by debbugs.gnu.org; 5 Oct 2021 01:59:42 +0000 Received: from localhost ([127.0.0.1]:38642 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXZk5-00028m-Q8 for submit@debbugs.gnu.org; Mon, 04 Oct 2021 21:59:42 -0400 Received: from mail-lf1-f48.google.com ([209.85.167.48]:45760) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXZk1-00028U-3X for 50906@debbugs.gnu.org; Mon, 04 Oct 2021 21:59:40 -0400 Received: by mail-lf1-f48.google.com with SMTP id u18so79605605lfd.12 for <50906@debbugs.gnu.org>; Mon, 04 Oct 2021 18:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=mt6HaHXoSsmAJpYojQCPUp9Cdb8jWxl3U4V78jjLYEU=; b=a/AmTNxo5aFZ+ZfClRMvs59uHVPPqyIYKu24VHpocCEJxYLI62KtDt0obEwU9VaQK5 cRAkwt0PXwdttUVtQDE6okQAalK8CLoRtXSFkwLslxOhE+MIvX0K3d9MN46jj2EYfSHN OU9D1Z22ycyCdThhbMxBIqgjZfdXwbxFh5TpZmmkg+cjCXIXeuYDK0kRUIHD3lFjDqYP lOfBD84wwJDn61EcM7Nb+wD9dYcldIX7L+0Ejm5DbKzMaI9ySP3vbJgiQxFhXQdfzODi QwB7zjy/uSxBvvEJAbnJQ4j/5nbxhchrNsHY2PafCo2cqbxf7WJYUIIoWWYUQoTlI7PP m+nA== 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:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mt6HaHXoSsmAJpYojQCPUp9Cdb8jWxl3U4V78jjLYEU=; b=SHwlZ1ODXFez66oVyiaEFEeYQ74eT1BV7kLjZGMB+x9yLxXnwTgi5eEFKwQYqPRmOb BmiAzOGA/ICPRkYxKmaswWM+FhiKWfyBFcKTzOPeQ7CO37KSD2MFrLUO342FgTh8R4Ti tHxbVVLOFy6ktoFOhJl6sKkDLCfGyxfYnAI30i1dFvaZQEuKmfrWg6cd0oY7DQK3FkdD td6Hy2/qFSJl/EW15dLyM1PGEkTmy/ij54ksCAhkxDXpBeJpPPEe8dqMpMLuedCZ6df+ b4NauPb0Pzyg0etQrLR+wToAkr3+Q3YVgmPCoLuYFNtM/Oi41QhTjpyfOieiT04vKDpF 5vbw== X-Gm-Message-State: AOAM532iKL8OtVJWvP56YucvVj+HjryIiXkD1OBVI8PK9I1xJpgVBwGT IRTqKOjo2O5amjwHWjJ1ruO7XEZR30I= X-Google-Smtp-Source: ABdhPJzA96bGMu8vonOZIrhZfQ4b5EP5wnVMVkIz5IGVO4MErjRhzQw8HvEP3XrwIZioI/u88IUdkQ== X-Received: by 2002:a2e:a4cb:: with SMTP id p11mr18740750ljm.138.1633399170841; Mon, 04 Oct 2021 18:59:30 -0700 (PDT) Received: from [192.168.1.113] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id o1sm1926674lfc.110.2021.10.04.18.59.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Oct 2021 18:59:30 -0700 (PDT) Subject: Re: bug#50906: xref-find-references blocks Emacs: asynchronous operation? To: Stefan Kangas , 50906@debbugs.gnu.org References: From: Dmitry Gutov Message-ID: <152761c7-d793-2fa5-430f-d018c4957f89@yandex.ru> Date: Tue, 5 Oct 2021 04:59:29 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 1.9 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 30.09.2021 01:49, Stefan Kangas wrote: > Severity: wishlist > > `xref-find-references' blocks Emacs while searching for matches. > This can take a long time to complete in large repositories. > > I [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.167.48 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.167.48 listed in list.dnswl.org] 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.1 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 50906 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.9 (/) On 30.09.2021 01:49, Stefan Kangas wrote: > Severity: wishlist > > `xref-find-references' blocks Emacs while searching for matches. > This can take a long time to complete in large repositories. > > It would be nice if it could work asynchronously, like e.g. `M-x rgrep'. Wishlist indeed! Daniel's bug report shows a good case for this kind of feature: huge projects where the search, even using fast tools (e.g. ripgrep), takes multiple seconds. So if results of such searches could be displayed incrementally, it would improve the perceive speed and usability. 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. 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? - 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. Given all of the above, I've been putting off this work, but thoughts and opinions welcome, and POC patches -- doubly so. From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 05 01:18:32 2021 Received: (at 50906) by debbugs.gnu.org; 5 Oct 2021 05:18:32 +0000 Received: from localhost ([127.0.0.1]:38798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXcqW-00076s-Fn for submit@debbugs.gnu.org; Tue, 05 Oct 2021 01:18:32 -0400 Received: from mail-oln040092069013.outbound.protection.outlook.com ([40.92.69.13]:20486 helo=EUR02-VE1-obe.outbound.protection.outlook.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXcqR-00076c-Ut for 50906@debbugs.gnu.org; Tue, 05 Oct 2021 01:18:31 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z9PYzjVlQ4gv5/+0ZI+/5c4s7zcMP8KdjcuTXTFmnlciAK1OPyjW+DFPE0oF6lHmkc2Uun47QBka6f6RAf13qSLVW1aF0WM9lEvxm8saiP37zadGo+au1rd5pKAtbPXce5/+HxSwspnt5alWo+ws1NJsRPRkSlheO6yN3Jz3LZT3kNY5FOaap4Bo6IijYdh0ikgldj9DDHTkJx6b3sibXz4y27qutw6yxC8Yf4NmbwZxjJACJPR6RbG7AevgdgTSNMmdoCHWOPxTYC0OwlcHAmAYu9NrpG7wdw1o47Xz+Joiq/UnlG3eiAyBZ7Y1v/Ppp+BejGwcTdza17Wya3W9nA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xtboF4GCv9E4T3ZVYnd7lrW1n7uHEvWqL3JE3he/2RM=; b=NxukbCZQDCDC+q2ZKoUeaxPST6yOzFqmuQl7Vq/PLK48oxF9mKI5itYl8KhIZCccWg5GuVJE7j86Fp0lGWApdo3MWrQnebYqmFoY0s9DdEf6U/glhefyncr16AvoeehFQd6qf+j5Wa1drAoxF2iycr/KBFZeFCi7wyWl3+GxE/wYHvAg+cESiAm46iwRsMqrx5atbmpfeFj8lLiBq5m0bjxQQxOvI6N/EDQemUCfndSTCQ/eUbulFR9UYMGnYzW9FXGMtix58reP5jPvfHc+sdeOiNcNlrFgIPBjIYj8yUWUUrr1Zyvp3vPxoRGsGy9Uqjr7OOpeJ+aAQ1A+8OJ78Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xtboF4GCv9E4T3ZVYnd7lrW1n7uHEvWqL3JE3he/2RM=; b=SfVH1787DAoLiIYupY6CJdmSSGKqFzt8pHHlhe0szJVqJWp68iHpQtFFldH18D9S12Rpg1HhTMd3qb4GueYUUugjHU1Zpu/zFIYKuRj5rVEsBifhTS3GnRP1rNtmP5kp4/V8Ty4MO8eyLFRfjkcHto4o8yNIQDrnFMDfFNzsZiS4wXyQc2LFkltHlOel85xttgShf/+FgGs7CfK+eO/7X/BL0oGQeIEmyHRD0Csf1F3+f3ZGvKdgbGbHh7vfvqWLwITNLUBqGGLpykZi45ZyIGXh60x/bbA1WxsnryFiAprN77m7+RyoAb2ZVKAiN/ESxxZY7LrqC6mJARYuwFg3Lg== Received: from AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) by AM9PR09MB5011.eurprd09.prod.outlook.com (2603:10a6:20b:30d::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.15; Tue, 5 Oct 2021 05:18:20 +0000 Received: from AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::c05b:e2ca:5b8a:56d2]) by AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::c05b:e2ca:5b8a:56d2%9]) with mapi id 15.20.4566.022; Tue, 5 Oct 2021 05:18:20 +0000 From: Arthur Miller To: Dmitry Gutov Subject: Re: bug#50906: xref-find-references blocks Emacs: asynchronous operation? References: <152761c7-d793-2fa5-430f-d018c4957f89@yandex.ru> Date: Tue, 05 Oct 2021 07:18:18 +0200 In-Reply-To: <152761c7-d793-2fa5-430f-d018c4957f89@yandex.ru> (Dmitry Gutov's message of "Tue, 5 Oct 2021 04:59:29 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-TMN: [3g4EGBDudTghFc5kuldAG0le+GoNRdpz] X-ClientProxiedBy: HE1PR02CA0091.eurprd02.prod.outlook.com (2603:10a6:7:29::20) To AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) X-Microsoft-Original-Message-ID: <87mtnouk11.fsf@live.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from pascal.homepc (81.232.177.30) by HE1PR02CA0091.eurprd02.prod.outlook.com (2603:10a6:7:29::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.15 via Frontend Transport; Tue, 5 Oct 2021 05:18:20 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3d622e21-5819-4f58-397e-08d987bf8bbe X-MS-TrafficTypeDiagnostic: AM9PR09MB5011: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: EN51Ogm8+U7gNAk3gpMRN6fUAaBvRl960pNR/e4jSPtRbC8uENXyqzho338fR14JGxs5q3BYFm8SQlRXAdf81KgGF/ANFjPd/L9hrG0rc9/mgW1V8BLp9xN53g/JtB8vBsIvMv2Qwoyl+GcOWghV2OBC3lmHxOLec3DWmi+XfXo/76GtI6IBLocvsARUvJVPvo38qRBJ/BOCuH+RrePE0KpMdk3atXBbIHR32xltyLYS3xyJVIydXlU/nEiXN4GsAK/QBY0kZMAuGC9cdXx2Z4F8Ue3Is5GrYMKXeh75m7R9YxOS55AchT+LBD2G37IQOfg8EU4vzDL2Jx6UAC9gRTnPSD1trv5sSEk7ffipTGaYEVYuhIeCY/x3tPusPWsDlfImvov5jWvY9TC+uc2eeq58LLWHVBTSGEOUgdxE06nRcYfdbHhZfFTgarBf9WLX X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Z6/rj7v+VI921G/fYhbNuHmUQQgFZmVmc36NQOX/86Jzrhvvn0RSjrUKGxd527AfLEkBydd027hZNSf5YY3+TjCWIoSYCeN6OynumTpNMCTYUSx6p+UUo0ktKvCtwGfg+PwFITNlvxfPUWjNW6kX7Q== X-OriginatorOrg: sct-15-20-3174-20-msonline-outlook-72e6e.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 3d622e21-5819-4f58-397e-08d987bf8bbe X-MS-Exchange-CrossTenant-AuthSource: AM9PR09MB4977.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2021 05:18:20.7119 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR09MB5011 X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Dmitry Gutov writes: > On 30.09.2021 01:49, Stefan Kangas wrote: >> Severity: wishlist >> `xref-find-references' blocks Emacs while searching for matches. >> This can take a long time to complete in large repositories. >> [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [40.92.69.13 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [40.92.69.13 listed in wl.mailspike.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (arthur.miller[at]live.com) 0.0 T_SPF_TEMPERROR SPF: test of record failed (temperror) -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.0 MSGID_FROM_MTA_HEADER Message-Id was added by a relay 1.3 FORGED_SPF_HELO No description available. X-Debbugs-Envelope-To: 50906 Cc: Stefan Kangas , 50906@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > On 30.09.2021 01:49, Stefan Kangas wrote: >> Severity: wishlist >> `xref-find-references' blocks Emacs while searching for matches. >> This can take a long time to complete in large repositories. >> It would be nice if it could work asynchronously, like e.g. `M-x rgrep'. > > Wishlist indeed! > > Daniel's bug report shows a good case for this kind of feature: huge proj= ects > where the search, even using fast tools (e.g. ripgrep), takes multiple > seconds. So if results of such searches could be displayed incrementally,= it > would improve the perceive speed and usability. > > 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 resu= lts), > but ideally it would look synchronous somehow, and the concurrency woul= d be > achieved through the use of threads. Not sure if that's realistic. Built-in threads are not realistic, what you probably want is async process= es. I was myself thinking of something for finding all references for implementin= g this asynchronosly for help, in style of , but I have not yet come to imple= ment that. However I have looked at native comp, 'comp-run-async-workers' and ho= w it processes it's qeue. I have no idea if it can be somehow adapted/reused, bu= t something like that at least as an idea. > - The new kind of fetcher would need to provide a way to abort the search= , since > 'C-g' would not be available anymore. It depends on how you would use it. If you would scan for references in the background than you would be working with something else and wouldn't need C-g. But reading your writing, something tells me that you would like to us= e it interactively, which means you would start a *synchronous* operation, which would use async workers, a l=C3=A1 Java's or MFC's thread workers to get re= sponsive and visible updates in real-time, while workers are still searching. In tha= t case you would still have C-g avaialable. On C-g you could signal worker processes to quit. Perhaps ...? :) From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 05 02:29:33 2021 Received: (at submit) by debbugs.gnu.org; 5 Oct 2021 06:29:33 +0000 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 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 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 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 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/ To: bug-gnu-emacs@gnu.org From: Helmut Eller Subject: Re: 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 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cancel-Lock: sha1:rD3sAER0vtY6bHOoIQPr46Qw6OM= 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-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.9 (/) 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 05 11:12:20 2021 Received: (at 50906) by debbugs.gnu.org; 5 Oct 2021 15:12:20 +0000 Received: from localhost ([127.0.0.1]:41624 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXm79-0005lj-Ne for submit@debbugs.gnu.org; Tue, 05 Oct 2021 11:12:19 -0400 Received: from mail-lf1-f46.google.com ([209.85.167.46]:47025) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXm78-0005lX-CO for 50906@debbugs.gnu.org; Tue, 05 Oct 2021 11:12:18 -0400 Received: by mail-lf1-f46.google.com with SMTP id i24so37714305lfj.13 for <50906@debbugs.gnu.org>; Tue, 05 Oct 2021 08:12:18 -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=cF+wtJuza49LiVe284ERrqe2hI8+Dlxu1P7l/8qbQf4=; b=ENfybQ+mIfv+wWDK7WHTJZkpNsLLKb1VNeMusRYr1RwxUm8gP4Sa6YX6dsc2tJiSck RDhOEI1YgNEYA4VrUns3yZDKgKAecxdkAFI+OfirRY8I9Pk/Hxx5oxZSadnetLZznmgl mWyzVNS4aPndKQOlxQjRe2nzU5OIro1ruxQmocpndKkp0Hc8r3jiMXXzKvMILo1gzP4e 8OYFPrwx3C8b3gtVATFkzFE+kZoy4pQfwX7uNDnfmcneHANTdKBEsl0CMakZYz/noTJH f1hvGPqm86MvNrObNcdXRNJWuao7Q78vI7Y5+pWqa+7HSwMm0QOUTNY8HdbqiVm//0lj TVlw== 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=cF+wtJuza49LiVe284ERrqe2hI8+Dlxu1P7l/8qbQf4=; b=fWqHXP+qGbvM+v3jCJ4NC9xCMbaVAjpeK8EhNh+JVcNlOkyzHXH/0WYXuMTdEvFYHt KsDMzHxlSLzoy/HJ436EUvlnDiYQQnRIKpqZxwAaRUv5MTQXyqTkTchPVUr2ysEDGNuG 0nwMm5OBwDjj5H0amBPLVeZ8P31UDXCSk/SsGEIEqDfXPIzL3DbGXD0/zAUl7EFb3dgV alePBU0ql9uJezF173MgQLes3g7btCizdZ3Bj70lZQ22B9WBKldO/6U4cDBeB7zvGFR/ kwAlW8DeDrbXpILSc8j1m3AtmSt7DReprndKlIlv0eJv0cUVC54qPIfPcZbDJYwa0bOY nPtw== X-Gm-Message-State: AOAM533IFEtqCc3mX0RMYmxz5lHO8V9jh5dj0AGqsFQ3FjVifCsUvxDK T98RhFZfelq8mZUGeziltvI0b+KlspQ= X-Google-Smtp-Source: ABdhPJxu8TjOtUvkmokzj0fXXftoknAVwWYZ9/erQ9CqQ7c1JF4iJXyv0Ei3lGx+qT+eAbW6OfxDhg== X-Received: by 2002:a2e:bd02:: with SMTP id n2mr19195727ljq.40.1633446700977; Tue, 05 Oct 2021 08:11:40 -0700 (PDT) Received: from [192.168.1.113] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id o9sm2186936ljh.9.2021.10.05.08.11.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Oct 2021 08:11:40 -0700 (PDT) Subject: Re: bug#50906: xref-find-references blocks Emacs: asynchronous operation? To: Arthur Miller References: <152761c7-d793-2fa5-430f-d018c4957f89@yandex.ru> From: Dmitry Gutov Message-ID: Date: Tue, 5 Oct 2021 18:11:40 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 1.9 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 05.10.2021 08:18, Arthur Miller 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 sim [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.167.46 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.167.46 listed in wl.mailspike.net] 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.1 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 50906 Cc: Stefan Kangas , 50906@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.9 (/) On 05.10.2021 08:18, Arthur Miller 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. > > Built-in threads are not realistic, what you probably want is async processes. Why not? It should be possible with cooperative multithreading (which we have), at least in theory. Under the hood it would be based on async processes, of course. > I > was myself thinking of something for finding all references for implementing > this asynchronosly for help, in style of , but I have not yet come to implement > that. However I have looked at native comp, 'comp-run-async-workers' and how it > processes it's qeue. I have no idea if it can be somehow adapted/reused, but > something like that at least as an idea. Doesn't seem like it really can be reused directly: it launches a queue of processes. What we would need is a "queue" of result batches coming from one process. And we'd need some abstraction for it, not just concrete implementation. >> - The new kind of fetcher would need to provide a way to abort the search, since >> 'C-g' would not be available anymore. > It depends on how you would use it. If you would scan for references in the > background than you would be working with something else and wouldn't need > C-g. Why not? Sometimes the regexp I have typed is wrong (too short, for example), and I need to stop the search to correct it. Or even if the regexp was right, I might discover it brings too many matches to be useful. > But reading your writing, something tells me that you would like to use it > interactively, which means you would start a *synchronous* operation, which > would use async workers, a lá Java's or MFC's thread workers to get responsive > and visible updates in real-time, while workers are still searching. In that > case you would still have C-g avaialable. On C-g you could signal worker > processes to quit. It's... an option too. And having lives with the current UI, I would probably be fine with it. But I suppose a lot of users might want to be able to interact with the first results (that have been already rendered) before the search completes. Otherwise we're not really taking full advantage of asynchronous searching. From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 05 12:38:49 2021 Received: (at 50906) by debbugs.gnu.org; 5 Oct 2021 16:38:49 +0000 Received: from localhost ([127.0.0.1]:41720 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXnSq-0001ie-Qz for submit@debbugs.gnu.org; Tue, 05 Oct 2021 12:38:49 -0400 Received: from mail-lf1-f42.google.com ([209.85.167.42]:42517) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXnSl-0001iN-Fj for 50906@debbugs.gnu.org; Tue, 05 Oct 2021 12:38:47 -0400 Received: by mail-lf1-f42.google.com with SMTP id x27so88022433lfa.9 for <50906@debbugs.gnu.org>; Tue, 05 Oct 2021 09:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4EeJH8oEsUmBkB+eArpX8ZKHG3a4Ek8cKCfgmqfZ2R0=; b=IwcrKUtxnWkVemA/8wIuBZP4pLf7CJu+cY/4Xv5ZY++r6GRdx3yG6zb6L4QgasAZ0A ojxhaBeu6TaPDfL0s+ML6i0Z7h5UozBJUtMLjuJAWFa9RzRPL1OKQ0aYxNMkBtlqGy+V tg//ss84WNgECgNe8/4Dst4m0WMnXD3ipjV31iO0s6npdrAsGHfb4aJ2e65h5OfgtacN E9IflS14Q4S3uzlBgt/YtGPP11uaBR9F/SxbMoQmAy8b5KLVyib5/IrnDaclJiFespdK XK0hfB3gjSJAX2iXDyArV8EjlGU6RaVK34E07Bixfhfi3JzZStLl+4+ruY+WdL9qOjAW 3N3g== 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:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4EeJH8oEsUmBkB+eArpX8ZKHG3a4Ek8cKCfgmqfZ2R0=; b=d7miYpiK6KvZOS1M1UPnt2pIqJp+Jk1EtmdTbZ3kLoQf8JpbxKT88473wCFEmmSir7 2IEVt+tLQogTXNnmvBCbfg5KPvhPksAQ6NmqVK3T+2XfWF8gafumu+yb2Utmml12iGQx KPVXMowjwRzwePOPamFSZuNZHbdoHj8kbI54O647r5ByffjihbWT9rTrZbtYONzj61sJ aa374IWmDBfmenqOJbVSzMSXEPvNx3IfinZDecU2hnoYzHKrmGiB0RuiCsm4nxL2FiEi ugOljZDpHGq7F3JiVC2wMCIFrZTzFxDT5CJ3U4Go1JISbVomQGkJfxAEFqug4N2SAcNX SRYw== X-Gm-Message-State: AOAM530uP4nFhECpY7BjfZIPJdz4+NSSFZAVOINDL6Y0/dsIrQcMcBvK fQWykgtWPIB2h59zW5k7iRYyrSBvWm0= X-Google-Smtp-Source: ABdhPJzwQuwok11naOWCbwdS5KUaZRjGNdlx7WZfH/ZgyJhU8REGYZ5o4zUho/c+RBOUMzGVAsks+A== X-Received: by 2002:a05:6512:6d2:: with SMTP id u18mr4373841lff.453.1633451917365; Tue, 05 Oct 2021 09:38:37 -0700 (PDT) Received: from [192.168.1.113] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id e28sm2159562ljo.63.2021.10.05.09.38.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Oct 2021 09:38:36 -0700 (PDT) Subject: Re: bug#50906: xref-find-references blocks Emacs: asynchronous operation? To: Helmut Eller , 50906@debbugs.gnu.org References: <152761c7-d793-2fa5-430f-d018c4957f89@yandex.ru> From: Dmitry Gutov Message-ID: <6f2c07d4-3e29-44c0-bb7f-c37905b3e12b@yandex.ru> Date: Tue, 5 Oct 2021 19:38:36 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 1.9 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 05.10.2021 09:29, Helmut Eller wrote: > On Tue, Oct 05 2021, Dmitry Gutov wrote: > >> What can be done here: >> >> - Design an "asynchronous" format for xref-show-xrefs-function to >> consume. FETC [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.167.42 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.167.42 listed in list.dnswl.org] 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.1 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 50906 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.9 (/) On 05.10.2021 09:29, Helmut Eller wrote: > 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. A promise is something that resolves once. We could build on top of this concept, but what's really needed is some sort of a lazy sequence (Clojure-style), or a sequence of chunks. >> 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. It would need be accessible by the code handling the "abort" command, not just by some special UI accessible to the user separately. But some Promise/Future implementations include the "abort" functionality, so it can work together. >> - 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? For xref-find-references in particular, you can build an index using 'ID Utils' already, and the search will be fast. The downside is you will need to update this index manually when the project changes. E.g. when you switch to a different repository branch. And the ripgrep devs are working on something similar: https://github.com/BurntSushi/ripgrep/issues/1497 Not sure how far off in the future that is, though. A really fast searcher solves the biggest part of the problem, but we'd still be left with very imprecise searches (many matches) locking up Emacs for seconds, since the Lisp overhead processing a match is unavoidably larger than the time it takes for a search program to print it. Using lazy sequences could allow us some leeway as well -- namely, processing only the first N hits initially, and then processing the rest only if the user requests that. If we only target this kind of improvement, the "abort" functionality could wait. We'd still need to choose between sorting the results and saving on parsing the output buffer eagerly, though. From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 05 14:09:53 2021 Received: (at 50906) by debbugs.gnu.org; 5 Oct 2021 18:09:53 +0000 Received: from localhost ([127.0.0.1]:41877 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXosy-0006QO-Qn for submit@debbugs.gnu.org; Tue, 05 Oct 2021 14:09:53 -0400 Received: from mail-ed1-f51.google.com ([209.85.208.51]:35786) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXosx-0006QA-4V for 50906@debbugs.gnu.org; Tue, 05 Oct 2021 14:09:52 -0400 Received: by mail-ed1-f51.google.com with SMTP id b8so115354edk.2 for <50906@debbugs.gnu.org>; Tue, 05 Oct 2021 11:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=B+d5spbBhOU7kmz3I5xB31ooRO/ti35Bk4tuPufjCHI=; b=ipxo0IHQ6zsOSCOn2hVNmPN/UNBsDHVYtjk8mIwfWWXjFgWcQ7fTiFuI4Ev5tIYKdr GkqHPzc19JwAgxxhD9omKKLVeV8L1TI3K7SDK17xQMgNpo9Ft5hC4YW34DdC27R9usuN 6dWQb8FfqEzJNdcNR7bkQ1mW/n2LRM+Rsnnv3S4dpBCWop1zUehQahpPzIg0Sgu6mgO9 EY/rP8pzId7Ddenj5RBV7OaXM1UpWralNFdzWjKGX1PqwcdAXQRZIsrpFmXfNFPaTUnS aq4eDsJT7i8zUAvYZivmDIdTF5BjNpOvkLq7CRSbv4qeiSfH/qoOLBPB4nAHbmqFABAv dn4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=B+d5spbBhOU7kmz3I5xB31ooRO/ti35Bk4tuPufjCHI=; b=0oUqtWd3H5KuAyppa18baAZKd2rUgBGq0aX+yHUyO87MfcRbIe7E/ECmdij1tF0nPh N6HP03mGBblu0Hht7/XJ1Y8jCGP9EtzTUjLh2cu8rmT9SshwtVi7Q6vAVPKlQKnKrm2U 2HYL3Uy+jWlnCBhVtQK7Rl6ZO9yntOZWbjThQTaziorDGvb38Vs9aYWd/PmpwWvuG40R inYHQvW2v+X20Ia2OjvaENmSF+pNEoXikQvbah3meTayl6yZEF1bXeua+utkvuDRewIP 6nqsL2xjRw4YaA5Gs8l8AbNlxe0yqcc1TG1C+D7INFghHuI3zK5zSzzem2WWjDZm7LuL enFA== X-Gm-Message-State: AOAM530Lxr6/hzOxWbfy5pN9STFxiYuvnngMXMzRcYuI1W0pvPzz0hDQ OBFDxxKaRrhJ+Dz0P6viV2Qc4zXJZxE= X-Google-Smtp-Source: ABdhPJy2goXpcOVyv/E+RTSji7r5AYq2mr6NwkhPo5aVkwwjmBaodHO6OovoKwIiNRBK7jeOl0UmrA== X-Received: by 2002:a17:907:2bec:: with SMTP id gv44mr15672020ejc.523.1633457385245; Tue, 05 Oct 2021 11:09:45 -0700 (PDT) Received: from caladan (dial-185031.pool.broadband44.net. [212.46.185.31]) by smtp.gmail.com with ESMTPSA id ca4sm8095957ejb.1.2021.10.05.11.09.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Oct 2021 11:09:44 -0700 (PDT) From: Helmut Eller To: Dmitry Gutov Subject: Re: bug#50906: xref-find-references blocks Emacs: asynchronous operation? References: <152761c7-d793-2fa5-430f-d018c4957f89@yandex.ru> <6f2c07d4-3e29-44c0-bb7f-c37905b3e12b@yandex.ru> Date: Tue, 05 Oct 2021 20:09:43 +0200 In-Reply-To: <6f2c07d4-3e29-44c0-bb7f-c37905b3e12b@yandex.ru> (Dmitry Gutov's message of "Tue, 5 Oct 2021 19:38:36 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50906 Cc: 50906@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Tue, Oct 05 2021, Dmitry Gutov wrote: > A really fast searcher solves the biggest part of the problem, but > we'd still be left with very imprecise searches (many matches) locking > up Emacs for seconds, since the Lisp overhead processing a match is > unavoidably larger than the time it takes for a search program to > print it. Using lazy sequences could allow us some leeway as well -- > namely, processing only the first N hits initially, and then > processing the rest only if the user requests that. > > If we only target this kind of improvement, the "abort" functionality > could wait. Yes, limiting the time that Emacs is locked up, by limiting the number of hits that Emacs accepts in one chunk, seems like the way to go. > We'd still need to choose between sorting the results and > saving on parsing the output buffer eagerly, though. Theoretically it should be possible to sort the first chunk and display it. Then, when the next chunk arrives, merge it in, =C3=A0 la heap-sort, a= nd update the display accordingly. Probably not worth the effort, though. Also, I think that the only "sorting" that we actually do, is grouping by filename. And that doesn't seem all that important to me. Helmut From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 05 15:24:38 2021 Received: (at 50906) by debbugs.gnu.org; 5 Oct 2021 19:24:38 +0000 Received: from localhost ([127.0.0.1]:41932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXq3K-0008Nr-3M for submit@debbugs.gnu.org; Tue, 05 Oct 2021 15:24:38 -0400 Received: from mail-lf1-f52.google.com ([209.85.167.52]:46686) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mXq3F-0008NX-S2 for 50906@debbugs.gnu.org; Tue, 05 Oct 2021 15:24:37 -0400 Received: by mail-lf1-f52.google.com with SMTP id i24so200341lfj.13 for <50906@debbugs.gnu.org>; Tue, 05 Oct 2021 12:24:33 -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=N56wcENHChx7DQZgbymhV3DhxUNXypx8d7kpG+bUObk=; b=WSk0oKvITv1dXPWtQeDZWBPJ8oM+QOcTyglAAh8yEpGGT9e1MUmALrVzeFoEzmyNum EBNgEyWiGLcHmWJchBnQQ4nXTcOTRmaynFyU53ueq3Qx/nMImxWLr3mhd3lQj+QIx3jT kpyMlw0lA8tAsOdJfNNtxeIQ1cmEMP0wgt+BhhafiHRbjffPVmZB8UTdnQK65gb2nvUQ kdLenIuNYx0QGHGFv8/ef7TFqHDuDK0+CGlyUdZthn4/t5G2MYpsmNMjaJgbhax4XGPM Id5ukf0f6lBaq/VNyj1lW5AvdDkHgq6gqjSUghR4E/oE8HSa2k9fe5ZDVvSafrfWUsKs UODA== 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=N56wcENHChx7DQZgbymhV3DhxUNXypx8d7kpG+bUObk=; b=iPhtUdfrpbQxKCuJekvzXlLWidCFcZ+aeej+X9hzjJQfbf3ROesfYHghCYdZicjVDd bcq1CIqsVFbe7/0O7kIMPZ1T71kwWL9/Y4rdsQQj+fXfM95XmcIsCGwHTg7E+N/IlWqY EXoOF8hklRIp8oDWk0ya0zb/nnw+mlJt0MEdt4fAZ54+s6YacrLfrleZoxavAs11LD1K DpN6Bn6WiT4FZkRSk6Z+nJQ0CoQo/ahaODTmyJ0NHzZrbCBcg7P/ztFnwY14m1QLBcXm d/Ix+k6VwKprLch3Luja5ib1ajOX1oM7UYOLZM+ExpAdMwEtSdzqwacoWsF6Q26I5d6b dtQg== X-Gm-Message-State: AOAM530hNiI54CwF0vaAgXe4cHFaG7zK8NsvtNjE769NP0WAAIb/IGse 1OtmzqJP1lj2IFEOK9LXA7vMrUWe96A= X-Google-Smtp-Source: ABdhPJwiu5Yo2vTulTOgPQIgkje/NoXkVY7ZvZnHFff53CtJLxtMo+68JOYFI5C0V2tirsd/1yPGBQ== X-Received: by 2002:a2e:5059:: with SMTP id v25mr23609701ljd.128.1633461867858; Tue, 05 Oct 2021 12:24:27 -0700 (PDT) Received: from [192.168.1.113] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id v28sm778569lfq.146.2021.10.05.12.24.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Oct 2021 12:24:27 -0700 (PDT) Subject: Re: bug#50906: xref-find-references blocks Emacs: asynchronous operation? To: Helmut Eller References: <152761c7-d793-2fa5-430f-d018c4957f89@yandex.ru> <6f2c07d4-3e29-44c0-bb7f-c37905b3e12b@yandex.ru> From: Dmitry Gutov Message-ID: <4b5b83c7-132d-c260-d42a-184f40f4e230@yandex.ru> Date: Tue, 5 Oct 2021 22:24:26 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 1.9 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 05.10.2021 21:09, Helmut Eller wrote: >> We'd still need to choose between sorting the results and >> saving on parsing the output buffer eagerly, though. > > Theoretically it should be possible to sort the first chunk and display > it. T [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.167.52 listed in list.dnswl.org] 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [178.252.127.239 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.167.52 listed in wl.mailspike.net] 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -0.1 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 50906 Cc: 50906@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.9 (/) On 05.10.2021 21:09, Helmut Eller wrote: >> We'd still need to choose between sorting the results and >> saving on parsing the output buffer eagerly, though. > > Theoretically it should be possible to sort the first chunk and display > it. Then, when the next chunk arrives, merge it in, à la heap-sort, and > update the display accordingly. Probably not worth the effort, though. This will lead to "jumping" of groups up and down. Not a pleasant UX. > Also, I think that the only "sorting" that we actually do, is grouping > by filename. And that doesn't seem all that important to me. xref-matches-in-files sorts results by filename alphabetically, because ripgrep returns them in random order every time. And the sorting step is pretty fast, as long as all results are available.