From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Date: Mon, 16 Aug 2021 11:15:33 +0100 Message-ID: References: <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37486"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , Dmitry Gutov , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org To: Daniel Mendler Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 16 12:16:14 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 1mFZfB-0009Yq-Ol for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 12:16:13 +0200 Original-Received: from localhost ([::1]:38656 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFZfA-0000cv-Nr for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 06:16:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35520) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFZf0-0000cF-SL for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 06:16:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37055) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mFZf0-0003pQ-Go for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 06:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mFZf0-0005n1-7k for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 06:16:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 10:16: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.162910896022245 (code B ref 47711); Mon, 16 Aug 2021 10:16:02 +0000 Original-Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 10:16:00 +0000 Original-Received: from localhost ([127.0.0.1]:48599 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFZeu-0005me-BP for submit@debbugs.gnu.org; Mon, 16 Aug 2021 06:16:00 -0400 Original-Received: from mail-pj1-f49.google.com ([209.85.216.49]:50939) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFZep-0005mL-7s; Mon, 16 Aug 2021 06:15:55 -0400 Original-Received: by mail-pj1-f49.google.com with SMTP id bo18so25799769pjb.0; Mon, 16 Aug 2021 03:15:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=oCu4cbI2ZHBlH+viXbn57tCqpQanGyFP2VKCGfxLh0g=; b=pOBU+OJWKVLpM+bgIOsSX7qDT6wD3fmisZzaVMYPZY7PDkcACW5A4vLnHqDhy/2MMB cKa8u/42PbX9UHUY5IPmRJN7xoGPyMJVXy7+ssfrBYza39Py4cN70Ltty0/DVuAelM17 Eehl2glcdmfPy3QfEap7uc/uXKbDEcUTOjefFFcchyPcFGh/jpG5ubBq8cRFkkXIsDu+ L2fpHWh1F6k/W8lpOiF0UfrvxZNuX42ApNTInrgGbuxY0kPrA3R2I+cNsmsP/ghLg8Dn bf3gRVr7KA/jsQbQGrRV2ecDJLP8NdjjrUx3a6pArAjDAeGhm3lgjU8fSsc6S4j20sHY WViQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=oCu4cbI2ZHBlH+viXbn57tCqpQanGyFP2VKCGfxLh0g=; b=rhsHunsSCjvFv79B7foeYQKAK33wUzmRtqIkwHeKwcGA0vIBqBBQhEcdFPNyRGGpvy AarweVcTNTI4eF7fs2Hrf/C9fDOqJAWOGrNj2BYLOl5ywiVtDuqMOZ7QjwEE1aSHrJIZ OeE2ok2O9/3kVtu2V1rWp93Omyz87sjZ/sAGxnSfSC7sZCUUUizxMn2PTkIt1gtuvDij XTjYmDTLvcTnDalrduCKomn72KtbJGg2vE6LSCLFPfwRDhxf8oGRGjWTcvi6RBI9Id8K FYZjGLtFEZyoLxnXvtcWwyA0xwZf99NiJ+j7QwnkUcqMl5WdH48UBDn7U6J1mfOaj1OW R8Ew== X-Gm-Message-State: AOAM530AAvV6A9459vlqXfrpFbwyQEfKBEcNBC6HESsdiu8ZXx1H0t+S qVUNecWQJwViMsgQdHcOuAXcWvBn4x5XTuxHwk0= X-Google-Smtp-Source: ABdhPJywDmMGd3lrQvu/IRBaYjuAjSKHTu2VbM9Pbf95ULRtVPqyQviOnAxC5kaOj1E9zxtJfwHeTrP7lYUHnU5kk9E= X-Received: by 2002:a17:90a:3849:: with SMTP id l9mr5591552pjf.7.1629108945143; Mon, 16 Aug 2021 03:15:45 -0700 (PDT) In-Reply-To: <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> 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:211977 Archived-At: On Mon, Aug 16, 2021 at 10:09 AM Daniel Mendler wr= ote: > There are serious drawbacks of attaching "private" string properties to > arbitrary strings. For once it complicates debugging seriously if there > are suddenly string properties attached to symbol names. It also leads > to a potential memory leak. Please, in the name of the sanity of this discussion, justify these two statements with examples or follow them with a clause like "because...". > 3. The `completion-filter-completions` API is the fastest possible API Again that's quite a statement that I cannot evaluate the veracity of without hard proof. What I _can_ evaluate is the material you have put forward, and using your patch and your Vertico completion software, version 0.14, the very latest one. I try emacs -Q -f package-initialize benchmark.el where benchmark.el is: (setq completion-styles '(flex)) (defmacro heyhey () `(progn ,@(cl-loop repeat 300000 collect `(defun ,(intern (symbol-name (gensym "heyhey"))) () 42)= ))) (heyhey) I then turn on vertico-mode and press C-h f. It takes about 4-5 seconds. It's *faster* than if I do the same with fido-vertical-mode and the current master, but is noticeably *slower* than if I do the same with the patch provided earlier and available at scratch/icomplete-lazy-highlight-attempt-= 2. Unfortunately, I cannot measure quantitatively here, because I don't know how to tell Vertico to wait until it gets the correct result. In other words, take this form: (completing-read "bla" obarray) if you type C-u C-x C-e C-m veeery s-l-o-w-l-y in Vertico, if prints , correctly, the character "%". But if you evaluate it quickly wrapped in a benchmark-run, it returns immediately and prints "". In fido-mode, it always waits blockinly until it prints the correct result and the time it took it to achieve that result. Not questioning if this is a bug in Vertico, but it would help if it could do the same, or be configured to do the same, so that we can measure. Without that, we can't evaluate the speed of Vertico where, presumably, the fastest API in the world is being used right now. > 4. If 'completion-all-completions' does indeed get slower thanks to my > patch, it is a performance regression of my patch. I will fix this. And > I thank you Jo=C3=A3o for bringing this to my attention. However one shou= ld > also consider that in the end, 'fido-mode' and 'icomplete-mode' should > move to the new API 'completion-filter-completions' such that they > benefit from the fast filtering and only copy and highlight the actually > displayed strings. Maybe they will, maybe they will. But it's still quite early to decide if we're going to move all frontends to that API. There's no manual documentation for it. Conceivably, if you appreciate your API so, you could demonstrate in practice us how easy it is to use by providing a separate patch that adapts icomplete-mode and fido-mode to use it. Then, I or other fido-mode users could test it for a while, evaluating its speed and correctness. If it performs well and the completion API architects have a good outlook for it, I see no reason why it shouldn't be merged and eventually supersede the new one. In the meantime, there is a patch with a measured and documented performance boost where fido-mode and icomplete-mode move opt-in to a new `completion-lazy-hilit` feature in the "old" API with a total or four 1-line changes. That patch lives in the branch scratch/icomplete-lazy-highlight-attempt-2. I think we should move to that, solving the bug#48841 while we do the evaluation of all aspects of your contributions. Jo=C3=A3o T=C3=A1vora