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#47711: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Date: Fri, 27 Oct 2023 16:29:03 +0300 Message-ID: <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@gutov.dev> References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@yandex.ru> <83fsvcbio7.fsf@gnu.org> <9f432d18-e70f-54c1-0173-1899fb66d176@gutov.dev> <877cnafv39.fsf@gmail.com> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@gutov.dev> <7d14bc13-4419-816c-5708-c42988c39c02@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21965"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: Daniel Mendler , Eli Zaretskii , Stefan Monnier , 47711@debbugs.gnu.org To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Oct 27 15:29:56 2023 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 1qwMuR-0005Ud-Vc for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 27 Oct 2023 15:29:56 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qwMuD-0000WG-DB; Fri, 27 Oct 2023 09:29:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qwMu3-0000Vm-4i for bug-gnu-emacs@gnu.org; Fri, 27 Oct 2023 09:29:31 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qwMu2-00042U-TA for bug-gnu-emacs@gnu.org; Fri, 27 Oct 2023 09:29:30 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qwMuY-00049o-64 for bug-gnu-emacs@gnu.org; Fri, 27 Oct 2023 09:30: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, 27 Oct 2023 13:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47711 X-GNU-PR-Package: emacs Original-Received: via spool by 47711-submit@debbugs.gnu.org id=B47711.169841338715937 (code B ref 47711); Fri, 27 Oct 2023 13:30:02 +0000 Original-Received: (at 47711) by debbugs.gnu.org; 27 Oct 2023 13:29:47 +0000 Original-Received: from localhost ([127.0.0.1]:35354 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qwMuI-00048y-FD for submit@debbugs.gnu.org; Fri, 27 Oct 2023 09:29:46 -0400 Original-Received: from out1-smtp.messagingengine.com ([66.111.4.25]:37515) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qwMuG-00048l-3O for 47711@debbugs.gnu.org; Fri, 27 Oct 2023 09:29:45 -0400 Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 8DA035C02AC; Fri, 27 Oct 2023 09:29:07 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Fri, 27 Oct 2023 09:29:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1698413347; x=1698499747; bh=brwrI4QaL3SGWYyBRFVHYn/JWAkiXtjc+Ya 7W3+C3MQ=; b=AjRmErAqMC7Rd0w5VARjNkN9CXreeYxzV6g72oDM9Aiy1GydhVI 6/8NM2vFFr7b2EoiGy8RMxY8Etu/laUhh8Hq289wquhIeby+tbVKRTDZ6QPs1/jm fhjaAuCUSZKi6Pu8e76O5iSlWrk+e+Mv+WOs+cuTXRr0WZF/ZMMybVXallVNfBc7 41alfvfmLjQwIddAVVIwTZ6rQcZWu3j7vGRGsXXsLOWoHBGyVuAo3xMW5lQMDDDY Hx1wNCxawKRURmLyE/YthxdKenyUhYYE0v2fbzIVl9nXnt65MBwRYniMEG0hyn/8 cZOdED5O6bvxbSVGoeWXACSUwr1qbeUYvRA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1698413347; x=1698499747; bh=brwrI4QaL3SGWYyBRFVHYn/JWAkiXtjc+Ya 7W3+C3MQ=; b=jjdGL9KsiBLV1ZJPJpgcDVKO/T/xqa3sZP0sDgQ0jWGHvc+Y9sS TmtD4f7X6ctmXkvbD9XUycl+9Hm+q6K0nXi4nBRDiQj7T5N4AYQuRDdpnMiD4V5p Hh8NHcsXZ+ORRQ0Fermdyqduk98jbmgjLXWxI0UUVCfNS9jZ0f/1vHAfQPQzmEVQ 8ny0X0Eit+Zx6BHi/K0bToAsfXnrkRUbgYhKf7D8paEIyppN4NpFkWYYgVilf5Rz E2hloeosFmJD6veK1qkyVVHNXONFBf33FXZoNjBPFh7QNzghNQq+5QOmtqhBAxam H06OpYqWaPJOGbgfvkngBxRy1M3tPXxvl0Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrleeggdeihecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpefhffehleejffegffeugefhkeektdffgfehjedvgeejtedtudehueffgffgfeej heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 27 Oct 2023 09:29:05 -0400 (EDT) Content-Language: en-US In-Reply-To: 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:273382 Archived-At: On 27/10/2023 03:26, João Távora wrote: > On Fri, Oct 27, 2023 at 1:11 AM Dmitry Gutov wrote: > >>> Also in the last iteration of the "yoyo" fido-vertical-mode test, >>> results with my latest patch are quite a bit faster. >> >> Hmm, your latest (lazy-hilit-2023-v3.diff) improves the (completing-read >> "" obarray) scenario a lot (over the original two 2023 solutions), but >> not the the 'C-h v' scenario. I don't have an explanation. > > The improvement was due to running string-match only once per completion, > if you look at the changes to completion-pcm--all-completions. Right. I just don't (didn't?) have an explanation for the difference in the improvement in performance (or the lack thereof) between the two scenarios. > It could be this code doesn't kick in in the C-h v scenario. Notice > that that function already has some optimizations: for example, when > the regexp match is performed by all-completions and its use of > completion-regexp-alist, there's no way to get the regex match data > to compute the score, so it'll have to be postponed to > completion-pcm--hilit-commonality as in the v2.diff case. > > Then again, that doesn't explain why in the C-h v scenario, the regression > was fixed precisely by adjust that code that I was conjecturing might > not kick in. According to my print-debugging, the situation is the reverse: (completing-read "" obarray) goes the "The internal functions already obeyed" route (because obarray is not a function?), and the scenario that didn't get better (C-h v) goes down the clause "pattern has something interesting to match". Unless the input is empty, then it also goes down the first clause. So it seems like we might misunderstand the reason why the former got faster. I see the check changed from (not (functionp table) to (or (not (functionp table)) (cl-loop for e in pattern never (stringp e))) but that can't be that reason. BTW, all-completion's docstring also says that a COLLECTION that is a function should itself handle completion-regexp-list, so we could try to rely on that too and drop the additional check. That's risky, though, so something for a later follow-up. > Anyway, I think it's safer to say that my latest patch is at least as fast, > sometimes faster, than the 2023 completion-filter-completions solution. All other things equal, I also prefer a smaller change, and thank you for producing it. Functionally, too, it's almost equivalent to completion-filter-completions. So one could easily write a wrapper like that with the same performance. But there are differences. The first is that the highlighter function takes one string as an argument instead of a collection. I mentioned this before, this will be much handier to use in company-capf. Second, in Daniel's patch the "adjust metadata" function got a different, arguably better, calling convention. That's not dependent on the rest of the patch, so it can be considered separately. Third, it made a principled stance to avoid altering the original strings, even the non-visual text properties. This approach could be adopted piecewise from Daniel's patch, especially if the performance ends up the same or insignificantly different in practical usage. As for whether we migrate to the completion-filter-completions API, I don't have a strong opinion. If we still think that the next revision of the completion API will be radically different, then there is not much point in making medium-sized steps like that. OTOH, if we end up with the same API for the next decade and more, completion-filter-completions does look more meaningful, and more easily extensible (e.g. next we could add a pair (completion-scorer . fn) to its return value; and so on). And again, the implementation could be a simple wrapper at first.