Received: (at 47711) by debbugs.gnu.org; 7 Nov 2023 12:14:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 07 07:14:03 2023
Received: from localhost ([127.0.0.1]:41398 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1r0Ky3-00085A-1K
for submit <at> debbugs.gnu.org; Tue, 07 Nov 2023 07:14:03 -0500
Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]:46518)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1r0Ky1-00084T-Ba
for 47711 <at> debbugs.gnu.org; Tue, 07 Nov 2023 07:14:02 -0500
Received: by mail-lf1-x12b.google.com with SMTP id
2adb3069b0e04-507e85ebf50so6920353e87.1
for <47711 <at> debbugs.gnu.org>; Tue, 07 Nov 2023 04:13:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1699359197; x=1699963997; darn=debbugs.gnu.org;
h=content-transfer-encoding:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:from:to:cc:subject:date
:message-id:reply-to;
bh=vgiMu1AMcTgicKCCRb4bMzWPu6AUcTX5hSbH59MrO+I=;
b=aHocNeDeAdvD9fRxIoE3TRt427NJ6I9mbFFcvcKfeWDwxq/aN5Dux0rsamkdGvMWwP
9T8ePq1H0Fw0ftvRaui0j3DviuUBPUx7oDRyT6C9amPczIOG7ITW8H0Jq8ad9AGJcZ7E
hTgs7aL/K9aEaEWhGzker8Bqy3Mm/aZQSwRz+6xxP43iKuTswO0nbBftNpyHqWjHa3Aa
jHceeQyLP3XWvalYzRuZJ4Lwm4Df0/SvKT4SfCTRSuIjtpyQMWH7yCvf3QUlIWdMDT7q
Tvy57eZ/5jWNhwkw/us/pRX6KwrCVDnjs2cq51eF1LxMxTyS/frRl0UZ6BscWOnKqOrj
PtiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1699359197; x=1699963997;
h=content-transfer-encoding:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=vgiMu1AMcTgicKCCRb4bMzWPu6AUcTX5hSbH59MrO+I=;
b=ubBB1LSOpReWkenp3/Ggpjx3ZLSqbi6mHlA1mno0dm4KsYmxR1clqkTzt6Q7v0KCCi
BYkRIhU5w+zgRNs2KvmKjh1c1gQTrQfbc0ASn53yBlepJkfAxvOVF1bU5aNq5uk6ymbM
H3LpeRDLgw4rwSA1FO16843xb4vRk8fuGSrTDIahKura1GBA3zDOjjR3RxqN830TWCSE
8ESO41XkgeeoY1htohbinGSAB0OzEwOI+TXSvsbYXxtzvLMdu5OXedzc6dYdCVosFnIe
mymQkBLkYK3h67hhbjv0J5F0PxXRyk3SdtaQn/aQOOLCof8KIgPysgxJ6bqgWO5wukcD
fU5A==
X-Gm-Message-State: AOJu0YzPPCR5rNX+0G2FSLxcpinU/dGa0/XNiZyAd/edDOkHQTn1egyq
er8jyntAaYz3KaQXo+H3PRd17VVP8eMPjbFILlU=
X-Google-Smtp-Source: AGHT+IFXYIWUzsZtNi6GkFi98NBfmLM2bpy3fOSBxfTxZFKjobr8R0AqIL1XreEBOGoXGtUz9F6Avp+sgy5qw0Jl0u8=
X-Received: by 2002:a19:6905:0:b0:507:a3ae:3252 with SMTP id
e5-20020a196905000000b00507a3ae3252mr21028494lfc.27.1699359197092; Tue, 07
Nov 2023 04:13:17 -0800 (PST)
MIME-Version: 1.0
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN>
<9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN>
<9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN>
<CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN>
<7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN>
<CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN>
<5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <877cn8asud.fsf@HIDDEN>
<c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN> <8734xtauqj.fsf@HIDDEN>
<eeabbe1f-7b2d-ade5-949c-05aea0ba85a9@HIDDEN>
<CALDnm51kS6p9V7z1AT=+TFp6kM5xw5Xv_oWZFSqAuEKx=-=a2A@HIDDEN>
<5181f95e-61e7-c8c4-6389-44ee57e0c749@HIDDEN>
<CALDnm51p7awjuw4vFMC=UByXnFUYMHsecUaSrT=Jiii5S3fgxQ@HIDDEN>
<31cadbfd-d086-a04f-0ed9-17ce70b4282c@HIDDEN>
<CALDnm51sO_A94NL6ozF6r5x+AsJemcqGRVJ2oQCtJcfoUcEi+A@HIDDEN>
<ddae4ed2-a306-9e47-40a9-7d2345300767@HIDDEN>
In-Reply-To: <ddae4ed2-a306-9e47-40a9-7d2345300767@HIDDEN>
From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
Date: Tue, 7 Nov 2023 12:13:05 +0000
Message-ID: <CALDnm5334OvCmOHfMcG1BS_5S_KMYFS+6mGg1UnaLeiJonxytQ@HIDDEN>
Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add
new `completion-filter-completions` API and deferred highlighting
To: Dmitry Gutov <dmitry@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47711
Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On Mon, Nov 6, 2023 at 7:39=E2=80=AFPM Dmitry Gutov <dmitry@HIDDEN> wrot=
e:
>
> On 06/11/2023 18:20, Jo=C3=A3o T=C3=A1vora wrote:
> > On Wed, Nov 1, 2023 at 10:45=E2=80=AFPM Dmitry Gutov<dmitry@HIDDEN> =
wrote:
> >
> >> I guess we should wait a few days to see if anyone has more comments,
> >> and then install this?
> > Five days elapsed, and no more comments came in, so I addressed your
> > comments and Eli's and I pushed this to master as
> > dfffb91a70532ac0021648ba692336331cbe0499.
Here's another place where completion-lazy-hilit could be leveraged:
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index ca2b25415f1..bb2670bccf6 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2067,7 +2067,7 @@ completion--insert-strings
;; when the caller uses tabs inside prefix.
(setq colwidth (- colwidth (mod colwidth completion-tab-width))))
(funcall (intern (format "completion--insert-%s" completions-format)=
)
- strings group-fun length wwidth colwidth columns))))
+ (mapcar #'completion-lazy-hilit strings) group-fun
length wwidth colwidth columns))))
(defun completion--insert-horizontal (strings group-fun
length wwidth
@@ -2378,6 +2378,7 @@ minibuffer-completion-help
(end (or end (point-max)))
(string (buffer-substring start end))
(md (completion--field-metadata start))
+ (completion-lazy-hilit t)
(completions (completion-all-completions
string
minibuffer-completion-table
Any objections? Seems to speed it up when flex is the preferred
completion style outside icomplete. These are average times
collected from the instrumentation of the above
completion-all-completions when doing a M-: (setq i TAB)
I just used my normal Emacs session for this.
with lazy hilit: 0.104536125
without lazy hilit: 0.172522571
Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 6 Nov 2023 19:39:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Nov 06 14:39:52 2023 Received: from localhost ([127.0.0.1]:40735 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1r05Rw-0000nn-Ho for submit <at> debbugs.gnu.org; Mon, 06 Nov 2023 14:39:52 -0500 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:37283) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1r05Ru-0000nX-UJ for 47711 <at> debbugs.gnu.org; Mon, 06 Nov 2023 14:39:51 -0500 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3CB855C0136; Mon, 6 Nov 2023 14:39:08 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 06 Nov 2023 14:39:08 -0500 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= 1699299548; x=1699385948; bh=5+ASUzWbtTYBk10z2A7RQdZFR+msjMq2i6I 2Txej1rc=; b=f+0zubYZo0AqHHtlVrrt9nmnhMLoBvAWq5C2n/j/XL9edOSRoeg tLOpSC0nzpd+s8rploSjyO8vrF/+LW8lbgqA56n1gN8oNGMUc1E7zEwNXVW+bsLl qhNUpy0bl3p/0ZqgXc38HuZbuSitZyYobqmdMYDRKPzpi7WNUK1TMornQFCZFjd3 rR20puNJo8AGOe8zBBxhu3MvkXhmrr3xhhtDI1635/6MXiXF/UJJk695k3tE8ZXu BBtoJ7JAvLGzk9643flgIswLLsS7oa7HTpYFjyZV4nNiifdXXsTywFqoSQVUQ4KD 95MxMpfJsXeVuoGqjWuuPjpjbTPEEm83DMg== 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= 1699299548; x=1699385948; bh=5+ASUzWbtTYBk10z2A7RQdZFR+msjMq2i6I 2Txej1rc=; b=t5+WFCIqzRRcBrl7LQjGGTEiiVinX9Fv3q+hYlvlRkTagElwhs7 nZ6olGjzh2UpkweucRA8W+pc1PI0GhdoZ+uusze4KyM0gD4mCW9GraIGrpc0VS6T VZsgyna4gU2EsNWiC+BdIWncmNfp7LCTLiAJhpOGsXvAp73puIsdzZaYuTWhhcvG HM1euT8PuLwRNYORXSB67XBwDSWSVbeHlzpGDCcZvoe53o9ZdsQ+FEWn2kk1CWJP 9rt14aPNFtYGmiMgrJ6UO3Z0qEifCUs0vHPrKhKggXC3x6RZ3oNvcWJI1uS7TMUT 4uq/pNGjHy0xKQVyXx28zYRNnxzrMMlmptA== X-ME-Sender: <xms:20BJZQWFXEfGOkGiN4sAml1IXypTG1M0w75cvWfEHtnNfyRN8mtqvA> <xme:20BJZUk9ecBfETmo_6olc5YeMeE0o0W55AsMEzEmM9Iko_3xL-IZ8ymD-DbG2OE7X VRVFtet20BLiXhMcLk> X-ME-Received: <xmr:20BJZUYGW6V6xGvjarsY3-FCZhBSLIiG_W1EY_JSR8GASWZldIV91-ma0_WE7Dg> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddugedguddvhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpefhffehleejffegffeugefhkeektdffgfehjedvgeejtedtudehueffgffg feejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: <xmx:20BJZfX7z_CvsNm08W34WZAww_KGpkqg0KiQI97JhGus88Qs43C-tg> <xmx:20BJZakpDF0hS75ob2rF8mSmlp_Wj1-jV0Y1dRUuaQXhi9a0z2Qmkg> <xmx:20BJZUcvTgL2Pfl7dQQHzkbqugtZQI57BA5xgrYW5jDyAgyUoUNMNA> <xmx:3EBJZciWXK_VCZop8iu4E__SeRsruzFAX8w7YReyostQlZNvFedcxw> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 6 Nov 2023 14:38:58 -0500 (EST) Message-ID: <ddae4ed2-a306-9e47-40a9-7d2345300767@HIDDEN> Date: Mon, 6 Nov 2023 21:38:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <877cn8asud.fsf@HIDDEN> <c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN> <8734xtauqj.fsf@HIDDEN> <eeabbe1f-7b2d-ade5-949c-05aea0ba85a9@HIDDEN> <CALDnm51kS6p9V7z1AT=+TFp6kM5xw5Xv_oWZFSqAuEKx=-=a2A@HIDDEN> <5181f95e-61e7-c8c4-6389-44ee57e0c749@HIDDEN> <CALDnm51p7awjuw4vFMC=UByXnFUYMHsecUaSrT=Jiii5S3fgxQ@HIDDEN> <31cadbfd-d086-a04f-0ed9-17ce70b4282c@HIDDEN> <CALDnm51sO_A94NL6ozF6r5x+AsJemcqGRVJ2oQCtJcfoUcEi+A@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <CALDnm51sO_A94NL6ozF6r5x+AsJemcqGRVJ2oQCtJcfoUcEi+A@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.2 (---) On 06/11/2023 18:20, João Távora wrote: > On Wed, Nov 1, 2023 at 10:45 PM Dmitry Gutov<dmitry@HIDDEN> wrote: > >> I guess we should wait a few days to see if anyone has more comments, >> and then install this? > Five days elapsed, and no more comments came in, so I addressed your > comments and Eli's and I pushed this to master as > dfffb91a70532ac0021648ba692336331cbe0499. Thanks! And thanks to Daniel for the original proposal and design work.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 6 Nov 2023 16:21:50 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Nov 06 11:21:50 2023 Received: from localhost ([127.0.0.1]:40440 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1r02MI-0001Ai-0H for submit <at> debbugs.gnu.org; Mon, 06 Nov 2023 11:21:50 -0500 Received: from mail-lf1-x130.google.com ([2a00:1450:4864:20::130]:61741) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1r02MG-0001AR-9T for 47711 <at> debbugs.gnu.org; Mon, 06 Nov 2023 11:21:49 -0500 Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-507c5249d55so6075258e87.3 for <47711 <at> debbugs.gnu.org>; Mon, 06 Nov 2023 08:21:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699287665; x=1699892465; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=5p6B7wqLviKfwEWAyelQ6um8OVrA52An9YuhSm7FElM=; b=VtFDuXxtmXh0GlgTSj/ICqbv0scMzPgtD5wmpQm87Y/GRQjUw5+3zji0eWNuUSJjF0 Xr0RxpdTP11F/VE2ye7rbp8vZfCEmfhQlrcduBT7AMx4FyXtivr3dA5Doq0BaeCQyY3F HwpJlUUE9Werz/1tmKjkL0OywkBVTLGruk3ARCl1jtSotKRPiIrsbRM9KeHkg5JhLCws yeWdZDzWaZQvOK+58kJ888/gjH96EjBq18I9iiDN9tvTwVZwi184VmBaifZQDNtUN0mr f/iJJ+6g/oVDlng/gOSP0JxPwcjLwQI1H6hf2EDsCPW0KAHfA20mPyT6GgiF2O2tmJTB V3LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699287665; x=1699892465; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5p6B7wqLviKfwEWAyelQ6um8OVrA52An9YuhSm7FElM=; b=F556Q3lapkLhsydzTX4NcxgXOzpoAwv0RuS5czdjduXQUqMCaUqu2okXFklwjkJ3fV P06DU+xt9uHKr2XdZ33jpw5LDNwgBYKug6I4WDz8cQOCWyaNZ6cW85TvyZeKXSwzisok B02yQVudTOxeMBcQkFDlQ8gPWu61qe84eMfvd1dcwiT2t/GZbjSrx9lWKS+n4KeqaI5B f0SeD2XqSgQVECaHECj7UxR7X5VCk2QEj0Pj1RgNfi6tZajFWT0Ne7lFHttqC9WAC6gI uoyDeEeiYwREuWe29v3r1qd63906vWkRCuSiOafy8fn59DBfezSPZBKD0W1bVdnc0r7o xKzw== X-Gm-Message-State: AOJu0YwmTWIM13Pb0LaVEmATkKxtNtn0u3tjviyYLoCzhzcPsFJHwAnJ 7UXGpRIoBrrRN0cPEJLC6pbkbEIc2IjraYBMvwg= X-Google-Smtp-Source: AGHT+IG6zoVXxAdPJ0EpvHDX06ji13HSukTVGEl9T1tv8QPfNCTaAwq9XOZXJ1mp15SQ336LgongEAQ5/oY0xh6njgE= X-Received: by 2002:a05:6512:4ca:b0:509:4655:d8d5 with SMTP id w10-20020a05651204ca00b005094655d8d5mr10876687lfq.11.1699287664273; Mon, 06 Nov 2023 08:21:04 -0800 (PST) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <877cn8asud.fsf@HIDDEN> <c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN> <8734xtauqj.fsf@HIDDEN> <eeabbe1f-7b2d-ade5-949c-05aea0ba85a9@HIDDEN> <CALDnm51kS6p9V7z1AT=+TFp6kM5xw5Xv_oWZFSqAuEKx=-=a2A@HIDDEN> <5181f95e-61e7-c8c4-6389-44ee57e0c749@HIDDEN> <CALDnm51p7awjuw4vFMC=UByXnFUYMHsecUaSrT=Jiii5S3fgxQ@HIDDEN> <31cadbfd-d086-a04f-0ed9-17ce70b4282c@HIDDEN> In-Reply-To: <31cadbfd-d086-a04f-0ed9-17ce70b4282c@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Mon, 6 Nov 2023 16:20:52 +0000 Message-ID: <CALDnm51sO_A94NL6ozF6r5x+AsJemcqGRVJ2oQCtJcfoUcEi+A@HIDDEN> Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Dmitry Gutov <dmitry@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Wed, Nov 1, 2023 at 10:45=E2=80=AFPM Dmitry Gutov <dmitry@HIDDEN> wro= te: > I guess we should wait a few days to see if anyone has more comments, > and then install this? Five days elapsed, and no more comments came in, so I addressed your comments and Eli's and I pushed this to master as dfffb91a70532ac0021648ba692336331cbe0499. Thanks, Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 4 Nov 2023 18:47:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 04 14:47:45 2023
Received: from localhost ([127.0.0.1]:35698 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qzLgO-0002zW-Uo
for submit <at> debbugs.gnu.org; Sat, 04 Nov 2023 14:47:45 -0400
Received: from lists.gnu.org ([2001:470:142::17]:60668)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <geb-bug-gnu-emacs@HIDDEN>)
id 1qzLgM-0002zF-En
for submit <at> debbugs.gnu.org; Sat, 04 Nov 2023 14:47:43 -0400
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 <geb-bug-gnu-emacs@HIDDEN>)
id 1qzLff-0007WU-P6
for bug-gnu-emacs@HIDDEN; Sat, 04 Nov 2023 14:46:59 -0400
Received: from ciao.gmane.io ([116.202.254.214])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <geb-bug-gnu-emacs@HIDDEN>)
id 1qzLfe-00023W-Fg
for bug-gnu-emacs@HIDDEN; Sat, 04 Nov 2023 14:46:59 -0400
Received: from list by ciao.gmane.io with local (Exim 4.92)
(envelope-from <geb-bug-gnu-emacs@HIDDEN>)
id 1qzLfZ-0000ar-02
for bug-gnu-emacs@HIDDEN; Sat, 04 Nov 2023 19:46:53 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: bug-gnu-emacs@HIDDEN
From: Howard Melman <hmelman@HIDDEN>
Subject: Re: bug#47711: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH
VERSION 2] Add new `completion-filter-completions` API and deferred
highlighting
Date: Sat, 04 Nov 2023 14:46:43 -0400
Message-ID: <lyh6m1fjak.fsf@HIDDEN>
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN>
<877cn8asud.fsf@HIDDEN>
<c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN>
<8734xtauqj.fsf@HIDDEN>
<eeabbe1f-7b2d-ade5-949c-05aea0ba85a9@HIDDEN>
<CALDnm51kS6p9V7z1AT=+TFp6kM5xw5Xv_oWZFSqAuEKx=-=a2A@HIDDEN>
<5181f95e-61e7-c8c4-6389-44ee57e0c749@HIDDEN>
<CALDnm51p7awjuw4vFMC=UByXnFUYMHsecUaSrT=Jiii5S3fgxQ@HIDDEN>
<31cadbfd-d086-a04f-0ed9-17ce70b4282c@HIDDEN>
<CALDnm5336QOoUf740oX0x+We2BJQihtOnGLzFzFe8QEuYAMw8w@HIDDEN>
<bae801f2-bc7b-dc33-d655-ba6b423050d8@HIDDEN>
<CALDnm534Mpsif=y7-Gq0r+UJSS4UkkFgwHVH+FJ4u1kvvpq3oQ@HIDDEN>
<15a867ba-5a0f-9852-0296-b4c809baac7b@HIDDEN>
<CALDnm52uQ6t_bBxTa5R-RKc_W8Oow_a8mpBaPrsf1a_dXz5ySw@HIDDEN>
<2a144a08-eb41-22ee-ddf0-59ad1f3222f0@HIDDEN>
<CALDnm51CHHqwxMBNds_GhtWHuhz-nRqgWfpX+O9xHBRJFp2uzQ@HIDDEN>
<fdedfc70-e0f9-461e-a05d-cd1f431b0586@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:HE4eQhOzvizq8QJvhHZVU8zwvts=
Received-SPF: pass client-ip=116.202.254.214;
envelope-from=geb-bug-gnu-emacs@HIDDEN; 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.248, FREEMAIL_FROM=0.001,
HEADER_FROM_DIFFERENT_DOMAINS=0.248, NML_ADSP_CUSTOM_MED=0.9,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.5 (+)
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 <dmitry@HIDDEN> writes: > On 02/11/2023 18:09,
João Távora wrote: >> On Thu, Nov 2, 2023 at 4:03 PM Dmitry Gutov<dmitry@HIDDEN>
wrote: >> >>>> That's debatable, I like to be able to type 'vcdiff' and >>>>
see all the [...]
Content analysis details: (1.5 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (hmelman[at]gmail.com)
0.0 T_SPF_PERMERROR SPF: test of record failed (permerror)
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
1.0 FORGED_GMAIL_RCVD 'From' gmail.com does not match 'Received'
headers
0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
mail domains are different
0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and
EnvelopeFrom freemail headers are
different
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.5 (/)
Dmitry Gutov <dmitry@HIDDEN> writes:
> On 02/11/2023 18:09, João Távora wrote:
>> On Thu, Nov 2, 2023 at 4:03 PM Dmitry Gutov<dmitry@HIDDEN> wrote:
>>
>>>> That's debatable, I like to be able to type 'vcdiff' and
>>>> see all the commands that vc.el offers for diffing things.
>>> That also works for Orderless and "vc dif".
>> Ah, but the order in which all these commands appear is
>> arbitrary, if I understand correctly. It must be, since
>> there's no sorting, right?
>
> Seems so.
FYI, it's true that orderless just does filtering, it's just a
completion-style and leaves sorting to the completion UI
(I use it with vertico, but others work too).
It's configurable so what people can input can vary a lot,
but the main feature is that each space-separated bit is used
in any order. So in the above example "vc dif" and "dif vc"
would both work. The second is unlikely in this example
but it's far more useful when searching for function or
variable names.
The other great feature is that each "word" can be evaluated
in different ways, I typically use them as regexps, but it's
also easy to add syntax. It's common to make a leading ! in
a word mean "without". So an input of "file !--" would
match all things that include file anywhere and doesn't
have -- anywhere. "^rx- !--" matches everything in the
public rx API (well anything beginning with rx- without --).
--
Howard
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 3 Nov 2023 03:06:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 02 23:06:05 2023
Received: from localhost ([127.0.0.1]:56551 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qykVV-00037N-RR
for submit <at> debbugs.gnu.org; Thu, 02 Nov 2023 23:06:05 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:13472)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qykVP-000372-Vq
for 47711 <at> debbugs.gnu.org; Thu, 02 Nov 2023 23:05:59 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 315BE8076B;
Thu, 2 Nov 2023 23:05:15 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1698980714;
bh=D3uGUKlYCW/VHrXcZjqCB6TEBlAQ+6x0BuY57plVaDE=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=lhCuHX8geg23flbyD2uGj+GzpcPfWY+1cD17fHoPJdb5TLzHshXb4XQ7oDTmDrlIP
/MarxTeIOE5gFiMP0EcE0VZK0mG0ELUDz+5+KNuW64KdOWTzJ3I4O/vVhOTtE+gZIH
SJeL14fUdH9Dnoir1oG6CNfshjJOEtGOifUnDQNkRGXGROCFMOReQc4x+/rzkwt4Ou
qxzW7PurrmTqCLNmr0ao3xvURUfumwS8lT6g9UtnGcG7sWh3EiKLc1ZNwlpzplqslh
VNmbBe6KbwpDOHgfGfW5ruHERa9bXDragatw6dWo4dxOMbz26xf8JV3sNctXPwDRK/
3lmzGA/jbGfGA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 31E6A80087;
Thu, 2 Nov 2023 23:05:14 -0400 (EDT)
Received: from pastel (unknown [45.72.195.71])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E1C67120420;
Thu, 2 Nov 2023 23:05:13 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Dmitry Gutov <dmitry@HIDDEN>
Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2]
Add new `completion-filter-completions` API and deferred highlighting
In-Reply-To: <c58d036e-23f0-66a8-2762-ec54bede54ba@HIDDEN> (Dmitry Gutov's
message of "Fri, 3 Nov 2023 02:16:23 +0200")
Message-ID: <jwvpm0rd0mk.fsf-monnier+emacs@HIDDEN>
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN>
<CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN>
<328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN>
<83fsvcbio7.fsf@HIDDEN>
<9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN>
<877cnafv39.fsf@HIDDEN>
<9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN>
<CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN>
<7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN>
<CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN>
<5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN>
<jwv5y2stc2f.fsf-monnier+emacs@HIDDEN>
<bc621b6e-236a-736c-0723-0c17292ee5ee@HIDDEN>
<jwvsf5wqc33.fsf-monnier+emacs@HIDDEN>
<1504b2e4-42d9-5d7b-eaa2-c7b7d5ca02ba@HIDDEN>
<jwvsf5wrmfn.fsf-monnier+emacs@HIDDEN>
<40ddec76-751a-36cd-7f45-34de2d9d9393@HIDDEN>
<jwvv8aqnjsw.fsf-monnier+emacs@HIDDEN>
<c58d036e-23f0-66a8-2762-ec54bede54ba@HIDDEN>
Date: Thu, 02 Nov 2023 23:05:13 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.007 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47711
Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
=?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>,
47711 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Sorry for the pause, let's continue this digression. Though perhaps it would
> be better moved to emacs-devel or somewhere else. ;-/
I see this API as an experiment. I have no idea if I'll like
the result. It's definitely far from being something ready to submit as
a proposal for a new design.
>>> As such, the most useful methods currently are: 1) Emacs Regexp, 2) asking
>>> server for whatever it thinks is suitable (the "backend" completion style).
>> For the backends: agreed.
>> For the frontends (i.e. `completion-styles`), `glob` is the more useful
>> one, I'd say (except for the "external" style, of course).
>> We might also want support for things like `or` and `and` patterns, but
>> I haven't managed to fit them nicely in that structure :-(
> Possibly, but which code would produce such patterns?
The `or` pattern? No idea :-)
The `and` pattern? Well, the `orderless` style, for one.
But indeed, I'm not sure it'd be useful to handle things like or/and
directly in there rather than by using union/intersection on
the resulting completions. It's just an aspect of the design
I considered and I noticed that I had trouble extending it in
that direction.
Obviously, the caller which needs to collect a set of matching
candidates always has a choice between using a more refined pattern
or using a simpler pattern (including various calls with various
different patterns).
>>> I would also probably want to standardize on the recommended type of TO
>>> anyway: some of them are likely going to result in better performance
>>> than others.
>> The TO is chosen by the specific completion table, based on what it can
>> handle best. So it should always be "optimal".
> Sorry, I meant the recommended type of FROM. Because if the original caller
> passes an arbitrary regexp, it will often get turned into a pair with
> a predicate where the latter calls string-match-p.
The caller should use the most primitive pattern they can.
> And if the type of FROM is standardized, there likely would be no need for
> a four-way bidirectional conversion. Maybe just a helper that converts from
> the original "main" type into any of the available that is
> currently required.
Indeed the default method does:
(cond
((eq to (car pattern)) (cons nil (cdr pattern)))
((eq 'glob to) (cl-call-next-method))
(t
;; Most conversions can be performed by going through `glob'.
(pcase-let* ((`(,gpred . ,glob)
(completion-pattern-convert 'glob pattern))
(`(,tpred . ,newpattern)
(completion-pattern-convert to glob)))
(cons (or gpred tpred) newpattern)))))
>>> So I guess it's also a way to make every completion table aware of PRED?
>> Note also that these `pred` patterns are expected to be exclusively
>> looking at the string (they're used for `completion-styles` kind of
>> functionality), so nothing like `file-directory-p` or `fboundp` kind of
>> predicates here.
> Would we consider those pred's "fast enough"?
I don't know. I haven't had a use for a `pred` pattern yet, to
be honest. As for the predicates returned by
`completion-pattern-convert`, they're currently just fancy booleans
indicating if the returned pattern is faithful or not :-)
So I'm not sure those predicates will survive this experiment.
> (benchmark-run 10 (let* ((re "yo[^o]*o")
> (completion-regexp-list (list re)))
> (all-completions "" sss)))
> ;; => 0.60s
>
>
> (benchmark-run 10 (let* ((re "yo[^o]*o"))
> (all-completions "" sss
> (lambda (s) (string-match-p re s)))))
> ;; => 1.14s
>>> That should work; though it might be hard to reach the same raw performance
>>> as the current all-completions + completion-regexp-list.
>> I don't see why: currently my code actually uses `all-completions` and
>> `completion-regexp-list`, so as long as the pattern can be turned into
>> a regexp without requiring an additional PRED (that's usually the case), <...>
> Right, I was talking about the possible exceptions.
I don't know what you're getting at.
Stefan
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 3 Nov 2023 00:17:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 02 20:17:17 2023
Received: from localhost ([127.0.0.1]:56430 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qyhsD-00078G-6S
for submit <at> debbugs.gnu.org; Thu, 02 Nov 2023 20:17:17 -0400
Received: from out1-smtp.messagingengine.com ([66.111.4.25]:58245)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <dmitry@HIDDEN>) id 1qyhs8-00077y-3L
for 47711 <at> debbugs.gnu.org; Thu, 02 Nov 2023 20:17:15 -0400
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43])
by mailout.nyi.internal (Postfix) with ESMTP id 7EAE15C00E0;
Thu, 2 Nov 2023 20:16:31 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
by compute3.internal (MEProxy); Thu, 02 Nov 2023 20:16:31 -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=
1698970591; x=1699056991; bh=s9n3pn4qkdGfQy//OH5t25w2Sr9DY23Vj+H
dT/mgek8=; b=HRsmk147LE8sXNuuOWhhsrdaRM3VjKTcbDZslECY+QxnvA99mCF
pOQwYQPqspeLkLWTrZ6QFOoFZ4mVL90VcryUr3biDfr9ToR7XAquUSkYgbgAAf2z
EroSCUQJmUbNE8JJCmctfkM4R10Ai8g8XsddlpwvJYS8yBV1zIiy/sUua/eOAhlb
OHb3u2CWTy+F0voE6dNZ0LcfdYM5WlC2z/t2yKLIxUNQQNkAAoAJUFDv/aQYWIT0
xcmN6YJrjTzGInKxwI58xeNX6TaSSWno/mkViCEKLiicDudNbZomuRaA6wq+zbKY
iYPLAesEn2n6QUt4weyFeodHjRfxN4aoQIA==
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=
1698970591; x=1699056991; bh=s9n3pn4qkdGfQy//OH5t25w2Sr9DY23Vj+H
dT/mgek8=; b=fZVcZw3ZUde0K5VJu3gLBSKBYYr4EOwmP7LRg8KX+P02svLRCPX
7H1fWU2bmNiGbsPtfvzAT0W6fliJ594MvbD7LorXKDB/aTSmOTaeOCGXGQWmGzKN
qMhNqV2V8wIx63vqK8G0QrqucEJjSzGvWAowEWQx7ItmYgVqXl1au+plFsNutNGE
WxobMtBtjAwS7tBZgxNKRBrQ/7lC4LDdgG60HAznCQSKJxu51oRGfkFraTr9NWUg
XPSZRhtpmnuxJLgk4IIM7CnNTJkJgWSHP/phn8ZTFH2F0bNb8IOBmrjmpeCm4giT
nZzyA1nPCI8bA7+bwHMMZzr43yy817+6CKA==
X-ME-Sender: <xms:3jtEZSyCsrwDsPyX2PJAAEjznmloGE6EQPZQMwBKDYTPL2VaJh0Z4A>
<xme:3jtEZeQQeymTa6UbfuGCw7ShEMarsz-j4wCD2FLyNbtGE0j4g_esq0Rrl-P2IBV9H
tzi_nePuwO6Jhs6x5c>
X-ME-Received: <xmr:3jtEZUVhI3wOx4jO1qA2JJkIxcdV0IbZl4YHjAuOJ06v_D9Wnnmm7nIdiwzje-s>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddtjedgudelucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi
thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth
htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel
vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug
hmihhtrhihsehguhhtohhvrdguvghv
X-ME-Proxy: <xmx:3jtEZYjU82rOcN6zICgzSvsf2k7r3g-i0YtmQ1KAV5PeqIQAuOaLeg>
<xmx:3jtEZUByZ7S6Dc64xXzKBp_y1bR3PHhAnjrn_Z4z5isSL0Q3yXCmHQ>
<xmx:3jtEZZLBlxSYkPpLSkt8bUxvyVG_jHDq7z8RAcBf8V1vuLquTeJgEg>
<xmx:3ztEZXMHjHarHefrwjPtTZtJN3ZqjcEQ_KpsJQGXQCXwKktK4b_CCQ>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
2 Nov 2023 20:16:27 -0400 (EDT)
Message-ID: <c58d036e-23f0-66a8-2762-ec54bede54ba@HIDDEN>
Date: Fri, 3 Nov 2023 02:16:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.13.0
Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add
new `completion-filter-completions` API and deferred highlighting
Content-Language: en-US
To: Stefan Monnier <monnier@HIDDEN>
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN>
<CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN>
<328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN>
<9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN>
<9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN>
<CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN>
<7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN>
<CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN>
<5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN>
<jwv5y2stc2f.fsf-monnier+emacs@HIDDEN>
<bc621b6e-236a-736c-0723-0c17292ee5ee@HIDDEN>
<jwvsf5wqc33.fsf-monnier+emacs@HIDDEN>
<1504b2e4-42d9-5d7b-eaa2-c7b7d5ca02ba@HIDDEN>
<jwvsf5wrmfn.fsf-monnier+emacs@HIDDEN>
<40ddec76-751a-36cd-7f45-34de2d9d9393@HIDDEN>
<jwvv8aqnjsw.fsf-monnier+emacs@HIDDEN>
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <jwvv8aqnjsw.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.2 (--)
X-Debbugs-Envelope-To: 47711
Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
=?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, 47711 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.2 (---)
Hi Stefan,
Sorry for the pause, let's continue this digression. Though perhaps it
would be better moved to emacs-devel or somewhere else. ;-/
On 29/10/2023 06:41, Stefan Monnier wrote:
>> FWIW, this neat structure might not help too much: the most popular external
>> completion backend (the LSP language servers, collectively) don't accept
>> regexps or globs, they just send you the lists of completions available at
>> point. With the name matching method sometimes configurable per-server.
>
> Largely agreed. The main benefit tho is that you get just *one*
> pattern, rather than three (one being the prefix argument, the second
> being the `pred` arg which historically was so unused that it was abused
> to hold the directory for file-name completion, so lots of tables don't
> obey it, and the third being the `completion-regexp-list` that most coders
> forget, and those who don't end up regretting not forgetting when it was
> not meant for them), so it's much more clear.
The motivation all makes sense.
>> As such, the most useful methods currently are: 1) Emacs Regexp, 2) asking
>> server for whatever it thinks is suitable (the "backend" completion style).
>
> For the backends: agreed.
> For the frontends (i.e. `completion-styles`), `glob` is the more useful
> one, I'd say (except for the "external" style, of course).
>
> We might also want support for things like `or` and `and` patterns, but
> I haven't managed to fit them nicely in that structure :-(
Possibly, but which code would produce such patterns?
>> I would also probably want to standardize on the recommended type of TO
>> anyway: some of them are likely going to result in better performance
>> than others.
>
> The TO is chosen by the specific completion table, based on what it can
> handle best. So it should always be "optimal".
Sorry, I meant the recommended type of FROM. Because if the original
caller passes an arbitrary regexp, it will often get turned into a pair
with a predicate where the latter calls string-match-p.
And if the type of FROM is standardized, there likely would be no need
for a four-way bidirectional conversion. Maybe just a helper that
converts from the original "main" type into any of the available that is
currently required.
>> So I guess it's also a way to make every completion table aware of PRED?
>
> Note also that these `pred` patterns are expected to be exclusively
> looking at the string (they're used for `completion-styles` kind of
> functionality), so nothing like `file-directory-p` or `fboundp` kind of
> predicates here.
Would we consider those pred's "fast enough"?
I've done a little comparison of completion-regexp-list vs pred:
(setq sss (cl-loop repeat 300000 collect (symbol-name (gensym "yoyo"))))
(benchmark-run 10 (let* ((re "yo[^o]*o")
(completion-regexp-list (list re)))
(all-completions "" sss)))
;; => 0.60s
(benchmark-run 10 (let* ((re "yo[^o]*o"))
(all-completions "" sss
(lambda (s) (string-match-p re s)))))
;; => 1.14s
> The `pred`s used in things like `completing-read` and `read-file-name`
> would be handled elsewhere such as `completion-table-with-predicate`.
> This part is still up in the air, tho.
>
>> That should work; though it might be hard to reach the same raw performance
>> as the current all-completions + completion-regexp-list.
>
> I don't see why: currently my code actually uses `all-completions` and
> `completion-regexp-list`, so as long as the pattern can be turned into
> a regexp without requiring an additional PRED (that's usually the case), <...>
Right, I was talking about the possible exceptions.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 2 Nov 2023 16:16:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 02 12:16:20 2023 Received: from localhost ([127.0.0.1]:55852 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qyaMm-0008Gu-5E for submit <at> debbugs.gnu.org; Thu, 02 Nov 2023 12:16:20 -0400 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:53515) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1qyaMj-0008Gb-8c for 47711 <at> debbugs.gnu.org; Thu, 02 Nov 2023 12:16:18 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 1226B32009A8; Thu, 2 Nov 2023 12:15:34 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Thu, 02 Nov 2023 12:15:35 -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= 1698941734; x=1699028134; bh=ZXAeSqA02Bd1RsI+f6LZwiTjBaEOMkeh4mI Uqe5mS0E=; b=LuueB1FNJCWgbIfKeS6ze/JvQO4PoUN+2dV6VHmybvjCRgf39nP H93uw88hX4x/6cKc2oTxHN9l405xHiSr7D0fZ85jW3P3g6KYve6ElVjBmJpJf/zl Bcsfhr1jjDfUDkSzBILmAfncG066wGX76DQgwh2WD7MNFsW8uHQvD+lsfN+dpjZi v02dACiK66NpRGNSEhi8ZGY68yxtNWK97o2+C2iW2U3MC+gMuMqc7pnArpcR7Ydt 1KWvd/r50l3osTW7YPrGh8rab69ef1gE6UD93eKneG9JggahRypLca0ElJCsmume JPkZQW4DHd1o5D7IZOxKRkUg52nK4MnaTPQ== 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= 1698941734; x=1699028134; bh=ZXAeSqA02Bd1RsI+f6LZwiTjBaEOMkeh4mI Uqe5mS0E=; b=k/Noc85Dwln8pYYVNfwFSIfw/Cb4U+ZOJRtFaMwPjxNApwAUnB1 cPU74MfI14nU3088wfHT/PuAI5EAQhiV+Tb847gHAlR1ZxlMyExoAvEohy4GDgZA kJkcRHZrZ43+EbbCnG10fBzflvMh90imCZd55KqGUidnTQClqrSjJy1v4s1/ULUO t5ZOl5PskbdTn9d015t7bdZRAIbg8jJigKZ9TnxQgTgsdsGEHGc4C7dyu8P7rFif Mm1rhBdQnstGdFt4GW/VmZXIVGTYuCmLw93N0qIMa7Zhn6IYrgujcwMLbPTLtWO4 UhI96+JbcjBjORyzDyjuS6SK0VomtHYTg1A== X-ME-Sender: <xms:JstDZcnLuTPeloh4mxy4cJX__wGicaA8F61OgQBS3IVHVwr1ZAO4dA> <xme:JstDZb12dGYZhKpiw3RLkobwpcjwF_9OAsGxnlhAQKzWwxD4TxXwmSMr8dqz6u1Uu UGdRWUfKhT9_jeqba4> X-ME-Received: <xmr:JstDZaq04JXGODyGLuEdiKNjtFnZNloTRue6DCaeyvjwFr4LtilMEGyPM2DNDR4> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddtiedgkeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhephfffheeljeffgeffueeghfekkedtfffgheejvdegjeettdduheeufffggfef jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: <xmx:JstDZYkUmfBWnKgX-MFzOfEXk3UfGhNlP0uwIZ2_3C_jZsl6LEnp0Q> <xmx:JstDZa2YMPImzFsV88OFmfBebsiOEar1_pKsk_zDTdnYn02oBXGEZg> <xmx:JstDZfsLPw4q_RY7gDHNVRXMpk0fbte4KaRCIY5WKFHcR9HUTq2ABw> <xmx:JstDZfzVgITCYvOdLa8Y9WzIceVFZIK1Yk9DraXn2fkgx59jmuzmuQ> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 2 Nov 2023 12:15:32 -0400 (EDT) Message-ID: <fdedfc70-e0f9-461e-a05d-cd1f431b0586@HIDDEN> Date: Thu, 2 Nov 2023 18:15:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <877cn8asud.fsf@HIDDEN> <c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN> <8734xtauqj.fsf@HIDDEN> <eeabbe1f-7b2d-ade5-949c-05aea0ba85a9@HIDDEN> <CALDnm51kS6p9V7z1AT=+TFp6kM5xw5Xv_oWZFSqAuEKx=-=a2A@HIDDEN> <5181f95e-61e7-c8c4-6389-44ee57e0c749@HIDDEN> <CALDnm51p7awjuw4vFMC=UByXnFUYMHsecUaSrT=Jiii5S3fgxQ@HIDDEN> <31cadbfd-d086-a04f-0ed9-17ce70b4282c@HIDDEN> <CALDnm5336QOoUf740oX0x+We2BJQihtOnGLzFzFe8QEuYAMw8w@HIDDEN> <bae801f2-bc7b-dc33-d655-ba6b423050d8@HIDDEN> <CALDnm534Mpsif=y7-Gq0r+UJSS4UkkFgwHVH+FJ4u1kvvpq3oQ@HIDDEN> <15a867ba-5a0f-9852-0296-b4c809baac7b@HIDDEN> <CALDnm52uQ6t_bBxTa5R-RKc_W8Oow_a8mpBaPrsf1a_dXz5ySw@HIDDEN> <2a144a08-eb41-22ee-ddf0-59ad1f3222f0@HIDDEN> <CALDnm51CHHqwxMBNds_GhtWHuhz-nRqgWfpX+O9xHBRJFp2uzQ@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <CALDnm51CHHqwxMBNds_GhtWHuhz-nRqgWfpX+O9xHBRJFp2uzQ@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.2 (---) On 02/11/2023 18:09, João Távora wrote: > On Thu, Nov 2, 2023 at 4:03 PM Dmitry Gutov<dmitry@HIDDEN> wrote: > >>> That's debatable, I like to be able to type 'vcdiff' and >>> see all the commands that vc.el offers for diffing things. >> That also works for Orderless and "vc dif". > Ah, but the order in which all these commands appear is > arbitrary, if I understand correctly. It must be, since > there's no sorting, right? Seems so.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 2 Nov 2023 16:10:12 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 02 12:10:12 2023 Received: from localhost ([127.0.0.1]:55841 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qyaGm-00085a-Kl for submit <at> debbugs.gnu.org; Thu, 02 Nov 2023 12:10:12 -0400 Received: from mail-lf1-x12c.google.com ([2a00:1450:4864:20::12c]:59738) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1qyaGh-00084w-RG for 47711 <at> debbugs.gnu.org; Thu, 02 Nov 2023 12:10:07 -0400 Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-507adc3381cso1324707e87.3 for <47711 <at> debbugs.gnu.org>; Thu, 02 Nov 2023 09:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698941362; x=1699546162; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=aUQFf4+utFqLssZMWVKWI/YXtFZR2T3o+DcJCJm0y6A=; b=QnJ+cMun+uKr5pILI7O0iLZ5tdnYjzTsRLQltRByGmp91N5wroK/5xxNJ5npOj8VmY 2zY+Fon/87v9YghJ9ehmqsC+C6T+jNBmjZkmBdRtrRRG2FyPnUItNhbr7DjGraf1mxWF r9v0fe1O1CnGBaZVTCeQTSma34y8STnkfs5CKTdO20Q/hODYo2Q2AHok9xNirXPn394K iaVBOg2xLOjMEOKVo61xAYoYKLyrL9VuSLh7NFW5U0FK86RPsvk+NDPNJevmGCQv7fmW mvLhY68e+mT/qTnpZg5MxV3CnUH2a0PvUgJT2ohSw6rtIjfzSCFRpGJ/DTEMfI7FEmVS p1tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698941362; x=1699546162; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=aUQFf4+utFqLssZMWVKWI/YXtFZR2T3o+DcJCJm0y6A=; b=vieyWPeCvBmQKH0mBsji+wiUBdU05iuSHsqOoG18aLSOFsd6W17cAKkRgYeIDvZo0Y XecjnCDJhHWEj9P8q0tFixTRhTxzBjvK5Q0scec3p7PJgijs3gGomuoB9IGP8+6xN+AZ ra/NJ9okqB4iJj9oKQQ1N349gEATa2r7a0vFCemq98FRYROFVk4+jbUYxnQxWPCTO4Hv aBA7fUmsOkAMdZTq86C2jGmp7ra/LZZy9nZbtSsb2110YjXoQIQ6wK54FjWG77JAgR4V Q3p+BDiwAp660eyPkSCh5lUZWO4qKfTll/8NeIK1gOhPjqLH2uBeJHm3v1tVErtVmji0 yevA== X-Gm-Message-State: AOJu0Yz5cd9gar3T1D9YlN4ENmpDjG37LvgyJ3ZFuA+FiDlNsG+qTDtX ChkAExatAvM0TTXbPW08tYjJweKtFTvkU8c1FpM= X-Google-Smtp-Source: AGHT+IH3AeFl9FsWKPyRqhcM9pW6HWYwtTSz9IcP3Nt7pre8eGFe6KTwIOif8IurGsl0PIyxDzj2K4wqSikeo47b75M= X-Received: by 2002:ac2:44d3:0:b0:507:a703:886e with SMTP id d19-20020ac244d3000000b00507a703886emr14083059lfm.53.1698941362106; Thu, 02 Nov 2023 09:09:22 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <877cn8asud.fsf@HIDDEN> <c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN> <8734xtauqj.fsf@HIDDEN> <eeabbe1f-7b2d-ade5-949c-05aea0ba85a9@HIDDEN> <CALDnm51kS6p9V7z1AT=+TFp6kM5xw5Xv_oWZFSqAuEKx=-=a2A@HIDDEN> <5181f95e-61e7-c8c4-6389-44ee57e0c749@HIDDEN> <CALDnm51p7awjuw4vFMC=UByXnFUYMHsecUaSrT=Jiii5S3fgxQ@HIDDEN> <31cadbfd-d086-a04f-0ed9-17ce70b4282c@HIDDEN> <CALDnm5336QOoUf740oX0x+We2BJQihtOnGLzFzFe8QEuYAMw8w@HIDDEN> <bae801f2-bc7b-dc33-d655-ba6b423050d8@HIDDEN> <CALDnm534Mpsif=y7-Gq0r+UJSS4UkkFgwHVH+FJ4u1kvvpq3oQ@HIDDEN> <15a867ba-5a0f-9852-0296-b4c809baac7b@HIDDEN> <CALDnm52uQ6t_bBxTa5R-RKc_W8Oow_a8mpBaPrsf1a_dXz5ySw@HIDDEN> <2a144a08-eb41-22ee-ddf0-59ad1f3222f0@HIDDEN> In-Reply-To: <2a144a08-eb41-22ee-ddf0-59ad1f3222f0@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Thu, 2 Nov 2023 16:09:10 +0000 Message-ID: <CALDnm51CHHqwxMBNds_GhtWHuhz-nRqgWfpX+O9xHBRJFp2uzQ@HIDDEN> Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Dmitry Gutov <dmitry@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Thu, Nov 2, 2023 at 4:03=E2=80=AFPM Dmitry Gutov <dmitry@HIDDEN> wrot= e: > > That's debatable, I like to be able to type 'vcdiff' and > > see all the commands that vc.el offers for diffing things. > > That also works for Orderless and "vc dif". Ah, but the order in which all these commands appear is arbitrary, if I understand correctly. It must be, since there's no sorting, right? Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 2 Nov 2023 16:04:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 02 12:04:46 2023 Received: from localhost ([127.0.0.1]:55836 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qyaBV-0007vG-QB for submit <at> debbugs.gnu.org; Thu, 02 Nov 2023 12:04:46 -0400 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:47249) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1qyaBP-0007ur-RK for 47711 <at> debbugs.gnu.org; Thu, 02 Nov 2023 12:04:40 -0400 Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.west.internal (Postfix) with ESMTP id CDD913200909; Thu, 2 Nov 2023 12:03:54 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 02 Nov 2023 12:03:55 -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= 1698941034; x=1699027434; bh=D9DTsptfYIWRomrrc4iwHTC3jwTm6k1WJZX n8RF/GSo=; b=Flwr7zOb2MrV1A2MP/TNsFL477GBn+JMbbTU7OTQIbVMkT2xQ9Y 5m1TUJik2EwuTd4vJR6byBI+YRvV5/btVhLbqb18xJDD66VBtuvUEZ7RMB9KjsyZ /MhWk7G5tAMEX+tb3V/5wd2NVrsv1egb200LzecikrpEe1ExfWGIf4gtz8V5NAjE cHGPjSP7wWsmUAD3JrEXyi8LHD5CUvRjBlcmCd4cb6urG8nt43JsiXqCNFFATE/W E/MIku2K07wbfCCnhI9vCNq7bBgi3BqFW8+KsuEg1n0USteDDSm66j2CO4vyto/r Mt+PSvcK6Gt7JKZxXiNK8E2Pu/gdl16MLxw== 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= 1698941034; x=1699027434; bh=D9DTsptfYIWRomrrc4iwHTC3jwTm6k1WJZX n8RF/GSo=; b=WvglKssqyceROS6yfH3rbyTjMC4B46CsLoda+jfsQVCsna/TxLt anUdDOyEo5uv3FXJrst+cmZsJtFT4OGPdTpyd0IgEM+rmbZxPJCqYPi40AaTWUla UiicLFB04JfUaHZ9hVF31xakxsTJLxo1OUYk2VEY1pbThiTNwr/sm1vIz/kV9qtU uP0IdKjok7psxMjydyiATwAqoWMBZYd0TiwDE/FRlEyVfG/qdfYocatj46iUxWcD z4jZfhFz+b6lQYUWKmv96BlbS7+0nVVEZiBI6hkMVytwDp3zz+xhUY5L8q+uUzYC gZBmqevgdbbllkgzEKZbCAM+R3BfLEGeG2Q== X-ME-Sender: <xms:achDZU-rCwxPnvNU5Eb8DUVVNPmIvL71rhse4ZKwkqitxzvTaiQOFA> <xme:achDZcsGq1Pw5Ly82BMEhdd8QHd2K4EMrKPGxh6bCBLZWWZTy05i2-RRsXT1CILpb hnzTTLmKvVYbhW6ZiE> X-ME-Received: <xmr:achDZaCecIxE4EsgSYNIgXoiq191X1mj-OKieeo_ojLWJVSDPjsBuvvKqWopaeI> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddtiedgkeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhephfffheeljeffgeffueeghfekkedtfffgheejvdegjeettdduheeufffggfef jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: <xmx:achDZUe22jrrn9vMPvfYgAsbi2_qsG_mPJX0wpMF88RQA1499OjKvg> <xmx:achDZZMqm2amNnLyucYkqOcG1cSIPTS4ixKuXJCbaYAhBrbMwEScmA> <xmx:achDZenOu1JjecX3dnI-Y5bvQI8ih81rsNRtH0AVBKRCrY5D4uNOCA> <xmx:ashDZarIDdTY-niX5kxvIG9oJshupX84HSKltCEhf_WMVrDNVKe2Jw> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 2 Nov 2023 12:03:52 -0400 (EDT) Message-ID: <2a144a08-eb41-22ee-ddf0-59ad1f3222f0@HIDDEN> Date: Thu, 2 Nov 2023 18:03:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <877cn8asud.fsf@HIDDEN> <c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN> <8734xtauqj.fsf@HIDDEN> <eeabbe1f-7b2d-ade5-949c-05aea0ba85a9@HIDDEN> <CALDnm51kS6p9V7z1AT=+TFp6kM5xw5Xv_oWZFSqAuEKx=-=a2A@HIDDEN> <5181f95e-61e7-c8c4-6389-44ee57e0c749@HIDDEN> <CALDnm51p7awjuw4vFMC=UByXnFUYMHsecUaSrT=Jiii5S3fgxQ@HIDDEN> <31cadbfd-d086-a04f-0ed9-17ce70b4282c@HIDDEN> <CALDnm5336QOoUf740oX0x+We2BJQihtOnGLzFzFe8QEuYAMw8w@HIDDEN> <bae801f2-bc7b-dc33-d655-ba6b423050d8@HIDDEN> <CALDnm534Mpsif=y7-Gq0r+UJSS4UkkFgwHVH+FJ4u1kvvpq3oQ@HIDDEN> <15a867ba-5a0f-9852-0296-b4c809baac7b@HIDDEN> <CALDnm52uQ6t_bBxTa5R-RKc_W8Oow_a8mpBaPrsf1a_dXz5ySw@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <CALDnm52uQ6t_bBxTa5R-RKc_W8Oow_a8mpBaPrsf1a_dXz5ySw@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.2 (---) On 02/11/2023 17:58, João Távora wrote: > On Thu, Nov 2, 2023 at 3:36 PM Dmitry Gutov <dmitry@HIDDEN> wrote: >> >> On 02/11/2023 17:24, João Távora wrote: >>> On Thu, Nov 2, 2023 at 2:40 PM Dmitry Gutov<dmitry@HIDDEN> wrote: >>> >>>> IOW, this whole approach results in stricter matching with fewer >>>> results, so a smarter sort isn't that necessary. >>> Just curious, so in orderless, what do I type to quickly select >>> M-x vc-diff or M-x vc-version-diff or M-x vc-ediff? >>> >>> In flex I just type "vcdiff" and these results normally bubble to the top. >> >> I'm not really a user of it (yet?), but >> >> "vc-dif" or "vc dif" matches the first one, and "vc-ver" or "vc vers" >> matches the second one. > > So "vc dif" doesn't also match 'vc-ediff' and 'vc-version-diff'? It does, of course. I just described what I imagine is the more common scenario: continue typing until the command you want is at the top, so you don't have to reach for C-n/C-p or the arrow keys. >> Not a lot of difference in the amount of typing, >> but a little more control on the part of the user. > > That's debatable, I like to be able to type 'vcdiff' and > see all the commands that vc.el offers for diffing things. That also works for Orderless and "vc dif". And from that you can continue to "vc dif ver", which brings "vc-version-diff" to the top, that's something unique to Orderless, I suppose.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 2 Nov 2023 15:59:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 02 11:59:06 2023 Received: from localhost ([127.0.0.1]:55831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qya65-0007jb-Sy for submit <at> debbugs.gnu.org; Thu, 02 Nov 2023 11:59:06 -0400 Received: from mail-lf1-x135.google.com ([2a00:1450:4864:20::135]:54524) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1qya64-0007j4-1M for 47711 <at> debbugs.gnu.org; Thu, 02 Nov 2023 11:59:04 -0400 Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-507a3b8b113so1325130e87.0 for <47711 <at> debbugs.gnu.org>; Thu, 02 Nov 2023 08:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698940702; x=1699545502; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=TEd2kQFcCxw9b3va+HA1daS416a0wxKDqd0jYceEW7s=; b=fg+PULroa+hdt3OLRSoNocJJHd1ShNAJMzhi5gApTEnU0K4PswUoopMgHsXSTj3F38 THCOQcEDN4FaV7j79LG6xrUSt1TfOtixE1Zl7yAXeRV3RnkZfZXPBwkC6H6+qr2+BvFv m1qlTYiW0gruphkdS3iggQkkdKoCAYL79SxYMuo+pISyxRXE0vkmyJEuEwSg44yYTfYb KAH7+4UwyzPxm4amUaMO4SiE79I3dWIFMp1J98bNo5Lnr7weq6vDGc3om5LRIRCXiaf7 qn5gowp7JEap1GBAjWzDzafKPCVaGiWxPt3CkrHEvPArzvNuh9YpMrHYp1DtxItM9nrW TfSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698940702; x=1699545502; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=TEd2kQFcCxw9b3va+HA1daS416a0wxKDqd0jYceEW7s=; b=LOSwWoTouuIwy5pFPR835ua8/YeFQgULxUsMw79gJUE4lJ9Ltq90i3/X6zr1szYUu/ F96iLlQpxaF9HyGWTelErWgAJDTgWzQQuUE8RmGvwXfWV3Rq1VsI/SfMjrhimSlBJne1 aHROM8MSJQmA2kTg7Ub6R7vFcaQU47x3ve+yisonoFNi1GH7VCgO6v03to1oM95BGFTX yWrQn+kqCKLhF7l8ugCCYL1tGsRAMAaV2uwLxvnEPiN/fPrnbyzb8t6QsoYUoG99rG6L 8mI3raTI5fhdAHf0GWP/zt9Lb9JGI3csHzkJWV5HLCdYAq7QINvbaPcGAFy9Q7zHOUMv ikkg== X-Gm-Message-State: AOJu0YzZkuvwTLv9zVyBfndhQ5Y0mTN8u52grlaaGKlssPf7qMhvG9OR 0EWv366/3fW/kPCWfQxgAV+NQUt9tSp9iCJTqzI= X-Google-Smtp-Source: AGHT+IFlLFogtcaomCA5CQP+g67yo93tX+tvWPPqLw1g+b3krNREwXVAaOzHt7cVIUkbeb8KE16IymwaDr0arAhHZyY= X-Received: by 2002:a05:6512:2525:b0:500:ac10:1641 with SMTP id be37-20020a056512252500b00500ac101641mr22613911lfb.46.1698940702414; Thu, 02 Nov 2023 08:58:22 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <877cnafv39.fsf@HIDDEN> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <877cn8asud.fsf@HIDDEN> <c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN> <8734xtauqj.fsf@HIDDEN> <eeabbe1f-7b2d-ade5-949c-05aea0ba85a9@HIDDEN> <CALDnm51kS6p9V7z1AT=+TFp6kM5xw5Xv_oWZFSqAuEKx=-=a2A@HIDDEN> <5181f95e-61e7-c8c4-6389-44ee57e0c749@HIDDEN> <CALDnm51p7awjuw4vFMC=UByXnFUYMHsecUaSrT=Jiii5S3fgxQ@HIDDEN> <31cadbfd-d086-a04f-0ed9-17ce70b4282c@HIDDEN> <CALDnm5336QOoUf740oX0x+We2BJQihtOnGLzFzFe8QEuYAMw8w@HIDDEN> <bae801f2-bc7b-dc33-d655-ba6b423050d8@HIDDEN> <CALDnm534Mpsif=y7-Gq0r+UJSS4UkkFgwHVH+FJ4u1kvvpq3oQ@HIDDEN> <15a867ba-5a0f-9852-0296-b4c809baac7b@HIDDEN> In-Reply-To: <15a867ba-5a0f-9852-0296-b4c809baac7b@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Thu, 2 Nov 2023 15:58:10 +0000 Message-ID: <CALDnm52uQ6t_bBxTa5R-RKc_W8Oow_a8mpBaPrsf1a_dXz5ySw@HIDDEN> Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Dmitry Gutov <dmitry@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Thu, Nov 2, 2023 at 3:36=E2=80=AFPM Dmitry Gutov <dmitry@HIDDEN> wrot= e: > > On 02/11/2023 17:24, Jo=C3=A3o T=C3=A1vora wrote: > > On Thu, Nov 2, 2023 at 2:40=E2=80=AFPM Dmitry Gutov<dmitry@HIDDEN> = wrote: > > > >> IOW, this whole approach results in stricter matching with fewer > >> results, so a smarter sort isn't that necessary. > > Just curious, so in orderless, what do I type to quickly select > > M-x vc-diff or M-x vc-version-diff or M-x vc-ediff? > > > > In flex I just type "vcdiff" and these results normally bubble to the t= op. > > I'm not really a user of it (yet?), but > > "vc-dif" or "vc dif" matches the first one, and "vc-ver" or "vc vers" > matches the second one. So "vc dif" doesn't also match 'vc-ediff' and 'vc-version-diff'? > Not a lot of difference in the amount of typing, > but a little more control on the part of the user. That's debatable, I like to be able to type 'vcdiff' and see all the commands that vc.el offers for diffing things. But to each their own, of course Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 2 Nov 2023 15:36:57 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 02 11:36:57 2023 Received: from localhost ([127.0.0.1]:55821 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qyZkf-00075o-5d for submit <at> debbugs.gnu.org; Thu, 02 Nov 2023 11:36:57 -0400 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:39587) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1qyZkb-00075T-6K for 47711 <at> debbugs.gnu.org; Thu, 02 Nov 2023 11:36:55 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 0345B3200933; Thu, 2 Nov 2023 11:36:11 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 02 Nov 2023 11:36:12 -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= 1698939371; x=1699025771; bh=UyNTS+jcWbIeql1ECNg1matRKoUE2XnqHnF ebXsb16I=; b=MABrVDJPPJltTGtpM5XwqIUj6RVQPgLEyq0T/DrZz6kb15WM06g rJ0+o5R9dFipxVjUSnY52cXthVKzeLeT1JsHshot8i9iobg4gCcaye6TShk3sJXO zvAJUBOZkTHJMeJZce/G481EZFbVdL1au4diDHBKpSi5a0uqXg3bAYfb4a1CU8Cr vMgNEHRrz7tR7vpIv4GddIyBnjeeD4cYgu5KRK8yx6u1vBXi0E9zTgOEqmq0y2vt I059JfoYBzBU9sv6kOdn8+qx28rgo/EejRpm0W+d+wJVpExkzIzOgtGC8PRKtHRm DbLVgbtzfU9k2sZ5NSELxNqFlUn8/3T6uCg== 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= 1698939371; x=1699025771; bh=UyNTS+jcWbIeql1ECNg1matRKoUE2XnqHnF ebXsb16I=; b=Fq70gk/KRhMWgqJ2nNQD/lII9mT+16DfSAvwViJ2iAwAzKaZ5Y/ CReyqln6wndM/pv0fwc4lVbmESAgRtkRjHX0aLRJZimb3g8lO14IW6tDf6Y5HaEa 326fQFdAj7Dfmxk900SyMT+AZ7E5PeFiEbFOWPKtLMc8Qh29N3wMwmNfdghcs0DG 5wkXCgZvyEg7o/X9glTZyL2CrqsHLBQ8H7kaaGbhXazRtJXL0oGpotD227eheJNi WUoIPV+FR3AWo7Yfs4MYy4ouHlXvZ+jrDNYLmjAAaGJmg1dn0XkkgLgCAGzrK4Qv 99Eta+QHKKqT/otC3B/yHBXwVFszHNxdwjw== X-ME-Sender: <xms:6sFDZaHDigqmDE8PTbjK3fFQqjVAx5p-6jtsxXbeixKhGne7PneHcw> <xme:6sFDZbUNOmdpz_Cw0cugChRWiImCoigp4pY9-ekNahJBwQ5M8qLX2ywOzT5jxwq7s on0EczjQMIVE8EfcbE> X-ME-Received: <xmr:6sFDZULMRKzDxf-07O_iEwAPrpUgZR-Xztrrfj4hIMhFdaf-OXBSey4ZVaMEtr8> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddtiedgjeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhephfffheeljeffgeffueeghfekkedtfffgheejvdegjeettdduheeufffggfef jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: <xmx:6sFDZUGwifZ5T_V3MovoRCIQA9PKZ19OX2wpxbIe6ioErFBOL9Q5kg> <xmx:6sFDZQU2KsPUWrp3ujkQW3auHfXZtWumABhVsmhj-ROMRfkKx4B2Uw> <xmx:6sFDZXMaBKlGDgga3OrGAit7n9yLRUU3BeNFxk4jjk_PTw6DBSecHw> <xmx:68FDZXQ7PHtpkUDzSSdqYBF_HIFFEX7XyNHERery0qz1__mcOdEFkw> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 2 Nov 2023 11:36:08 -0400 (EDT) Message-ID: <15a867ba-5a0f-9852-0296-b4c809baac7b@HIDDEN> Date: Thu, 2 Nov 2023 17:36:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <877cnafv39.fsf@HIDDEN> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <877cn8asud.fsf@HIDDEN> <c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN> <8734xtauqj.fsf@HIDDEN> <eeabbe1f-7b2d-ade5-949c-05aea0ba85a9@HIDDEN> <CALDnm51kS6p9V7z1AT=+TFp6kM5xw5Xv_oWZFSqAuEKx=-=a2A@HIDDEN> <5181f95e-61e7-c8c4-6389-44ee57e0c749@HIDDEN> <CALDnm51p7awjuw4vFMC=UByXnFUYMHsecUaSrT=Jiii5S3fgxQ@HIDDEN> <31cadbfd-d086-a04f-0ed9-17ce70b4282c@HIDDEN> <CALDnm5336QOoUf740oX0x+We2BJQihtOnGLzFzFe8QEuYAMw8w@HIDDEN> <bae801f2-bc7b-dc33-d655-ba6b423050d8@HIDDEN> <CALDnm534Mpsif=y7-Gq0r+UJSS4UkkFgwHVH+FJ4u1kvvpq3oQ@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <CALDnm534Mpsif=y7-Gq0r+UJSS4UkkFgwHVH+FJ4u1kvvpq3oQ@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.2 (---) On 02/11/2023 17:24, João Távora wrote: > On Thu, Nov 2, 2023 at 2:40 PM Dmitry Gutov<dmitry@HIDDEN> wrote: > >> IOW, this whole approach results in stricter matching with fewer >> results, so a smarter sort isn't that necessary. > Just curious, so in orderless, what do I type to quickly select > M-x vc-diff or M-x vc-version-diff or M-x vc-ediff? > > In flex I just type "vcdiff" and these results normally bubble to the top. I'm not really a user of it (yet?), but "vc-dif" or "vc dif" matches the first one, and "vc-ver" or "vc vers" matches the second one. Not a lot of difference in the amount of typing, but a little more control on the part of the user.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 2 Nov 2023 15:25:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 02 11:25:01 2023 Received: from localhost ([127.0.0.1]:55808 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qyZZ7-0006ly-6k for submit <at> debbugs.gnu.org; Thu, 02 Nov 2023 11:25:01 -0400 Received: from mail-lf1-x12a.google.com ([2a00:1450:4864:20::12a]:47545) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1qyZZ4-0006lT-Gn for 47711 <at> debbugs.gnu.org; Thu, 02 Nov 2023 11:25:00 -0400 Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-50930f126b1so1245516e87.3 for <47711 <at> debbugs.gnu.org>; Thu, 02 Nov 2023 08:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698938657; x=1699543457; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=pDB5mgfgXIy8RtAvHbdKj50e+WyAV3ny+1tn1LTTWSU=; b=QTHftTPWBmyN5t6hCGO09aWlcRcIHVBmftB5wS/BNmvgyfmDjguFJOl/iv4HLO+JQd mV6wefq1TNu0nESCrnbYGgLIzxjb+JK5YFu6ih9BUwSBWe46tosuXTYCHwD1sAj3wfVp DTq0b83C/IXXfwJxObKNpnxDxA3HHqgfKigiYhAnmfhKusUh6YUTkcw8MkO5aPaSv3s9 UelxkTT2nQCv+REMee3dOoPhVvr1fkrIkrabwR46Rr0Je9NTZoHYDgcLD4q2pjll6A+1 f6SozFAtWv8Eveajhifs7fVpOAjfb2ub5jMubPQRvRR1JCKJ1gEnzgnqULCkdGlFv9q+ CmqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698938657; x=1699543457; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pDB5mgfgXIy8RtAvHbdKj50e+WyAV3ny+1tn1LTTWSU=; b=iuHh3qqvGrGmlZrWEx83s0oH/ZwYu2rpHYiO9QfJ84nhsEL0QdtT+2lQue3qgLxbte dFddXtHcfeKFM0k21D+FdUJSC4I1MO45az//spgF1PTBDErXAHHbIdwnV2gQERK55Z0s QsCYvHMeYjocxdFtHcmbhE5OH/PAF+SSwle5RmyKBZa3gqODlHR5jyvbIJMlcUHu5OMo SpP3DKz25uLLd7vMsGr8k0Fzf41Aa7+DVRuKJOfIfF08aOmsiJj3NRx5s+tN4ZhyO5Kb 9+eoy/53MlPwFEC4MVIQaVNMlng/kqU2cghlapUkN+Xuus8oC3kH18P9xViHLZ4tCHEe bsqQ== X-Gm-Message-State: AOJu0YwWa7c3s2bE5+evmjFQ7LaNOTN+GQGlqJRYL2v5NIZ8iVfys+dE Q34xagmBjy5PgpgOvwPSQq48QabGm8t9TLLXv7M= X-Google-Smtp-Source: AGHT+IFS7WLV6LekPrxpETWnlYnGQgm3PPrGLp9wk0JGMpWC1bBe5lW5zdRcpvEVrvUYZ4/j/MJ16zeR0OI3eadzAic= X-Received: by 2002:a05:6512:60f:b0:507:a9ae:5c2 with SMTP id b15-20020a056512060f00b00507a9ae05c2mr14295177lfe.44.1698938657118; Thu, 02 Nov 2023 08:24:17 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <877cn8asud.fsf@HIDDEN> <c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN> <8734xtauqj.fsf@HIDDEN> <eeabbe1f-7b2d-ade5-949c-05aea0ba85a9@HIDDEN> <CALDnm51kS6p9V7z1AT=+TFp6kM5xw5Xv_oWZFSqAuEKx=-=a2A@HIDDEN> <5181f95e-61e7-c8c4-6389-44ee57e0c749@HIDDEN> <CALDnm51p7awjuw4vFMC=UByXnFUYMHsecUaSrT=Jiii5S3fgxQ@HIDDEN> <31cadbfd-d086-a04f-0ed9-17ce70b4282c@HIDDEN> <CALDnm5336QOoUf740oX0x+We2BJQihtOnGLzFzFe8QEuYAMw8w@HIDDEN> <bae801f2-bc7b-dc33-d655-ba6b423050d8@HIDDEN> In-Reply-To: <bae801f2-bc7b-dc33-d655-ba6b423050d8@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Thu, 2 Nov 2023 15:24:05 +0000 Message-ID: <CALDnm534Mpsif=y7-Gq0r+UJSS4UkkFgwHVH+FJ4u1kvvpq3oQ@HIDDEN> Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Dmitry Gutov <dmitry@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Thu, Nov 2, 2023 at 2:40=E2=80=AFPM Dmitry Gutov <dmitry@HIDDEN> wrot= e: > IOW, this whole approach results in stricter matching with fewer > results, so a smarter sort isn't that necessary. Just curious, so in orderless, what do I type to quickly select M-x vc-diff or M-x vc-version-diff or M-x vc-ediff? In flex I just type "vcdiff" and these results normally bubble to the top. > > I addressed all your docstring suggestions, fixed a bug and significant= ly > > simplified the code in the latest version of the patch. I also > > removed the instrumentation in icomplete.el. Patch attached here > > and pushed to feature/completion-lazy-hilit. > > Thank you. I don't see that the bug was, but deferring the scoring even > in the eager highlighting case looks sensible (why not, indeed, if the > performance is no worse). The bug was in the eager highlighting case. Wasn't sorting at all. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 2 Nov 2023 14:41:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 02 10:41:37 2023 Received: from localhost ([127.0.0.1]:55705 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qyYt3-0005PX-CC for submit <at> debbugs.gnu.org; Thu, 02 Nov 2023 10:41:37 -0400 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:37119) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1qyYsm-0005Ot-FD for 47711 <at> debbugs.gnu.org; Thu, 02 Nov 2023 10:41:31 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 738D8320046F; Thu, 2 Nov 2023 10:40:34 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 02 Nov 2023 10:40:34 -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= 1698936033; x=1699022433; bh=EWF5POCf3+e108eOVZ6h/3WW3qmiCykTFTG MuCc9o1U=; b=QlC2BTQRv5COR5T17NBS5PzKPlnGRt8AgUPiwwcq8Z7TW8P4JWb oMFyJ/VqCblJK4ss4flCARoQor4inVuRmkP+2FxIDjm3Mx/ejWREYdrcsPbfojN3 hgvhye5YHtPd/7gvR7uhnWkevS9+AcbTArgAlEYVIXBq5hCZbJxkmNpx+6juxu1J zWudnpjP5uysDEMhQNURE7IiWPnk9NxZc+unY4GzEP1+ma1Q7U83L0dh64+oPxVM boF6ohbeH2Q2+k6Jkw4C0s9JRtM4gkV+TWgeROUrNIXPiD+e5EPd/G72U0s/J77T uMwcAcd8iOHqzLJJ0HLBGwKo5+OXdLw7qHQ== 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= 1698936033; x=1699022433; bh=EWF5POCf3+e108eOVZ6h/3WW3qmiCykTFTG MuCc9o1U=; b=Ieog6pUFNQ2DBf+Sfbq8rj11VbwWAfQYe/2Wsg/c0wJqSOO+mkM dArfmWTDfbFHaOS1JAn39RWY+hml/n3nZOb24ynWcs+jrOL4+C2EL6wiFef1MbAj X77fn1zt53rfFEvCWivfTbCXq8wSBSEa6GYM8ruBROY+vIRw9AfYcJIYR9He0d2Y dZ8Dn5YNg/Ott9LNQv+zL41KFbOhLIGzuNyDgs8N5x7iqpKlQh8kRPPKf2QVzzRp bUgIKa/W1Mfrfmba9yjdthdPbSA7ZpIZYuFrEibzDaaddNfIRhq4g+fUUZyFtyHr 03ZNBElqMFTHP/yEC11Aj+5fBsg/wX/c8TA== X-ME-Sender: <xms:4LRDZTgO7xO3MafKuvTYV06T9iF1tw-eOdsYTGqPZj5R9rWTMMTnlg> <xme:4LRDZQB6JTf2sMsI4x644ss-ZCpWWO1gGGxPSUYVAsO9Y_NHZVuz0UqdEXIX_VofJ Ryki15sNEZ8wL5um3M> X-ME-Received: <xmr:4LRDZTFK8ZUyz1-jmTos7zgQ4gY1F7nwTv76x1an_sElDNDmr_mUmGEWqn4pytQ> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddtiedgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhephfffheeljeffgeffueeghfekkedtfffgheejvdegjeettdduheeufffggfef jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: <xmx:4LRDZQQJdMhLH5XvP7dk_Piw2BD6bSi8dLeW0Z9MdFKzLsF69u_69w> <xmx:4LRDZQwzdZ2zyziae4Adcl_mi9bD0ryinX47qXWyQ0e4IonkACrctA> <xmx:4LRDZW4guk7BZxqVSkA7sLKAA8nf_0fABzRraZ6ysDm56qvVe3hrFg> <xmx:4bRDZc_lsKfBmsK0gxt86oGWS4xr8G3CQfSMSskbywUqN19Miof2Ig> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 2 Nov 2023 10:40:31 -0400 (EDT) Message-ID: <bae801f2-bc7b-dc33-d655-ba6b423050d8@HIDDEN> Date: Thu, 2 Nov 2023 16:40:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <877cn8asud.fsf@HIDDEN> <c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN> <8734xtauqj.fsf@HIDDEN> <eeabbe1f-7b2d-ade5-949c-05aea0ba85a9@HIDDEN> <CALDnm51kS6p9V7z1AT=+TFp6kM5xw5Xv_oWZFSqAuEKx=-=a2A@HIDDEN> <5181f95e-61e7-c8c4-6389-44ee57e0c749@HIDDEN> <CALDnm51p7awjuw4vFMC=UByXnFUYMHsecUaSrT=Jiii5S3fgxQ@HIDDEN> <31cadbfd-d086-a04f-0ed9-17ce70b4282c@HIDDEN> <CALDnm5336QOoUf740oX0x+We2BJQihtOnGLzFzFe8QEuYAMw8w@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <CALDnm5336QOoUf740oX0x+We2BJQihtOnGLzFzFe8QEuYAMw8w@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -1.5 (-) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.2 (---) On 02/11/2023 11:48, João Távora wrote: > On Wed, Nov 1, 2023 at 10:45 PM Dmitry Gutov <dmitry@HIDDEN> wrote: > >>> If orderless (which I've never tried), does some kind of scoring of >>> completions, it probably also needs the same complications of flex. >> >> Turns out, Orderless doesn't do any scoring or sorting. Only filtering. > > Interesting, so if I M-x d i f f with orderless I don't get results in > any particular order? Right. And input "diff" actually results in prefix-only matching. But if the input contains space (or any other pre-configured delimiter character), then it's translated to a set of substring matches, performed in any order. So "diff mode" does not translate to ".*diff.*mode", but a more complex regexp with all permutations. IOW, this whole approach results in stricter matching with fewer results, so a smarter sort isn't that necessary. >>>>>> Anyway, have you looked into what it would take to solve it? >>>>> >>>>> No, naively, I just think it's a similar situation of display and business >>>>> logic being mixed up. Presumably the quoted stuff is just for insertion >>>>> (and display?), and the unquoted stuff is what patterns/scoring should >>>>> operate on. >>>> >>>> Apparently it's good for insertion, but according to that comment inside >>>> the function, the unquoted stuff might actually be better for display. >>> >>> No idea what the unquoted stuff is for, so I haven't really tested it. >> >> A couple of scenarios: > > Thanks. Then I think it is working OK, but it would be safer if you were > to double-check yourself, as I really never use this functionality. They look okay, yes. I imagine Daniel also tested the 'completion--unquoted' solution before offering his patches. > I addressed all your docstring suggestions, fixed a bug and significantly > simplified the code in the latest version of the patch. I also > removed the instrumentation in icomplete.el. Patch attached here > and pushed to feature/completion-lazy-hilit. Thank you. I don't see that the bug was, but deferring the scoring even in the eager highlighting case looks sensible (why not, indeed, if the performance is no worse).
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 2 Nov 2023 11:13:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 02 07:13:18 2023 Received: from localhost ([127.0.0.1]:54032 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qyVdS-0005Me-8y for submit <at> debbugs.gnu.org; Thu, 02 Nov 2023 07:13:18 -0400 Received: from mail-lf1-x12a.google.com ([2a00:1450:4864:20::12a]:61785) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1qyVdL-0005MK-VC for 47711 <at> debbugs.gnu.org; Thu, 02 Nov 2023 07:13:12 -0400 Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-507c5249d55so953202e87.3 for <47711 <at> debbugs.gnu.org>; Thu, 02 Nov 2023 04:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698923547; x=1699528347; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=uxxqBMGhl1VrYLzij/h26zZyVwBnfQpBZxB1M1LMwX8=; b=g6rLU21YoeF4c4uLqmaY4YUlpkNgFnAOGM46HPID6VGWOpS5Nw5rjusIWYowqXtuHq bU/WH+XmAjg6HLUweQ0Yzyqszydc5FCJY063pN6khYk5giHAzXq9nlZY42hxgIn6ZrsW db5kQTr0WwdqjixYrysv0zWsHKVaDGoGm47DU/UWKaWUzrZe4dZEWT4heCYiOUvUfpN6 H4NtCeJCmNx8DU4ctkEgenxA/M8r2lHqSPHZ34xsioCuWUmwaDsQOJj1F8KGHL6ZfX0t eYLRtH1pY1E10rzlEGDQusQg84BOPiHCUDyjc46QHx3Dyw/axAE/QBuIG6+QJXZDOF0U oS+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698923547; x=1699528347; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uxxqBMGhl1VrYLzij/h26zZyVwBnfQpBZxB1M1LMwX8=; b=RsbCg1L9bnbpoKhVz+1ZTqkHgRolOB8vrQiDnl23gajDrqdN4mBM8QjWtzHaokdY9w 8X9BXCuojLvQdK+LeD49YolP1W4lmoVUdo344Z+pzjRcz9eK7Bedidrq3solliW75pN/ KmkIBhxUaMEIKvGBRXrQ3jwXlHIibAMgLGdWRM62Kg8m5hwpuKoccX7EQO3+93tOEWh3 3V6vlGluhM6OWThgIiUXGwYqbF2uT/DleAYwGuTZMpVF75vMbSportXqlGfGqEEulwX/ Rh47oDKQW679ODdrWmfUzHRKPE7GV0zCkvKa2Z+xkuKpI8JN/et0Cpd93l32MpDvUrJE qApQ== X-Gm-Message-State: AOJu0YzZHRQik12KpR8HyqKInCkdVerQoojuEvgN/44wdYabNVxP3hxa lYc4P3pt9YGc2MfBGeq8+6aLRbJ7+m252+SiOc8= X-Google-Smtp-Source: AGHT+IEkeQ89Nt6qsbvkR21wcSTCIl485m5V6Y+z5mDwzxg5QtLqyDB5v3kP0Mr4HBPuKfuf4iE3K+HALdFgFDQInp0= X-Received: by 2002:a19:ca49:0:b0:507:c9d5:39a9 with SMTP id h9-20020a19ca49000000b00507c9d539a9mr12694997lfj.52.1698923546828; Thu, 02 Nov 2023 04:12:26 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <877cn8asud.fsf@HIDDEN> <c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN> <8734xtauqj.fsf@HIDDEN> <eeabbe1f-7b2d-ade5-949c-05aea0ba85a9@HIDDEN> <CALDnm51kS6p9V7z1AT=+TFp6kM5xw5Xv_oWZFSqAuEKx=-=a2A@HIDDEN> <5181f95e-61e7-c8c4-6389-44ee57e0c749@HIDDEN> <CALDnm51p7awjuw4vFMC=UByXnFUYMHsecUaSrT=Jiii5S3fgxQ@HIDDEN> <31cadbfd-d086-a04f-0ed9-17ce70b4282c@HIDDEN> <CALDnm5336QOoUf740oX0x+We2BJQihtOnGLzFzFe8QEuYAMw8w@HIDDEN> <835y2k8nyt.fsf@HIDDEN> <CALDnm52N8LeT65wmRVijbJ8xX_PxGgviX7rzCSQyGTsisnyXBQ@HIDDEN> <834ji48lrg.fsf@HIDDEN> In-Reply-To: <834ji48lrg.fsf@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Thu, 2 Nov 2023 11:12:15 +0000 Message-ID: <CALDnm50EDs348G_HXMbGcZfo-zyokamWu5iTG-R3xA_UVWP4KQ@HIDDEN> Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Eli Zaretskii <eliz@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: dmitry@HIDDEN, 47711 <at> debbugs.gnu.org, monnier@HIDDEN, mail@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Thu, Nov 2, 2023 at 10:58=E2=80=AFAM Eli Zaretskii <eliz@HIDDEN> wrote: > > After some rounds of benchmarking and discussion, Dmitry and I > > think the latest version of the patch should be installed. > > Are there any problematic aspects of the patch that need to be > discussed or considered before installing the patch? > > IOW, why are you soliciting our opinions, instead of just going ahead > and installing? No particular reason. Dmitry suggested that we do, and you participated in this discussion a while back, and I know you normally have some useful comment or two. > > In a nutshell it solves the performance problem of overly eager > > completion highlighting with minimal changes to the completion API. > > It looks to me like it adds a new feature, not just solves a > performance problem? > > Some minor comments to the patch itself: > > > +(defvar-local completion-lazy-hilit nil > > + "If non-nil, request completion lazy highlighting. > > + > > +Completion-presenting frontends may opt to bind this variable to > > +non-nil value in the context of completion-producing calls (such > > +as `completion-all-completions'). This hints the intervening > > +completion styles that they do not need to > > +fontify (i.e. propertize with the `face' property) completion > > +strings with highlights of the matching parts. > > If this is intended to be bound by frontends, why is it defvar-local? > I thought let-binding buffer-local variables is a tricky business that > could have unexpected results? Good catch! It shouldn't be defvar-local indeed, not with this latest version. See, glad I called you ;-) > Also, I think this doc string should reference > completion-lazy-hilit-fn. > > > +(defvar completion-lazy-hilit-fn nil > > + "Used by completions styles honoring `completion-lazy-hilit'. > > This should mention "function", since just "Used to..." doesn't convey > that, and "-fn" could also mean "file name", not just "function". Makes sense. > > +(defun completion-lazy-hilit (str) > > + "Return a copy of completion STR that is `face'-propertized. > ^^^^^^^^^^^^^^^^^^ > Strange quoting. "face" is not a symbol that we want to have a link > to, is it? It's not a symbol we'll be referencing, but it's a symbol. I'll rewrite it. > > I see a few more places in the doc strings that will "need work", but > that can be done later. > > What did you want to say in NEWS about this? If it's just a > performance improvement, we don't normally mention them in NEWS. But it needs frontends to opt in, and that requires an non-breaking addition to completion API. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 2 Nov 2023 10:59:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 02 06:59:20 2023
Received: from localhost ([127.0.0.1]:54019 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qyVQ0-00050J-A1
for submit <at> debbugs.gnu.org; Thu, 02 Nov 2023 06:59:20 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:43386)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1qyVPw-000505-UX
for 47711 <at> debbugs.gnu.org; Thu, 02 Nov 2023 06:59:19 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1qyVPG-00087z-Rp; Thu, 02 Nov 2023 06:58:34 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
Date; bh=I33Lh/R2aQtq/3xrBnKGKKziPi42D4uQEohoZDPsPgA=; b=YXLiFlmHzcXNwmIOHcf8
DvedO5AF2XQDT9jtikgXzgLWK7hX/98EA60hGD2vQQ5Qw6J/7Yqs2/UKho30vPI8XkZkgTg4UOBg2
d3HrT0zsTwqaIPXFuJ6UeDmy5rF/D4GBsYEXVzwmUbM/bPakUNRxLyswT14xlVceY8P4UuguZPO1R
sW83UcyhnqvmNcyu0fUhdDyHvi/z9WOKV8lWloRjFS+02h3ayCP4W+Og5kJf6O2MfvAbGlHzTMF/1
6e8kyqL7P0UEEPe42D8xnm+84sDPSX+pC2saXJqhsEvn4oWKHEt2Vdv+q6uo+i5YwIVXTX3Cdrtf/
vXa7ygA+NjoJdg==;
Date: Thu, 02 Nov 2023 12:58:27 +0200
Message-Id: <834ji48lrg.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
In-Reply-To: <CALDnm52N8LeT65wmRVijbJ8xX_PxGgviX7rzCSQyGTsisnyXBQ@HIDDEN>
(message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Thu, 2 Nov 2023 10:39:53
+0000)
Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add
new `completion-filter-completions` API and deferred highlighting
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN>
<CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN>
<328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN>
<9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN>
<9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN>
<CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN>
<7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN>
<CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN>
<5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <877cn8asud.fsf@HIDDEN>
<c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN> <8734xtauqj.fsf@HIDDEN>
<eeabbe1f-7b2d-ade5-949c-05aea0ba85a9@HIDDEN>
<CALDnm51kS6p9V7z1AT=+TFp6kM5xw5Xv_oWZFSqAuEKx=-=a2A@HIDDEN>
<5181f95e-61e7-c8c4-6389-44ee57e0c749@HIDDEN>
<CALDnm51p7awjuw4vFMC=UByXnFUYMHsecUaSrT=Jiii5S3fgxQ@HIDDEN>
<31cadbfd-d086-a04f-0ed9-17ce70b4282c@HIDDEN>
<CALDnm5336QOoUf740oX0x+We2BJQihtOnGLzFzFe8QEuYAMw8w@HIDDEN>
<835y2k8nyt.fsf@HIDDEN>
<CALDnm52N8LeT65wmRVijbJ8xX_PxGgviX7rzCSQyGTsisnyXBQ@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47711
Cc: dmitry@HIDDEN, 47711 <at> debbugs.gnu.org, monnier@HIDDEN,
mail@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> From: João Távora <joaotavora@HIDDEN>
> Date: Thu, 2 Nov 2023 10:39:53 +0000
> Cc: dmitry@HIDDEN, mail@HIDDEN, monnier@HIDDEN,
> 47711 <at> debbugs.gnu.org
>
> > > Stefan, Eli, would you like to chime in?
> >
> > Chime in on what aspect(s) of this discussion (or the patch)?
>
> The patch condenses the results of the discussion of last week,
> as resuscitated by Dmitry after a 2-year long hiatus.
>
> After some rounds of benchmarking and discussion, Dmitry and I
> think the latest version of the patch should be installed.
Are there any problematic aspects of the patch that need to be
discussed or considered before installing the patch?
IOW, why are you soliciting our opinions, instead of just going ahead
and installing?
> In a nutshell it solves the performance problem of overly eager
> completion highlighting with minimal changes to the completion API.
It looks to me like it adds a new feature, not just solves a
performance problem?
Some minor comments to the patch itself:
> +(defvar-local completion-lazy-hilit nil
> + "If non-nil, request completion lazy highlighting.
> +
> +Completion-presenting frontends may opt to bind this variable to
> +non-nil value in the context of completion-producing calls (such
> +as `completion-all-completions'). This hints the intervening
> +completion styles that they do not need to
> +fontify (i.e. propertize with the `face' property) completion
> +strings with highlights of the matching parts.
If this is intended to be bound by frontends, why is it defvar-local?
I thought let-binding buffer-local variables is a tricky business that
could have unexpected results?
Also, I think this doc string should reference
completion-lazy-hilit-fn.
> +(defvar completion-lazy-hilit-fn nil
> + "Used by completions styles honoring `completion-lazy-hilit'.
This should mention "function", since just "Used to..." doesn't convey
that, and "-fn" could also mean "file name", not just "function".
> +(defun completion-lazy-hilit (str)
> + "Return a copy of completion STR that is `face'-propertized.
^^^^^^^^^^^^^^^^^^
Strange quoting. "face" is not a symbol that we want to have a link
to, is it?
I see a few more places in the doc strings that will "need work", but
that can be done later.
What did you want to say in NEWS about this? If it's just a
performance improvement, we don't normally mention them in NEWS.
Thanks.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 2 Nov 2023 10:41:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 02 06:41:05 2023 Received: from localhost ([127.0.0.1]:53997 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qyV8G-0004TR-Q4 for submit <at> debbugs.gnu.org; Thu, 02 Nov 2023 06:41:05 -0400 Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]:60788) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1qyV82-0004Sv-DQ for 47711 <at> debbugs.gnu.org; Thu, 02 Nov 2023 06:40:59 -0400 Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-50939d39d0fso928173e87.1 for <47711 <at> debbugs.gnu.org>; Thu, 02 Nov 2023 03:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698921605; x=1699526405; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=TR3Dgd+EP4doyiMPIzzj80ddBN0xS2Yibtfdm8tyvPQ=; b=ffi4vu0F2H22DMleLPWlx70pMSnpUsAC6qxvNRYhLfv9MogU1UdFJtf7rYf0BA7hxn Od6Pua/iDUQizckWexTRefbdEYSB8mmsccPND2rcx95TZAS5cbJZ5qHQxSQQK+DFBQiL ITiB4eZ+71IoHAB1gMPGkHLsP4zMRIb1ycP1d8w9bD0Smjvl3vz4HbqeEQSkMQJzXWx6 RXnb8NreWyU+H8UldBw/jVO9j8Ck7bCYBOX/cjzslo2S9IYvHRUvn0wwLhlZlGi//fgc /CnAiteooUCw5xkc8QUvzNbemkMZFv6HUg9uyIMrj/2g+agjTaFovvIKngqLEMoCXOWI QngQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698921605; x=1699526405; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=TR3Dgd+EP4doyiMPIzzj80ddBN0xS2Yibtfdm8tyvPQ=; b=MUINgI4yYzRHZRxU42fzjawSNQCeaFJeSd+RHsg2/vQ5dzxfy1JCYTS2QCUovIySTT xEjPzQFlFbmrhbs/z+MYFqtrjvbzYagZtm9EbLpuKx5ABnPHf/yVf5/UaPr5t41kDqRp 9fmZMSMrw9BvoxNj2LWHBUPMkUaXybzq37lyYMmL74YmwanLT0tIeG7Y7SeoOAV7gUgN Uk8AhlRp9hcDYxagHnCTKutDZecVrkX4QrxWeCDaJ7YYSl0BzacHBS1WfaIArIHobkk9 JNVxIrV1pNTSRnsg18NGm7MMkK/XouHZn4P6YgTZwxnbrdQD9m42jVFfPAwPvFR2UPz4 zncw== X-Gm-Message-State: AOJu0Yy/TBhCOq/gVOJy2WZjJ73PdFttEOCBiwl0QD9K6sYXBRIec4jS a+Q+lKlyLnidFO2o6X20B7y8SayUc7Xgd7FCOUk= X-Google-Smtp-Source: AGHT+IEAJo0qN0vJadD+4X+yFfEECxo8ImtLsaxJzKpq/Uu1JDGR6C6XO62NsKUbJgwrcZXNb4lp815oFFBYI98V4rA= X-Received: by 2002:a05:6512:4845:b0:500:acf1:b432 with SMTP id ep5-20020a056512484500b00500acf1b432mr14796226lfb.63.1698921605100; Thu, 02 Nov 2023 03:40:05 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <877cn8asud.fsf@HIDDEN> <c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN> <8734xtauqj.fsf@HIDDEN> <eeabbe1f-7b2d-ade5-949c-05aea0ba85a9@HIDDEN> <CALDnm51kS6p9V7z1AT=+TFp6kM5xw5Xv_oWZFSqAuEKx=-=a2A@HIDDEN> <5181f95e-61e7-c8c4-6389-44ee57e0c749@HIDDEN> <CALDnm51p7awjuw4vFMC=UByXnFUYMHsecUaSrT=Jiii5S3fgxQ@HIDDEN> <31cadbfd-d086-a04f-0ed9-17ce70b4282c@HIDDEN> <CALDnm5336QOoUf740oX0x+We2BJQihtOnGLzFzFe8QEuYAMw8w@HIDDEN> <835y2k8nyt.fsf@HIDDEN> In-Reply-To: <835y2k8nyt.fsf@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Thu, 2 Nov 2023 10:39:53 +0000 Message-ID: <CALDnm52N8LeT65wmRVijbJ8xX_PxGgviX7rzCSQyGTsisnyXBQ@HIDDEN> Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Eli Zaretskii <eliz@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: dmitry@HIDDEN, 47711 <at> debbugs.gnu.org, monnier@HIDDEN, mail@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Thu, Nov 2, 2023 at 10:11=E2=80=AFAM Eli Zaretskii <eliz@HIDDEN> wrote: > > > From: Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> > > Date: Thu, 2 Nov 2023 09:48:51 +0000 > > Cc: Eli Zaretskii <eliz@HIDDEN>, Daniel Mendler <mail@HIDDEN= e>, > > Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org > > > > Stefan, Eli, would you like to chime in? > > Chime in on what aspect(s) of this discussion (or the patch)? The patch condenses the results of the discussion of last week, as resuscitated by Dmitry after a 2-year long hiatus. After some rounds of benchmarking and discussion, Dmitry and I think the latest version of the patch should be installed. If you've not been following closely, the variables the patch introduces have docstrings explaining the functionality added, as do the commit messages to feature/completion-lazy-hilit. In a nutshell it solves the performance problem of overly eager completion highlighting with minimal changes to the completion API. The original patch proposed by Daniel Mendler was also partly about solving this problem, but with much more extensive changes. NEWS entries -- and possibly manual entries -- are also needed, not done yet. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 2 Nov 2023 10:11:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 02 06:11:44 2023 Received: from localhost ([127.0.0.1]:53982 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qyUfv-0003Va-Kh for submit <at> debbugs.gnu.org; Thu, 02 Nov 2023 06:11:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qyUft-0003VH-JO for 47711 <at> debbugs.gnu.org; Thu, 02 Nov 2023 06:11:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qyUfC-0005Eg-Jw; Thu, 02 Nov 2023 06:10:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=A6UowmjWCK/7ShPVt+Zu21RghpruEwHCXKRAbxV5NCM=; b=hO/rODbmEAI7yaBXjvge 6qnBN5N7GoCdeM9yThq0/E6vGanrH/bk0ilCk7rtWK7lQy6YfOzplI5jEfsZJi0Pi1oVVWiLlX1nh wNx7ar+S9H3K58L79uPogQW95ypT6abXhqZfmiuxoN1S7nRjtZ2XfgdKqyPM+d5KeOCGCz7InG66Q b/bP+bJsmOYx667kn59LscDjqmVWkjDaNP5GD696lO1H5qnE6nFQ8VRQt38gyv1ih8i2akwYx4q8x DYgvKhSxMTR0JRvCO+d7o8SSBZkIsxLtdfz9fH+uc7pdZFl6HRfCnFa7w5Otv0H4wlaH++kpBHhHr NQ/SLypSzQ+9lg==; Date: Thu, 02 Nov 2023 12:10:50 +0200 Message-Id: <835y2k8nyt.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> In-Reply-To: <CALDnm5336QOoUf740oX0x+We2BJQihtOnGLzFzFe8QEuYAMw8w@HIDDEN> (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Thu, 2 Nov 2023 09:48:51 +0000) Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <877cn8asud.fsf@HIDDEN> <c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN> <8734xtauqj.fsf@HIDDEN> <eeabbe1f-7b2d-ade5-949c-05aea0ba85a9@HIDDEN> <CALDnm51kS6p9V7z1AT=+TFp6kM5xw5Xv_oWZFSqAuEKx=-=a2A@HIDDEN> <5181f95e-61e7-c8c4-6389-44ee57e0c749@HIDDEN> <CALDnm51p7awjuw4vFMC=UByXnFUYMHsecUaSrT=Jiii5S3fgxQ@HIDDEN> <31cadbfd-d086-a04f-0ed9-17ce70b4282c@HIDDEN> <CALDnm5336QOoUf740oX0x+We2BJQihtOnGLzFzFe8QEuYAMw8w@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: dmitry@HIDDEN, 47711 <at> debbugs.gnu.org, monnier@HIDDEN, mail@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: João Távora <joaotavora@HIDDEN> > Date: Thu, 2 Nov 2023 09:48:51 +0000 > Cc: Eli Zaretskii <eliz@HIDDEN>, Daniel Mendler <mail@HIDDEN>, > Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org > > Stefan, Eli, would you like to chime in? Chime in on what aspect(s) of this discussion (or the patch)?
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 2 Nov 2023 09:49:53 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 02 05:49:53 2023 Received: from localhost ([127.0.0.1]:53954 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qyUKj-0000Nv-EL for submit <at> debbugs.gnu.org; Thu, 02 Nov 2023 05:49:53 -0400 Received: from mail-lf1-x12e.google.com ([2a00:1450:4864:20::12e]:50503) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1qyUKd-0000Nf-Nc for 47711 <at> debbugs.gnu.org; Thu, 02 Nov 2023 05:49:47 -0400 Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-507975d34e8so929039e87.1 for <47711 <at> debbugs.gnu.org>; Thu, 02 Nov 2023 02:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698918543; x=1699523343; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zuzDYWFWzFu5GTXkGhSRBmYjTcowG6ZDAfieURGFEjM=; b=GRBQsz+wKY2I/EDtjd853wma/DvBNW+D9OL2gv5a434TW8Yloj+u34Q+xv5BVekAfH UnmbkHsCaKJcFbHfqbAKm+izElhhuP662/sw8hogeMj9Lgm79K9mIcGMiaN9S2M8hziz NA5i5hc6uxkqtcJIJvyULMK8B2jkGk1p3IhYOWJJ8YRGcwZrQH/m6ndwKSqjkq2EmrHS nrXSAFw/6AXw53wB1SSwTGWzOR0vm0uJZy4JpywxPvLHHSXJ0X2J+mKA0PcLEwGBIUv8 AJltvIfCQCwWZwbabRzMGoI2LqYdYtA306neSoqKn0ty3aQdFtFPM//w7+VjB4NOxLht MP0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698918543; x=1699523343; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zuzDYWFWzFu5GTXkGhSRBmYjTcowG6ZDAfieURGFEjM=; b=f0CT0GJJRcNdqI4aP0/jUBt3IammReCypIhewUMiZ6iN+AYicKGP2hTrU0kPaR47LV hegiq/REYCl5OUzff4HeLCaolIoSWaS8D6MR3h54S5QGyb0cu8jzNeX/LQE0ucPJV28N aOVxqXlA3INAsYwnNRU9YQyygCjEfcxdK3BeB0Sn92RFaDt6BgTspAb5HR5knzTnOC0m KyRmhVbTHvV1k8FrJrELRy/yf6IUa2mmKRBVu7D7nYzI0E3kOmoUBKcfoR3aQNF7C6Bq XQajjrg6CUS8fsGISJcWAMbLqTXXH4DCa7dvNVXw4hFwWaeqikPDANednnoT5KzN5R// S8pQ== X-Gm-Message-State: AOJu0Yzn62J3pMi2MeEWNwNbrOSK6RIcqvB2oEt2e0iMH05URXa77j55 HUo3WGb9MSI0b4t33Y20f/SPTs6yAyh6xzEa4DoEepXv5gfsfw== X-Google-Smtp-Source: AGHT+IFPvzeWtxqT8rnnCCP3ZMA9vtmOgz6fS+HyFaR4nGcQeX+rQtHrkfy5tmY2WFOdpQNa5u5GUU/2iO5AtBcmOAo= X-Received: by 2002:a05:6512:249:b0:503:fee:5849 with SMTP id b9-20020a056512024900b005030fee5849mr13389612lfo.53.1698918542697; Thu, 02 Nov 2023 02:49:02 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <877cn8asud.fsf@HIDDEN> <c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN> <8734xtauqj.fsf@HIDDEN> <eeabbe1f-7b2d-ade5-949c-05aea0ba85a9@HIDDEN> <CALDnm51kS6p9V7z1AT=+TFp6kM5xw5Xv_oWZFSqAuEKx=-=a2A@HIDDEN> <5181f95e-61e7-c8c4-6389-44ee57e0c749@HIDDEN> <CALDnm51p7awjuw4vFMC=UByXnFUYMHsecUaSrT=Jiii5S3fgxQ@HIDDEN> <31cadbfd-d086-a04f-0ed9-17ce70b4282c@HIDDEN> In-Reply-To: <31cadbfd-d086-a04f-0ed9-17ce70b4282c@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Thu, 2 Nov 2023 09:48:51 +0000 Message-ID: <CALDnm5336QOoUf740oX0x+We2BJQihtOnGLzFzFe8QEuYAMw8w@HIDDEN> Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Dmitry Gutov <dmitry@HIDDEN> Content-Type: multipart/mixed; boundary="0000000000003d98570609284c82" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --0000000000003d98570609284c82 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 1, 2023 at 10:45=E2=80=AFPM Dmitry Gutov <dmitry@HIDDEN> wro= te: > > If orderless (which I've never tried), does some kind of scoring of > > completions, it probably also needs the same complications of flex. > > Turns out, Orderless doesn't do any scoring or sorting. Only filtering. Interesting, so if I M-x d i f f with orderless I don't get results in any particular order? > >>>> Anyway, have you looked into what it would take to solve it? > >>> > >>> No, naively, I just think it's a similar situation of display and bus= iness > >>> logic being mixed up. Presumably the quoted stuff is just for insert= ion > >>> (and display?), and the unquoted stuff is what patterns/scoring shoul= d > >>> operate on. > >> > >> Apparently it's good for insertion, but according to that comment insi= de > >> the function, the unquoted stuff might actually be better for display. > > > > No idea what the unquoted stuff is for, so I haven't really tested it. > > A couple of scenarios: Thanks. Then I think it is working OK, but it would be safer if you were to double-check yourself, as I really never use this functionality. > LGTM overall, and I see that you compressed the sorting code a little. > > Both quoting/unquoting scenarios also seem to work as expected (for > highlighting, that seems to be thanks to completion--twq-all applying > the faces eagerly anyway). That's good. > Though given the examples (and I think others should be similar) it > wouldn't be an end of the world if scoring didn't really work for them > -- filtering should have already done most of the job. All of this is to > say that any new 3rd party completion styles, even those that do > sorting, would be okay without knowing about this text property. Maybe. > Some minor nits for the patch: Thanks. > I guess we should wait a few days to see if anyone has more comments, > and then install this? I addressed all your docstring suggestions, fixed a bug and significantly simplified the code in the latest version of the patch. I also removed the instrumentation in icomplete.el. Patch attached here and pushed to feature/completion-lazy-hilit. Stefan, Eli, would you like to chime in? Jo=C3=A3o --0000000000003d98570609284c82 Content-Type: application/octet-stream; name="lazy-hilit-2023-v6.diff" Content-Disposition: attachment; filename="lazy-hilit-2023-v6.diff" Content-Transfer-Encoding: base64 Content-ID: <f_loh079840> X-Attachment-Id: f_loh079840 ZGlmZiAtLWdpdCBhL2xpc3AvaWNvbXBsZXRlLmVsIGIvbGlzcC9pY29tcGxldGUuZWwKaW5kZXgg ZTZmZGQxZjE4MzYuLmY0YzRmZWI3MzA0IDEwMDY0NAotLS0gYS9saXNwL2ljb21wbGV0ZS5lbAor KysgYi9saXNwL2ljb21wbGV0ZS5lbApAQCAtNzIyLDcgKzcyMiw4IEBAIGljb21wbGV0ZS1leGhp Yml0CiAgICAgICAgICAgICAgOzsgQ2hlY2sgaWYgc3RpbGwgaW4gdGhlIHJpZ2h0IGJ1ZmZlciAo YnVnIzYxMzA4KQogICAgICAgICAgICAgIChvciAod2luZG93LW1pbmlidWZmZXItcCkgY29tcGxl dGlvbi1pbi1yZWdpb24tLWRhdGEpCiAgICAgICAgICAgICAgKGljb21wbGV0ZS1zaW1wbGUtY29t cGxldGluZy1wKSkgO1Nob3VsZG4ndCBiZSBuZWNlc3NhcnkuCi0gICAgKGxldCAoKHNhdmVkLXBv aW50IChwb2ludCkpKQorICAgIChsZXQgKChzYXZlZC1wb2ludCAocG9pbnQpKQorICAgICAgICAg IChjb21wbGV0aW9uLWxhenktaGlsaXQgdCkpCiAgICAgICAoc2F2ZS1leGN1cnNpb24KICAgICAg ICAgKGdvdG8tY2hhciAoaWNvbXBsZXRlLS1maWVsZC1lbmQpKQogICAgICAgICA7OyBJbnNlcnQg dGhlIG1hdGNoLXN0YXR1cyBpbmZvcm1hdGlvbjoKQEAgLTkwMSw3ICs5MDIsNyBAQCBpY29tcGxl dGUtLXJlbmRlci12ZXJ0aWNhbAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAnaWNv bXBsZXRlLXNlbGVjdGVkLW1hdGNoICdhcHBlbmQgY29tcCkKICAgICAgY29sbGVjdCAoY29uY2F0 IHByZWZpeAogICAgICAgICAgICAgICAgICAgICAgKG1ha2Utc3RyaW5nICgtIG1heC1wcmVmaXgt bGVuIChsZW5ndGggcHJlZml4KSkgPyApCi0gICAgICAgICAgICAgICAgICAgICBjb21wCisgICAg ICAgICAgICAgICAgICAgICAoY29tcGxldGlvbi1sYXp5LWhpbGl0IGNvbXApCiAgICAgICAgICAg ICAgICAgICAgICAobWFrZS1zdHJpbmcgKC0gbWF4LWNvbXAtbGVuIChsZW5ndGggY29tcCkpID8g KQogICAgICAgICAgICAgICAgICAgICAgc3VmZml4KQogICAgICBpbnRvIGxpbmVzLWF1eApAQCAt MTA2Nyw3ICsxMDY4LDggQEAgaWNvbXBsZXRlLWNvbXBsZXRpb25zCiAgICAgICAgICAgICAgICAg ICAoaWYgKDwgcHJvc3BlY3RzLWxlbiBwcm9zcGVjdHMtbWF4KQogICAgICAgICAgICAgICAgICAg ICAgIChwdXNoIGNvbXAgcHJvc3BlY3RzKQogICAgICAgICAgICAgICAgICAgICAoc2V0cSBsaW1p dCB0KSkpCi0gICAgICAgICAgICAgICAgKHNldHEgcHJvc3BlY3RzIChucmV2ZXJzZSBwcm9zcGVj dHMpKQorICAgICAgICAgICAgICAgIChzZXRxIHByb3NwZWN0cworICAgICAgICAgICAgICAgICAg ICAgIChucmV2ZXJzZSAobWFwY2FyICMnY29tcGxldGlvbi1sYXp5LWhpbGl0IHByb3NwZWN0cykp KQogICAgICAgICAgICAgICAgIDs7IERlY29yYXRlIGZpcnN0IG9mIHRoZSBwcm9zcGVjdHMuCiAg ICAgICAgICAgICAgICAgKHdoZW4gcHJvc3BlY3RzCiAgICAgICAgICAgICAgICAgICAobGV0ICgo Zmlyc3QgKGNvcHktc2VxdWVuY2UgKHBvcCBwcm9zcGVjdHMpKSkpCmRpZmYgLS1naXQgYS9saXNw L21pbmlidWZmZXIuZWwgYi9saXNwL21pbmlidWZmZXIuZWwKaW5kZXggMjEyMGUzMTc3NWUuLmVl MGE1NDdmZTliIDEwMDY0NAotLS0gYS9saXNwL21pbmlidWZmZXIuZWwKKysrIGIvbGlzcC9taW5p YnVmZmVyLmVsCkBAIC02NzcsNiArNjc3LDEwIEBAIGNvbXBsZXRpb24tLXR3cS1hbGwKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICdjb21wbGV0aW9ucy1jb21t b24tcGFydCkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBxcHJlZml4KSkpKQogICAg ICAgICAgICAgICAgICAgICAgICAgKHFjb21wbGV0aW9uIChjb25jYXQgcXByZWZpeCBxbmV3KSkp CisgICAgICAgICAgICAgICAgICAgOzsgQXR0YWNoIHVucXVvdGVkIGNvbXBsZXRpb24gc3RyaW5n LCB3aGljaCBpcyBuZWVkZWQKKyAgICAgICAgICAgICAgICAgICA7OyB0byBzY29yZSB0aGUgY29t cGxldGlvbiBpbiBgY29tcGxldGlvbi0tZmxleC1zY29yZScuCisgICAgICAgICAgICAgICAgICAg KHB1dC10ZXh0LXByb3BlcnR5IDAgMSAnY29tcGxldGlvbi0tdW5xdW90ZWQKKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgY29tcGxldGlvbiBxY29tcGxldGlvbikKIAkJICAg OzsgRklYTUU6IFNpbWlsYXJseSBoZXJlLCBDeWd3aW4ncyBtYXBwaW5nIHRyaXBzIHRoaXMKIAkJ ICAgOzsgYXNzZXJ0aW9uLgogICAgICAgICAgICAgICAgICAgIDs7KGNsLWFzc2VydApAQCAtMTIz NCw2ICsxMjM4LDcgQEAgY29tcGxldGlvbi1hbGwtY29tcGxldGlvbnMKIFBPSU5UIGlzIHRoZSBw b3NpdGlvbiBvZiBwb2ludCB3aXRoaW4gU1RSSU5HLgogVGhlIHJldHVybiB2YWx1ZSBpcyBhIGxp c3Qgb2YgY29tcGxldGlvbnMgYW5kIG1heSBjb250YWluIHRoZSBiYXNlLXNpemUKIGluIHRoZSBs YXN0IGBjZHInLiIKKyAgKHNldHEgY29tcGxldGlvbi1sYXp5LWhpbGl0LWZuIG5pbCkKICAgOzsg RklYTUU6IFdlIG5lZWQgdG8gYWRkaXRpb25hbGx5IHJldHVybiB0aGUgaW5mbyBuZWVkZWQgZm9y IHRoZQogICA7OyBzZWNvbmQgcGFydCBvZiBjb21wbGV0aW9uLWJhc2UtcG9zaXRpb24uCiAgIChj b21wbGV0aW9uLS1udGgtY29tcGxldGlvbiAyIHN0cmluZyB0YWJsZSBwcmVkIHBvaW50IG1ldGFk YXRhKSkKQEAgLTM3NDksMTA4ICszNzU0LDE5MyBAQCBmbGV4LXNjb3JlLW1hdGNoLXRpZ2h0bmVz cwogdGhhbiB0aGUgbGF0dGVyICh3aGljaCBoYXMgdHdvIFwiaG9sZXNcIiBhbmQgdGhyZWUKIG9u ZS1sZXR0ZXItbG9uZyBtYXRjaGVzKS4iKQogCisoZGVmdmFyLWxvY2FsIGNvbXBsZXRpb24tbGF6 eS1oaWxpdCBuaWwKKyAgIklmIG5vbi1uaWwsIHJlcXVlc3QgY29tcGxldGlvbiBsYXp5IGhpZ2hs aWdodGluZy4KKworQ29tcGxldGlvbi1wcmVzZW50aW5nIGZyb250ZW5kcyBtYXkgb3B0IHRvIGJp bmQgdGhpcyB2YXJpYWJsZSB0bworbm9uLW5pbCB2YWx1ZSBpbiB0aGUgY29udGV4dCBvZiBjb21w bGV0aW9uLXByb2R1Y2luZyBjYWxscyAoc3VjaAorYXMgYGNvbXBsZXRpb24tYWxsLWNvbXBsZXRp b25zJykuICBUaGlzIGhpbnRzIHRoZSBpbnRlcnZlbmluZworY29tcGxldGlvbiBzdHlsZXMgdGhh dCB0aGV5IGRvIG5vdCBuZWVkIHRvCitmb250aWZ5IChpLmUuIHByb3BlcnRpemUgd2l0aCB0aGUg YGZhY2UnIHByb3BlcnR5KSBjb21wbGV0aW9uCitzdHJpbmdzIHdpdGggaGlnaGxpZ2h0cyBvZiB0 aGUgbWF0Y2hpbmcgcGFydHMuCisKK1doZW4gZG9pbmcgc28sIGl0IGlzIHRoZSBmcm9udGVuZCAt LSBub3QgdGhlIHN0eWxlIC0tIHdobyBiZWNvbWVzCityZXNwb25zaWJsZSBmb3IgdGhpcyBmb250 aWZpY2F0aW9uLiAgVGhlIGZyb250ZW5kIGJpbmRzIHRoaXMKK3ZhcmlhYmxlIHRvIG5vbi1uaWws IGFuZCBjYWxscyB0aGUgZnVuY3Rpb24gd2l0aCB0aGUgc2FtZSBuYW1lCitgY29tcGxldGlvbi1s YXp5LWhpbGl0JyBvbiBlYWNoIGNvbXBsZXRpb24gc3RyaW5nIHRoYXQgaXMgdG8gYmUKK2Rpc3Bs YXllZCB0byB0aGUgdXNlci4KKworTm90ZSB0aGF0IG9ubHkgc29tZSBjb21wbGV0aW9uIHN0eWxl cyB0YWtlIGFkdmFudGFnZSBvZiB0aGlzCit2YXJpYWJsZSBmb3Igb3B0aW1pemF0aW9uIHB1cnBv c2VzLiAgT3RoZXIgc3R5bGVzIHdpbGwgaWdub3JlIHRoZQoraGludCBhbmQgZm9udGlmeSBlYWdl cmx5IGFzIHVzdWFsLiAgSXQgaXMgc3RpbGwgc2FmZSBmb3IgYQorZnJvbnRlbmQgdG8gY2FsbCBg Y29tcGxldGlvbi1sYXp5LWhpbGl0JyBpbiB0aGVzZSBzaXR1YXRpb25zLgorCitUbyBhdXRob3Ig YSBjb21wbGV0aW9uIHN0eWxlIHRoYXQgdGFrZXMgYWR2YW50YWdlIHNlZQorYGNvbXBsZXRpb24t bGF6eS1oaWxpdC1mbicgYW5kIGxvb2sgaW4gdGhlIHNvdXJjZSBvZgorYGNvbXBsZXRpb24tcGNt LS1oaWxpdC1jb21tb25hbGl0eScuIikKKworKGRlZnZhciBjb21wbGV0aW9uLWxhenktaGlsaXQt Zm4gbmlsCisgICJVc2VkIGJ5IGNvbXBsZXRpb25zIHN0eWxlcyBob25vcmluZyBgY29tcGxldGlv bi1sYXp5LWhpbGl0Jy4KK1doZW4gYSBnaXZlbiBzdHlsZSB3YW50cyB0byBlbmFibGUgc3VwcG9y dCBmb3IKK2Bjb21wbGV0aW9uLWxhenktaGlsaXQnICh3aGljaCBzZWUpLCB0aGF0IHN0eWxlIHNo b3VsZCBzZXQgdGhpcwordmFyaWFibGUgdG8gYSBmdW5jdGlvbiBvZiBvbmUgYXJndW1lbnQsIGEg ZnJlc2ggc3RyaW5nIHRvIGJlCitkaXNwbGF5ZWQgdG8gdGhlIHVzZXIuICBUaGUgZnVuY3Rpb24g aXMgcmVzcG9uc2libGUgZm9yCitkZXN0cnVjdGl2ZWx5IGhpZ2hsaWdodGluZyB0aGUgc3RyaW5n LiIpCisKKyhkZWZ1biBjb21wbGV0aW9uLWxhenktaGlsaXQgKHN0cikKKyAgIlJldHVybiBhIGNv cHkgb2YgY29tcGxldGlvbiBTVFIgdGhhdCBpcyBgZmFjZSctcHJvcGVydGl6ZWQuCitTZWUgZG9j dW1lbnRhdGlvbiBmb3IgdmFyaWFibGUgYGNvbXBsZXRpb24tbGF6eS1oaWxpdCcgZm9yIG1vcmUK K2RldGFpbHMuIgorICAoaWYgKGFuZCBjb21wbGV0aW9uLWxhenktaGlsaXQgY29tcGxldGlvbi1s YXp5LWhpbGl0LWZuKQorICAgICAgKGZ1bmNhbGwgY29tcGxldGlvbi1sYXp5LWhpbGl0LWZuIChj b3B5LXNlcXVlbmNlIHN0cikpCisgICAgc3RyKSkKKworKGRlZnVuIGNvbXBsZXRpb24tLWhpbGl0 LWZyb20tcmUgKHN0cmluZyByZWdleHApCisgICJGb250aWZ5IFNUUklORyB3aXRoIGBjb21wbGV0 aW9ucy1jb21tb24tcGFydCcgdXNpbmcgUkVHRVhQLiIKKyAgKGxldCogKChtZCAoYW5kIHJlZ2V4 cCAoc3RyaW5nLW1hdGNoIHJlZ2V4cCBzdHJpbmcpIChjZGRyIChtYXRjaC1kYXRhIHQpKSkpCisg ICAgICAgICAobWUgKGFuZCBtZCAobWF0Y2gtZW5kIDApKSkKKyAgICAgICAgIChmcm9tIDApKQor ICAgICh3aGlsZSBtZAorICAgICAgKGFkZC1mYWNlLXRleHQtcHJvcGVydHkgZnJvbSAocG9wIG1k KSAnY29tcGxldGlvbnMtY29tbW9uLXBhcnQgbmlsIHN0cmluZykKKyAgICAgIChzZXRxIGZyb20g KHBvcCBtZCkpKQorICAgICh1bmxlc3MgKG9yIChub3QgbWUpICg9IGZyb20gbWUpKQorICAgICAg KGFkZC1mYWNlLXRleHQtcHJvcGVydHkgZnJvbSBtZSAnY29tcGxldGlvbnMtY29tbW9uLXBhcnQg bmlsIHN0cmluZykpCisgICAgc3RyaW5nKSkKKworKGRlZnVuIGNvbXBsZXRpb24tLWZsZXgtc2Nv cmUtMSAobWQtZ3JvdXBzIG1hdGNoLWVuZCBsZW4pCisgICJDb21wdXRlIG1hdGNoaW5nIHNjb3Jl IG9mIGNvbXBsZXRpb24uCitUaGUgc2NvcmUgbGllcyBpbiB0aGUgcmFuZ2UgYmV0d2VlbiAwIGFu ZCAxLCB3aGVyZSAxIGNvcnJlc3BvbmRzIHRvCit0aGUgZnVsbCBtYXRjaC4KK01ELUdST1VQUyBp cyB0aGUgXCJncm91cFwiICBwYXJ0IG9mIHRoZSBtYXRjaCBkYXRhLgorTUFUQ0gtRU5EIGlzIHRo ZSBlbmQgb2YgdGhlIG1hdGNoLgorTEVOIGlzIHRoZSBsZW5ndGggb2YgdGhlIGNvbXBsZXRpb24g c3RyaW5nLiIKKyAgKGxldCogKChmcm9tIDApCisgICAgICAgICA7OyBUbyB1bmRlcnN0YW5kIGhv dyB0aGlzIHdvcmtzLCBjb25zaWRlciB0aGVzZSBzaW1wbGUKKyAgICAgICAgIDs7IGFzY2lpIGRp YWdyYW1zIHNob3dpbmcgaG93IHRoZSBwYXR0ZXJuICJmb28iCisgICAgICAgICA7OyBmbGV4LW1h dGNoZXMgImZhYnJvYmF6byIsICJmYmFyYmF6b28iIGFuZAorICAgICAgICAgOzsgImJhcmZvb2Jh eiI6CisKKyAgICAgICAgIDs7ICAgICAgZiBhYnIgbyBiYXogbworICAgICAgICAgOzsgICAgICAr IC0tLSArIC0tLSArCisKKyAgICAgICAgIDs7ICAgICAgZiBiYXJiYXogb28KKyAgICAgICAgIDs7 ICAgICAgKyAtLS0tLS0gKysKKworICAgICAgICAgOzsgICAgICBiYXIgZm9vIGJhegorICAgICAg ICAgOzsgICAgICAgICAgKysrCisKKyAgICAgICAgIDs7ICIrIiBpbmRpY2F0ZXMgcGFydHMgd2hl cmUgdGhlIHBhdHRlcm4gbWF0Y2hlZC4gIEEKKyAgICAgICAgIDs7ICJob2xlIiBpbiB0aGUgbWlk ZGxlIG9mIHRoZSBzdHJpbmcgaXMgaW5kaWNhdGVkIGJ5CisgICAgICAgICA7OyAiLSIuICBOb3Rl IHRoYXQgdGhlcmUgYXJlIG5vICJob2xlcyIgbmVhciB0aGUgZWRnZXMKKyAgICAgICAgIDs7IG9m IHRoZSBzdHJpbmcuICBUaGUgY29tcGxldGlvbiBzY29yZSBpcyBhIG51bWJlcgorICAgICAgICAg OzsgYm91bmQgYnkgKDAuLjFdIChpLmUuLCBsYXJnZXIgdGhhbiAoYnV0IG5vdCBlcXVhbAorICAg ICAgICAgOzsgdG8pIHplcm8sIGFuZCBzbWFsbGVyIG9yIGVxdWFsIHRvIG9uZSk6IHRoZSBoaWdo ZXIKKyAgICAgICAgIDs7IHRoZSBiZXR0ZXIgYW5kIG9ubHkgYSBwZXJmZWN0IG1hdGNoIChwYXR0 ZXJuIGVxdWFscworICAgICAgICAgOzsgc3RyaW5nKSB3aWxsIGhhdmUgc2NvcmUgMS4gIFRoZSBm b3JtdWxhIHRha2VzIHRoZQorICAgICAgICAgOzsgZm9ybSBvZiBhIHF1b3RpZW50LiAgRm9yIHRo ZSBudW1lcmF0b3IsIHdlIHVzZSB0aGUKKyAgICAgICAgIDs7IG51bWJlciBvZiArLCBpLmUuIHRo ZSBsZW5ndGggb2YgdGhlIHBhdHRlcm4uICBGb3IKKyAgICAgICAgIDs7IHRoZSBkZW5vbWluYXRv ciwgaXQgZmlyc3QgY29tcHV0ZXMKKyAgICAgICAgIDs7CisgICAgICAgICA7OyAgICAgaG9sZV9p X2NvbnRyaWIgPSAxICsgKExpLTEpXigxL3RpZ2h0bmVzcykKKyAgICAgICAgIDs7CisgICAgICAg ICA7OyAsIGZvciBlYWNoIGhvbGUgImkiIG9mIGxlbmd0aCAiTGkiLCB3aGVyZSB0aWdodG5lc3MK KyAgICAgICAgIDs7IGlzIGdpdmVuIGJ5IGBmbGV4LXNjb3JlLW1hdGNoLXRpZ2h0bmVzcycuICBU aGUKKyAgICAgICAgIDs7IGZpbmFsIHZhbHVlIGZvciB0aGUgZGVub21pbmF0b3IgaXMgdGhlbiBn aXZlbiBieToKKyAgICAgICAgIDs7CisgICAgICAgICA7OyAgICAoU1VNX2Fjcm9zc19pKGhvbGVf aV9jb250cmliKSArIDEpICogbGVuCisgICAgICAgICA7OworICAgICAgICAgOzsgLCB3aGVyZSAi bGVuIiBpcyB0aGUgc3RyaW5nJ3MgbGVuZ3RoLgorICAgICAgICAgKHNjb3JlLW51bWVyYXRvciAw KQorICAgICAgICAgKHNjb3JlLWRlbm9taW5hdG9yIDApCisgICAgICAgICAobGFzdC1iIDApKQor ICAgICh3aGlsZSAoYW5kIG1kLWdyb3VwcyAoY2FyIG1kLWdyb3VwcykpCisgICAgICAobGV0ICgo YSBmcm9tKQorICAgICAgICAgICAgKGIgKHBvcCBtZC1ncm91cHMpKSkKKyAgICAgICAgKHNldHEK KyAgICAgICAgIHNjb3JlLW51bWVyYXRvciAgICgrIHNjb3JlLW51bWVyYXRvciAoLSBiIGEpKSkK KyAgICAgICAgKHVubGVzcyAob3IgKD0gYSBsYXN0LWIpCisgICAgICAgICAgICAgICAgICAgICh6 ZXJvcCBsYXN0LWIpCisgICAgICAgICAgICAgICAgICAgICg9IGEgbGVuKSkKKyAgICAgICAgICAo c2V0cQorICAgICAgICAgICBzY29yZS1kZW5vbWluYXRvciAoKyBzY29yZS1kZW5vbWluYXRvcgor ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxCisgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIChleHB0ICgtIGEgbGFzdC1iIDEpCisgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICgvIDEuMAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBmbGV4LXNjb3JlLW1hdGNoLXRpZ2h0bmVzcykpKSkpCisgICAgICAgIChzZXRxCisgICAg ICAgICBsYXN0LWIgICAgICAgICAgICAgIGIpKQorICAgICAgKHNldHEgZnJvbSAocG9wIG1kLWdy b3VwcykpKQorICAgIDs7IElmIGBwYXR0ZXJuJyBkb2Vzbid0IGhhdmUgYW4gZXhwbGljaXQgdHJh aWxpbmcgYW55LCB0aGUKKyAgICA7OyByZWdleCBgcmUnIHdvbid0IHByb2R1Y2UgbWF0Y2ggZGF0 YSByZXByZXNlbnRpbmcgdGhlCisgICAgOzsgcmVnaW9uIGFmdGVyIHRoZSBtYXRjaC4gIFdlIG5l ZWQgdG8gYWNjb3VudCB0byBhY2NvdW50CisgICAgOzsgZm9yIHRoYXQgZXh0cmEgYml0IG9mIG1h dGNoIChidWcjNDIxNDkpLgorICAgICh1bmxlc3MgKD0gZnJvbSBtYXRjaC1lbmQpCisgICAgICAo bGV0ICgoYSBmcm9tKQorICAgICAgICAgICAgKGIgbWF0Y2gtZW5kKSkKKyAgICAgICAgKHNldHEK KyAgICAgICAgIHNjb3JlLW51bWVyYXRvciAgICgrIHNjb3JlLW51bWVyYXRvciAoLSBiIGEpKSkK KyAgICAgICAgKHVubGVzcyAob3IgKD0gYSBsYXN0LWIpCisgICAgICAgICAgICAgICAgICAgICh6 ZXJvcCBsYXN0LWIpCisgICAgICAgICAgICAgICAgICAgICg9IGEgbGVuKSkKKyAgICAgICAgICAo c2V0cQorICAgICAgICAgICBzY29yZS1kZW5vbWluYXRvciAoKyBzY29yZS1kZW5vbWluYXRvcgor ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxCisgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIChleHB0ICgtIGEgbGFzdC1iIDEpCisgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICgvIDEuMAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBmbGV4LXNjb3JlLW1hdGNoLXRpZ2h0bmVzcykpKSkpCisgICAgICAgIChzZXRxCisgICAg ICAgICBsYXN0LWIgICAgICAgICAgICAgIGIpKSkKKyAgICAoLyBzY29yZS1udW1lcmF0b3IgKCog bGVuICgxKyBzY29yZS1kZW5vbWluYXRvcikpIDEuMCkpKQorCisoZGVmdmFyIGNvbXBsZXRpb24t LWZsZXgtc2NvcmUtbGFzdC1tZCBuaWwKKyAgIkhlbHBlciB2YXJpYWJsZSBmb3IgYGNvbXBsZXRp b24tLWZsZXgtc2NvcmUnLiIpCisKKyhkZWZ1biBjb21wbGV0aW9uLS1mbGV4LXNjb3JlIChzdHIg cmUgJm9wdGlvbmFsIGRvbnQtZXJyb3IpCisgICJDb21wdXRlIGZsZXggc2NvcmUgb2YgY29tcGxl dGlvbiBTVFIgYmFzZWQgb24gUkUuCitJZiBET05ULUVSUk9SLCBqdXN0IHJldHVybiBuaWwgaWYg UkUgZG9lc24ndCBtYXRjaCBTVFIuIgorICAoY29uZCAoKHN0cmluZy1tYXRjaCByZSBzdHIpCisg ICAgICAgICAobGV0KiAoKG1hdGNoLWVuZCAobWF0Y2gtZW5kIDApKQorICAgICAgICAgICAgICAg IChtZCAoY2RkcgorICAgICAgICAgICAgICAgICAgICAgKHNldHEKKyAgICAgICAgICAgICAgICAg ICAgICBjb21wbGV0aW9uLS1mbGV4LXNjb3JlLWxhc3QtbWQKKyAgICAgICAgICAgICAgICAgICAg ICAobWF0Y2gtZGF0YSB0IGNvbXBsZXRpb24tLWZsZXgtc2NvcmUtbGFzdC1tZCkpKSkpCisgICAg ICAgICAgIChjb21wbGV0aW9uLS1mbGV4LXNjb3JlLTEgbWQgbWF0Y2gtZW5kIChsZW5ndGggc3Ry KSkpKQorICAgICAgICAoKG5vdCBkb250LWVycm9yKQorICAgICAgICAgKGVycm9yICJJbnRlcm5h bCBlcnJvcjogJXMgZG9lcyBub3QgbWF0Y2ggJXMiIHJlIHN0cikpKSkKKworKGRlZnZhciBjb21w bGV0aW9uLXBjbS0tcmVnZXhwIG5pbAorICAiUmVnZXhwIGZyb20gUENNIHBhdHRlcm4gaW4gYGNv bXBsZXRpb24tcGNtLS1oaWxpdC1jb21tb25hbGl0eScuIikKKwogKGRlZnVuIGNvbXBsZXRpb24t cGNtLS1oaWxpdC1jb21tb25hbGl0eSAocGF0dGVybiBjb21wbGV0aW9ucykKICAgIlNob3cgd2hl cmUgYW5kIGhvdyB3ZWxsIFBBVFRFUk4gbWF0Y2hlcyBDT01QTEVUSU9OUy4KIFBBVFRFUk4sIGEg bGlzdCBvZiBzeW1ib2xzIGFuZCBzdHJpbmdzIGFzIHNlZW4KIGBjb21wbGV0aW9uLXBjbS0tbWVy Z2UtY29tcGxldGlvbnMnLCBpcyBhc3N1bWVkIHRvIG1hdGNoIGV2ZXJ5Ci1zdHJpbmcgaW4gQ09N UExFVElPTlMuICBSZXR1cm4gYSBkZWVwIGNvcHkgb2YgQ09NUExFVElPTlMgd2hlcmUKLWVhY2gg c3RyaW5nIGlzIHByb3BlcnRpemVkIHdpdGggYGNvbXBsZXRpb24tc2NvcmUnLCBhIG51bWJlcgot YmV0d2VlbiAwIGFuZCAxLCBhbmQgd2l0aCBmYWNlcyBgY29tcGxldGlvbnMtY29tbW9uLXBhcnQn LAotYGNvbXBsZXRpb25zLWZpcnN0LWRpZmZlcmVuY2UnIGluIHRoZSByZWxldmFudCBzZWdtZW50 cy4iCitzdHJpbmcgaW4gQ09NUExFVElPTlMuCisKK0lmIGBjb21wbGV0aW9uLWxhenktaGlsaXQn IGlzIG5pbCwgcmV0dXJuIGEgZGVlcCBjb3B5IG9mCitDT01QTEVUSU9OUyB3aGVyZSBlYWNoIHN0 cmluZyBpcyBwcm9wZXJ0aXplZCB3aXRoCitgY29tcGxldGlvbi1zY29yZScsIGEgbnVtYmVyIGJl dHdlZW4gMCBhbmQgMSwgYW5kIHdpdGggZmFjZXMKK2Bjb21wbGV0aW9ucy1jb21tb24tcGFydCcs IGBjb21wbGV0aW9ucy1maXJzdC1kaWZmZXJlbmNlJyBpbiB0aGUKK3JlbGV2YW50IHNlZ21lbnRz LgorCitFbHNlLCBpZiBgY29tcGxldGlvbi1sYXp5LWhpbGl0JyBpcyB0LCByZXR1cm4gQ09NUExF VElPTlMKK3VuY2hhbmdlZCwgYnV0IHNldHVwIGEgc3VpdGFibGUgYGNvbXBsZXRpb24tbGF6eS1o aWxpdC1mbicgKHdoaWNoCitzZWUpIGZvciBsYXRlciBsYXp5IGhpZ2hsaWdodGluZy4iCisgIChz ZXRxIGNvbXBsZXRpb24tcGNtLS1yZWdleHAgbmlsCisgICAgICAgIGNvbXBsZXRpb24tbGF6eS1o aWxpdC1mbiBuaWwpCiAgIChjb25kCiAgICAoKGFuZCBjb21wbGV0aW9ucyAoY2wtbG9vcCBmb3Ig ZSBpbiBwYXR0ZXJuIHRoZXJlaXMgKHN0cmluZ3AgZSkpKQotICAgIChsZXQqICgocmUgKGNvbXBs ZXRpb24tcGNtLS1wYXR0ZXJuLT5yZWdleCBwYXR0ZXJuICdncm91cCkpCi0gICAgICAgICAgIChw b2ludC1pZHggKGNvbXBsZXRpb24tcGNtLS1wYXR0ZXJuLXBvaW50LWlkeCBwYXR0ZXJuKSkKLSAg ICAgICAgICAgKGNhc2UtZm9sZC1zZWFyY2ggY29tcGxldGlvbi1pZ25vcmUtY2FzZSkKLSAgICAg ICAgICAgbGFzdC1tZCkKLSAgICAgIChtYXBjYXIKLSAgICAgICAobGFtYmRhIChzdHIpCi0JIDs7 IERvbid0IG1vZGlmeSB0aGUgc3RyaW5nIGl0c2VsZi4KLSAgICAgICAgIChzZXRxIHN0ciAoY29w eS1zZXF1ZW5jZSBzdHIpKQotICAgICAgICAgKHVubGVzcyAoc3RyaW5nLW1hdGNoIHJlIHN0cikK LSAgICAgICAgICAgKGVycm9yICJJbnRlcm5hbCBlcnJvcjogJXMgZG9lcyBub3QgbWF0Y2ggJXMi IHJlIHN0cikpCi0gICAgICAgICAobGV0KiAoKHBvcyAoaWYgcG9pbnQtaWR4IChtYXRjaC1iZWdp bm5pbmcgcG9pbnQtaWR4KSAobWF0Y2gtZW5kIDApKSkKLSAgICAgICAgICAgICAgICAobWF0Y2gt ZW5kIChtYXRjaC1lbmQgMCkpCi0gICAgICAgICAgICAgICAgKG1kIChjZGRyIChzZXRxIGxhc3Qt bWQgKG1hdGNoLWRhdGEgdCBsYXN0LW1kKSkpKQotICAgICAgICAgICAgICAgIChmcm9tIDApCi0g ICAgICAgICAgICAgICAgKGVuZCAobGVuZ3RoIHN0cikpCi0gICAgICAgICAgICAgICAgOzsgVG8g dW5kZXJzdGFuZCBob3cgdGhpcyB3b3JrcywgY29uc2lkZXIgdGhlc2Ugc2ltcGxlCi0gICAgICAg ICAgICAgICAgOzsgYXNjaWkgZGlhZ3JhbXMgc2hvd2luZyBob3cgdGhlIHBhdHRlcm4gImZvbyIK LSAgICAgICAgICAgICAgICA7OyBmbGV4LW1hdGNoZXMgImZhYnJvYmF6byIsICJmYmFyYmF6b28i IGFuZAotICAgICAgICAgICAgICAgIDs7ICJiYXJmb29iYXoiOgotCi0gICAgICAgICAgICAgICAg OzsgICAgICBmIGFiciBvIGJheiBvCi0gICAgICAgICAgICAgICAgOzsgICAgICArIC0tLSArIC0t LSArCi0KLSAgICAgICAgICAgICAgICA7OyAgICAgIGYgYmFyYmF6IG9vCi0gICAgICAgICAgICAg ICAgOzsgICAgICArIC0tLS0tLSArKwotCi0gICAgICAgICAgICAgICAgOzsgICAgICBiYXIgZm9v IGJhegotICAgICAgICAgICAgICAgIDs7ICAgICAgICAgICsrKwotCi0gICAgICAgICAgICAgICAg OzsgIisiIGluZGljYXRlcyBwYXJ0cyB3aGVyZSB0aGUgcGF0dGVybiBtYXRjaGVkLiAgQQotICAg ICAgICAgICAgICAgIDs7ICJob2xlIiBpbiB0aGUgbWlkZGxlIG9mIHRoZSBzdHJpbmcgaXMgaW5k aWNhdGVkIGJ5Ci0gICAgICAgICAgICAgICAgOzsgIi0iLiAgTm90ZSB0aGF0IHRoZXJlIGFyZSBu byAiaG9sZXMiIG5lYXIgdGhlIGVkZ2VzCi0gICAgICAgICAgICAgICAgOzsgb2YgdGhlIHN0cmlu Zy4gIFRoZSBjb21wbGV0aW9uIHNjb3JlIGlzIGEgbnVtYmVyCi0gICAgICAgICAgICAgICAgOzsg Ym91bmQgYnkgKDAuLjFdIChpLmUuLCBsYXJnZXIgdGhhbiAoYnV0IG5vdCBlcXVhbAotICAgICAg ICAgICAgICAgIDs7IHRvKSB6ZXJvLCBhbmQgc21hbGxlciBvciBlcXVhbCB0byBvbmUpOiB0aGUg aGlnaGVyCi0gICAgICAgICAgICAgICAgOzsgdGhlIGJldHRlciBhbmQgb25seSBhIHBlcmZlY3Qg bWF0Y2ggKHBhdHRlcm4gZXF1YWxzCi0gICAgICAgICAgICAgICAgOzsgc3RyaW5nKSB3aWxsIGhh dmUgc2NvcmUgMS4gIFRoZSBmb3JtdWxhIHRha2VzIHRoZQotICAgICAgICAgICAgICAgIDs7IGZv cm0gb2YgYSBxdW90aWVudC4gIEZvciB0aGUgbnVtZXJhdG9yLCB3ZSB1c2UgdGhlCi0gICAgICAg ICAgICAgICAgOzsgbnVtYmVyIG9mICssIGkuZS4gdGhlIGxlbmd0aCBvZiB0aGUgcGF0dGVybi4g IEZvcgotICAgICAgICAgICAgICAgIDs7IHRoZSBkZW5vbWluYXRvciwgaXQgZmlyc3QgY29tcHV0 ZXMKLSAgICAgICAgICAgICAgICA7OwotICAgICAgICAgICAgICAgIDs7ICAgICBob2xlX2lfY29u dHJpYiA9IDEgKyAoTGktMSleKDEvdGlnaHRuZXNzKQotICAgICAgICAgICAgICAgIDs7Ci0gICAg ICAgICAgICAgICAgOzsgLCBmb3IgZWFjaCBob2xlICJpIiBvZiBsZW5ndGggIkxpIiwgd2hlcmUg dGlnaHRuZXNzCi0gICAgICAgICAgICAgICAgOzsgaXMgZ2l2ZW4gYnkgYGZsZXgtc2NvcmUtbWF0 Y2gtdGlnaHRuZXNzJy4gIFRoZQotICAgICAgICAgICAgICAgIDs7IGZpbmFsIHZhbHVlIGZvciB0 aGUgZGVub21pbmF0b3IgaXMgdGhlbiBnaXZlbiBieToKLSAgICAgICAgICAgICAgICA7OwotICAg ICAgICAgICAgICAgIDs7ICAgIChTVU1fYWNyb3NzX2koaG9sZV9pX2NvbnRyaWIpICsgMSkgKiBs ZW4KLSAgICAgICAgICAgICAgICA7OwotICAgICAgICAgICAgICAgIDs7ICwgd2hlcmUgImxlbiIg aXMgdGhlIHN0cmluZydzIGxlbmd0aC4KLSAgICAgICAgICAgICAgICAoc2NvcmUtbnVtZXJhdG9y IDApCi0gICAgICAgICAgICAgICAgKHNjb3JlLWRlbm9taW5hdG9yIDApCi0gICAgICAgICAgICAg ICAgKGxhc3QtYiAwKQotICAgICAgICAgICAgICAgICh1cGRhdGUtc2NvcmUtYW5kLWZhY2UKLSAg ICAgICAgICAgICAgICAgKGxhbWJkYSAoYSBiKQotICAgICAgICAgICAgICAgICAgICJVcGRhdGUg c2NvcmUgYW5kIGZhY2UgZ2l2ZW4gbWF0Y2ggcmFuZ2UgKEEgQikuIgotICAgICAgICAgICAgICAg ICAgIChhZGQtZmFjZS10ZXh0LXByb3BlcnR5IGEgYgotICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICdjb21wbGV0aW9ucy1jb21tb24tcGFydAotICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5pbCBzdHIpCi0gICAgICAgICAgICAgICAg ICAgKHNldHEKLSAgICAgICAgICAgICAgICAgICAgc2NvcmUtbnVtZXJhdG9yICAgKCsgc2NvcmUt bnVtZXJhdG9yICgtIGIgYSkpKQotICAgICAgICAgICAgICAgICAgICh1bmxlc3MgKG9yICg9IGEg bGFzdC1iKQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICh6ZXJvcCBsYXN0LWIpCi0g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKD0gYSAobGVuZ3RoIHN0cikpKQotICAgICAg ICAgICAgICAgICAgICAgKHNldHEKLSAgICAgICAgICAgICAgICAgICAgICBzY29yZS1kZW5vbWlu YXRvciAoKyBzY29yZS1kZW5vbWluYXRvcgotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDEKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAoZXhwdCAoLSBhIGxhc3QtYiAxKQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICgvIDEuMAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGZsZXgtc2NvcmUtbWF0Y2gtdGlnaHRuZXNzKSkpKSkKLSAgICAg ICAgICAgICAgICAgICAoc2V0cQotICAgICAgICAgICAgICAgICAgICBsYXN0LWIgICAgICAgICAg ICAgIGIpKSkpCi0gICAgICAgICAgICh3aGlsZSBtZAotICAgICAgICAgICAgIChmdW5jYWxsIHVw ZGF0ZS1zY29yZS1hbmQtZmFjZSBmcm9tIChwb3AgbWQpKQotICAgICAgICAgICAgIChzZXRxIGZy b20gKHBvcCBtZCkpKQotICAgICAgICAgICA7OyBJZiBgcGF0dGVybicgZG9lc24ndCBoYXZlIGFu IGV4cGxpY2l0IHRyYWlsaW5nIGFueSwgdGhlCi0gICAgICAgICAgIDs7IHJlZ2V4IGByZScgd29u J3QgcHJvZHVjZSBtYXRjaCBkYXRhIHJlcHJlc2VudGluZyB0aGUKLSAgICAgICAgICAgOzsgcmVn aW9uIGFmdGVyIHRoZSBtYXRjaC4gIFdlIG5lZWQgdG8gYWNjb3VudCB0byBhY2NvdW50Ci0gICAg ICAgICAgIDs7IGZvciB0aGF0IGV4dHJhIGJpdCBvZiBtYXRjaCAoYnVnIzQyMTQ5KS4KLSAgICAg ICAgICAgKHVubGVzcyAoPSBmcm9tIG1hdGNoLWVuZCkKLSAgICAgICAgICAgICAoZnVuY2FsbCB1 cGRhdGUtc2NvcmUtYW5kLWZhY2UgZnJvbSBtYXRjaC1lbmQpKQotICAgICAgICAgICAoaWYgKD4g KGxlbmd0aCBzdHIpIHBvcykKLSAgICAgICAgICAgICAgIChhZGQtZmFjZS10ZXh0LXByb3BlcnR5 Ci0gICAgICAgICAgICAgICAgcG9zICgxKyBwb3MpCi0gICAgICAgICAgICAgICAgJ2NvbXBsZXRp b25zLWZpcnN0LWRpZmZlcmVuY2UKLSAgICAgICAgICAgICAgICBuaWwgc3RyKSkKLSAgICAgICAg ICAgKHVubGVzcyAoemVyb3AgKGxlbmd0aCBzdHIpKQotICAgICAgICAgICAgIChwdXQtdGV4dC1w cm9wZXJ0eQotICAgICAgICAgICAgICAwIDEgJ2NvbXBsZXRpb24tc2NvcmUKLSAgICAgICAgICAg ICAgKC8gc2NvcmUtbnVtZXJhdG9yICgqIGVuZCAoMSsgc2NvcmUtZGVub21pbmF0b3IpKSAxLjAp IHN0cikpKQotICAgICAgICAgc3RyKQotICAgICAgIGNvbXBsZXRpb25zKSkpCisgICAgKGxldCog KChyZSAoY29tcGxldGlvbi1wY20tLXBhdHRlcm4tPnJlZ2V4IHBhdHRlcm4gJ2dyb3VwKSkpCisg ICAgICAoc2V0cSBjb21wbGV0aW9uLXBjbS0tcmVnZXhwIHJlKQorICAgICAgKGNvbmQgKGNvbXBs ZXRpb24tbGF6eS1oaWxpdAorICAgICAgICAgICAgIChzZXRxIGNvbXBsZXRpb24tbGF6eS1oaWxp dC1mbgorICAgICAgICAgICAgICAgICAgIChsYW1iZGEgKHN0cikgKGNvbXBsZXRpb24tLWhpbGl0 LWZyb20tcmUgc3RyIHJlKSkpCisgICAgICAgICAgICAgY29tcGxldGlvbnMpCisgICAgICAgICAg ICAodAorICAgICAgICAgICAgIChtYXBjYXIKKyAgICAgICAgICAgICAgKGxhbWJkYSAoc3RyKQor ICAgICAgICAgICAgICAgIChjb21wbGV0aW9uLS1oaWxpdC1mcm9tLXJlIChjb3B5LXNlcXVlbmNl IHN0cikgcmUpKQorICAgICAgICAgICAgICBjb21wbGV0aW9ucykpKSkpCiAgICAodCBjb21wbGV0 aW9ucykpKQogCiAoZGVmdW4gY29tcGxldGlvbi1wY20tLWZpbmQtYWxsLWNvbXBsZXRpb25zIChz dHJpbmcgdGFibGUgcHJlZCBwb2ludApAQCAtNDE4NywzNiArNDI3NywzOSBAQCBjb21wbGV0aW9u LWZsZXgtbm9zcGFjZQogCiAoZGVmdW4gY29tcGxldGlvbi0tZmxleC1hZGp1c3QtbWV0YWRhdGEg KG1ldGFkYXRhKQogICAiSWYgYGZsZXgnIGlzIGFjdHVhbGx5IGRvaW5nIGZpbHRlcmluZywgYWRq dXN0IHNvcnRpbmcuIgotICAobGV0ICgoZmxleC1pcy1maWx0ZXJpbmctcAotICAgICAgICAgOzsg SlRAMjAxOS0xMi0yMzogRklYTUU6IHRoaXMgaXMga2luZGEgd3JvbmcuICBXaGF0IHdlIG5lZWQK LSAgICAgICAgIDs7IHRvIHRlc3QgaGVyZSBpcyAic29tZSBpbnB1dCB0aGF0IGFjdHVhbGx5IGxl YWRzL2xlZCB0bwotICAgICAgICAgOzsgZmxleCBmaWx0ZXJpbmciLCBub3QgInNvbWV0aGluZyBh ZnRlciB0aGUgbWluaWJ1ZmZlcgotICAgICAgICAgOzsgcHJvbXB0Ii4gIEUuZy4gVGhlIGxhdHRl ciBpcyBhbHdheXMgdHJ1ZSBmb3IgZmlsZQotICAgICAgICAgOzsgc2VhcmNoZXMsIG1lYW5pbmcg d2UnbGwgYmUgZG9pbmcgZXh0cmEgd29yayB3aGVuIHdlCi0gICAgICAgICA7OyBuZWVkbid0Lgot ICAgICAgICAgKG9yIChub3QgKHdpbmRvdy1taW5pYnVmZmVyLXApKQotICAgICAgICAgICAgICg+ IChwb2ludC1tYXgpIChtaW5pYnVmZmVyLXByb21wdC1lbmQpKSkpCisgIChsZXQgKChmbGV4LWlz LWZpbHRlcmluZy1wIGNvbXBsZXRpb24tcGNtLS1yZWdleHApCiAgICAgICAgIChleGlzdGluZy1k c2YKICAgICAgICAgIChjb21wbGV0aW9uLW1ldGFkYXRhLWdldCBtZXRhZGF0YSAnZGlzcGxheS1z b3J0LWZ1bmN0aW9uKSkKICAgICAgICAgKGV4aXN0aW5nLWNzZgogICAgICAgICAgKGNvbXBsZXRp b24tbWV0YWRhdGEtZ2V0IG1ldGFkYXRhICdjeWNsZS1zb3J0LWZ1bmN0aW9uKSkpCiAgICAgKGNs LWZsZXQKLSAgICAgICAgKChjb21wb3NlLWZsZXgtc29ydC1mbgotICAgICAgICAgIChleGlzdGlu Zy1zb3J0LWZuKSA7IHdpc2ggYGNsLWZsZXQnIGhhZCBwcm9wZXIgaW5kZW50YXRpb24uLi4KLSAg ICAgICAgICAobGFtYmRhIChjb21wbGV0aW9ucykKLSAgICAgICAgICAgIChzb3J0Ci0gICAgICAg ICAgICAgKGZ1bmNhbGwgZXhpc3Rpbmctc29ydC1mbiBjb21wbGV0aW9ucykKLSAgICAgICAgICAg ICAobGFtYmRhIChjMSBjMikKLSAgICAgICAgICAgICAgIChsZXQgKChzMSAoZ2V0LXRleHQtcHJv cGVydHkgMCAnY29tcGxldGlvbi1zY29yZSBjMSkpCi0gICAgICAgICAgICAgICAgICAgICAoczIg KGdldC10ZXh0LXByb3BlcnR5IDAgJ2NvbXBsZXRpb24tc2NvcmUgYzIpKSkKLSAgICAgICAgICAg ICAgICAgKD4gKG9yIHMxIDApIChvciBzMiAwKSkpKSkpKSkKKyAgICAgICAgKChjb21wb3NlLWZs ZXgtc29ydC1mbiAoZXhpc3Rpbmctc29ydC1mbikKKyAgICAgICAgICAgKGxhbWJkYSAoY29tcGxl dGlvbnMpCisgICAgICAgICAgICAgKGxldCogKChzb3J0ZWQgKHNvcnQKKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKG1hcGNhcgorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGxh bWJkYSAoc3RyKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoY29ucworICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKC0gKGNvbXBsZXRpb24tLWZsZXgtc2NvcmUKKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAob3IgKGdldC10ZXh0LXByb3BlcnR5 CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICdjb21wbGV0aW9u LS11bnF1b3RlZCBzdHIpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHN0cikKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb21wbGV0aW9uLXBj bS0tcmVnZXhwKSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cikpCisgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAoaWYgZXhpc3Rpbmctc29ydC1mbgorICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIChmdW5jYWxsIGV4aXN0aW5nLXNvcnQtZm4gY29tcGxl dGlvbnMpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbXBsZXRpb25zKSkKKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIydjYXItbGVzcy10aGFuLWNhcikpCisgICAgICAg ICAgICAgICAgICAgIChjZWxsIHNvcnRlZCkpCisgICAgICAgICAgICAgICA7OyBSZXVzZSB0aGUg bGlzdAorICAgICAgICAgICAgICAgKHdoaWxlIGNlbGwKKyAgICAgICAgICAgICAgICAgKHNldGNh ciBjZWxsIChjZGFyIGNlbGwpKQorICAgICAgICAgICAgICAgICAocG9wIGNlbGwpKQorICAgICAg ICAgICAgICAgc29ydGVkKSkpKQogICAgICAgYChtZXRhZGF0YQogICAgICAgICAsQChhbmQgZmxl eC1pcy1maWx0ZXJpbmctcAotICAgICAgICAgICAgICAgYCgoZGlzcGxheS1zb3J0LWZ1bmN0aW9u Ci0gICAgICAgICAgICAgICAgICAuICwoY29tcG9zZS1mbGV4LXNvcnQtZm4gKG9yIGV4aXN0aW5n LWRzZiAjJ2lkZW50aXR5KSkpKSkKKyAgICAgICAgICAgICAgIGAoKGRpc3BsYXktc29ydC1mdW5j dGlvbiAuICwoY29tcG9zZS1mbGV4LXNvcnQtZm4gZXhpc3RpbmctZHNmKSkpKQogICAgICAgICAs QChhbmQgZmxleC1pcy1maWx0ZXJpbmctcAotICAgICAgICAgICAgICAgYCgoY3ljbGUtc29ydC1m dW5jdGlvbgotICAgICAgICAgICAgICAgICAgLiAsKGNvbXBvc2UtZmxleC1zb3J0LWZuIChvciBl eGlzdGluZy1jc2YgIydpZGVudGl0eSkpKSkpCisgICAgICAgICAgICAgICBgKChjeWNsZS1zb3J0 LWZ1bmN0aW9uIC4gLChjb21wb3NlLWZsZXgtc29ydC1mbiBleGlzdGluZy1jc2YpKSkpCiAgICAg ICAgICxAKGNkciBtZXRhZGF0YSkpKSkpCiAKIChkZWZ1biBjb21wbGV0aW9uLWZsZXgtLW1ha2Ut ZmxleC1wYXR0ZXJuIChwYXR0ZXJuKQo= --0000000000003d98570609284c82--
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 1 Nov 2023 22:46:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 01 18:46:11 2023
Received: from localhost ([127.0.0.1]:53446 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qyJyR-00087w-HU
for submit <at> debbugs.gnu.org; Wed, 01 Nov 2023 18:46:11 -0400
Received: from out2-smtp.messagingengine.com ([66.111.4.26]:50883)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <dmitry@HIDDEN>) id 1qyJyL-00087J-Qf
for 47711 <at> debbugs.gnu.org; Wed, 01 Nov 2023 18:46:06 -0400
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
by mailout.nyi.internal (Postfix) with ESMTP id 0F1025C0212;
Wed, 1 Nov 2023 18:45:22 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
by compute4.internal (MEProxy); Wed, 01 Nov 2023 18:45:22 -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=
1698878722; x=1698965122; bh=ePzhaBKxh8el6GMSrfuuAt8RiLBLPV6ogI9
K8442gAg=; b=jWlTBtOFRpumllmMKFdUPrbI7UybNlOHN+vsLsVajPpCFUgbMC8
+tAeKlJGo4KNMAEGm50AIZqTnknC44UIeFOL7Xa8pvid7u1rgItOFCtbLqTjySLX
KofL744YRKJYKdtqedw9AnBN+6zW0UZ4MVOFWlQSCvbpTLI3FaMavFOhzHe/rY6u
Ic4Fl515bgZ5j3PqXz/4kBIP2YiACWro8hwGGAtWmC6bjBcrR16EHvVkka+N3o8R
xBTGjaoEj1C4g51zg4sw2xB6FO7O1+9U/sB1u0OCVIN7jzs5M6zQ4E+2a7hUmk0B
FLh/5LpR5pwQXn106JQtaroZhy/WI/S4k1w==
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=
1698878722; x=1698965122; bh=ePzhaBKxh8el6GMSrfuuAt8RiLBLPV6ogI9
K8442gAg=; b=rlntdExTkMDMDbCwz73RCYm/xKb4T4Mgw4eKXTAKCV8DVi4Q610
ML8UzuhKjmkQJpbp7QQsulOeMfcrivdSWBhHpuRuqv4Rj6+lM+yqkemtFHSGxGMG
tVFGZeHrwMSDIHLjdNb2z+kGpa8D0nFe4fMR5/mTHYwvqw0ZlcgPc5RARoRyyK/A
0n3FxVlLu7bq4yqcpS2Wuwgo8BACvPrIpIKyLTFFW0VJuWw79jFGLbkkgztis9HX
uVmmlRYuEkoOk4M57rlvX/7gXa1MxNM/ljFhC+qqbu3SMoAH/kRwl88VEq8xw99L
0dlE6Yg9pECeKbXCZpDUXs5U3amPEKCbEVg==
X-ME-Sender: <xms:ANVCZRWRxfSZYPc2FwzNAoFzNNXPuRiypeYzia3Vj_JDACfCgbDazw>
<xme:ANVCZRnAyfWKCwb4gq8sv--gYPUc-XNiD8JlS4Qs4JpACE9zaW65M40FihSqXtR0m
k81_icghzDCkNU5PDA>
X-ME-Received: <xmr:ANVCZdaY6aW98CWQdxiVdc-8SXOjhHw0a_rNwtS8iaENEzW_FAID8SY7eBHBOxo>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddthedgtddvucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi
thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth
htvghrnhephfffheeljeffgeffueeghfekkedtfffgheejvdegjeettdduheeufffggfef
jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug
hmihhtrhihsehguhhtohhvrdguvghv
X-ME-Proxy: <xmx:ANVCZUXD8UFZ5brzVm0KeuL4FcfhzshxPTDbFTXf48XLUIb8yc2Jtw>
<xmx:ANVCZbnmP19ktgrcCwt19foQFee-QV7E7zHd23fK5fN_Q3oDmFl5sA>
<xmx:ANVCZRcP8pglAiB6gVzHaaeiqm_Mgog6ACPZis6vL4cu2QecEkoBqQ>
<xmx:AtVCZZigjmuWaGMgFH4m8BNwQDIqBjNXPmY9dL9L3J-kuq3BR4jMOQ>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
1 Nov 2023 18:45:19 -0400 (EDT)
Message-ID: <31cadbfd-d086-a04f-0ed9-17ce70b4282c@HIDDEN>
Date: Thu, 2 Nov 2023 00:45:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.13.0
Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add
new `completion-filter-completions` API and deferred highlighting
Content-Language: en-US
To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN>
<CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN>
<328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN>
<9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN>
<9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN>
<CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN>
<7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN>
<CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN>
<5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <877cn8asud.fsf@HIDDEN>
<c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN> <8734xtauqj.fsf@HIDDEN>
<eeabbe1f-7b2d-ade5-949c-05aea0ba85a9@HIDDEN>
<CALDnm51kS6p9V7z1AT=+TFp6kM5xw5Xv_oWZFSqAuEKx=-=a2A@HIDDEN>
<5181f95e-61e7-c8c4-6389-44ee57e0c749@HIDDEN>
<CALDnm51p7awjuw4vFMC=UByXnFUYMHsecUaSrT=Jiii5S3fgxQ@HIDDEN>
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <CALDnm51p7awjuw4vFMC=UByXnFUYMHsecUaSrT=Jiii5S3fgxQ@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.2 (--)
X-Debbugs-Envelope-To: 47711
Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.2 (---)
On 01/11/2023 20:47, João Távora wrote:
> On Tue, Oct 31, 2023 at 8:52 PM Dmitry Gutov <dmitry@HIDDEN> wrote:
>
>> It seems like the only code that would be concerned with it are
>> completion styles that also do sorting, or completion tables that would
>> do similar things to this "with quoting" business. But I'm not aware of
>> any other examples of the latter aside from what is inside Emacs itself.
>
> If orderless (which I've never tried), does some kind of scoring of
> completions, it probably also needs the same complications of flex.
Turns out, Orderless doesn't do any scoring or sorting. Only filtering.
>>>> Anyway, have you looked into what it would take to solve it?
>>>
>>> No, naively, I just think it's a similar situation of display and business
>>> logic being mixed up. Presumably the quoted stuff is just for insertion
>>> (and display?), and the unquoted stuff is what patterns/scoring should
>>> operate on.
>>
>> Apparently it's good for insertion, but according to that comment inside
>> the function, the unquoted stuff might actually be better for display.
>
> No idea what the unquoted stuff is for, so I haven't really tested it.
A couple of scenarios:
First:
1. sudo mkdir /home/${USER}-foobar
2. C-x C-f /home/${USER} TAB ; it shows both directories inside home as
${USER}-foo/
${USER}/
Second:
1. mkdir ~/examples/test\ test\ test/
2. mkdir ~/examples/test\ test/
3. M-x shell
4. In the shell buffer, type 'ls ~/examples/test\ ' and TAB. See:
test\ test/
test\ test\ test/
In the current implementation, both the inputs and the text in the
completions buffer that we see, are "quoted". The "unquoted" versions
would be the directory name with the variable substitution performed,
and the directory names without backslashes.
>> I'm not 100% clear which of the versions is better for
>> scoring/highlighting, but apparently the unquoted one.
>>
>>> But, IMO, there's no need to tackle it right now.
>>>
>>> If the thing holding you back from the lazy-hilit-2023-v4.patch is the
>>> completion-score propertization, I can move it to the sorting step
>>> in a future v5 and add spread the completion--unquoted thing a little
>>> bit more.
>>
>> I think that's the main blocker, yes.
>
> Alright, here goes v5 then, with this change. Note I've implemented
> this unquoted thing which kicks in in C-x f but I haven't actually
> seen any strings that have different "quoted" "non-quoted" versions.
>
> The performance of the three main patches as measured in yet
> another machine:
>
> ;; C-h v
> ;;
> ;; Daniel+Dmitry: 0.696340454545
> ;; lazy hilit v4: 0.692849642852
> ;; lazy hilit v5: 0.683088541667
> ;;
> ;; completing-read
> ;;
> ;; Daniel+Dmitry: 0.590994909091
> ;; lazy hilit v4: 0.586523307692
> ;; lazy hilit v5: 0.586165466667
>
> Nothing unexpected.
Confirm. The "property allocation" spikes are gone too.
> So if you're satisfied with the general design now, maybe
> we should start looking at finer details, docstrings, style,
> etc.
LGTM overall, and I see that you compressed the sorting code a little.
Both quoting/unquoting scenarios also seem to work as expected (for
highlighting, that seems to be thanks to completion--twq-all applying
the faces eagerly anyway).
Though given the examples (and I think others should be similar) it
wouldn't be an end of the world if scoring didn't really work for them
-- filtering should have already done most of the job. All of this is to
say that any new 3rd party completion styles, even those that do
sorting, would be okay without knowing about this text property.
Some minor nits for the patch:
> +Completion-presenting frontends may opt to bind this variable to
> +non-nil value in the context of completion-producing calls (such
> +as `completion-all-sorted-completions'). This hints the
I suggest mentioning `completion-all-completions' instead, as it is more
often used directly by the frontends.
> +responsible this fontification. The frontend binds this variable
responsible for
> +hint and greedily fontify as usual. It is still safe for a
"fontify eagerly"? I think that's a more common term than "greedily".
> + "Used by completions styles to honouring `completion-lazy-hilit'.
"to honour", or "styles honouring"
> +(defun completion--flex-score (str re &optional dont-error)
Looks like the third argument is unused in both callers. I think it was
intended for compose-flex-sort-fn.
> +see) for later lazy highlighting"
Missing period.
> + ;; Lazy highlight not requested, so strings are
> + ;; assumed to already contain `completion-> score'
> + ;; (and highlighting) and we can freely destroy
> + ;; list.
Perhaps drop the last two lines, since IIUC the list can be
destructively sorted in both cases, lazy highlighting or not.
I guess we should wait a few days to see if anyone has more comments,
and then install this?
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 1 Nov 2023 18:48:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 01 14:48:22 2023 Received: from localhost ([127.0.0.1]:52590 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qyGGL-0004Rr-K5 for submit <at> debbugs.gnu.org; Wed, 01 Nov 2023 14:48:21 -0400 Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]:61612) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1qyGGI-0004Qn-CU for 47711 <at> debbugs.gnu.org; Wed, 01 Nov 2023 14:48:19 -0400 Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-507c78d258fso15105e87.2 for <47711 <at> debbugs.gnu.org>; Wed, 01 Nov 2023 11:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698864458; x=1699469258; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1S1P1Rvp+/E8RRp5zTdqQn/jlY6JT6Wqe4rWmjXpORU=; b=kGEIaAfZ/mFnVtjslnPwnDFgYrES8+2LGnDeSI5uC+3HRBp6cg/hPl1ercgmREiZwl yyCDadWu7dui+YsuYzEUMSQb6LOt9KYp+kvtwNy04wwXUZjaTNyI0H6+SUKUDPuqzaGM kFTvmeRGUtrgZ5aiQuxlaFd9HIc69hlb+9UVClepsUJ0Te+yVMoycamnpvs395OHPSWp UlciQLBQyXrBAqE0aoadfDp9MRP0nj08sxDAaIN5ycFiIxF5L4qVHLtTdSmIoG22fILB G5b5eUgcs73rnjmNM4ypyFzPZnxRvv5LHZVYFw3CUK6wAn1cxWmVrzOCmi5z8D/hZWym d5KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698864458; x=1699469258; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1S1P1Rvp+/E8RRp5zTdqQn/jlY6JT6Wqe4rWmjXpORU=; b=CFjGx7fwAHFnT4eXq9f/xgltNHfvKeJ5kZDq+BWhm+jsAGvqTnkRYSDqk6n+79Z2vb 7QDs5PAeY44i7Amg1/DCnQLAU3qCDCNqZ0OLS0CPwD/VsuxzkFf5QhmFw2TPf3rUuEcP ddFV1YeJArWkxdaSTBKtkLR/EGiozDRrB8PtaHsIN9yoq2uD/eZK7T0ci93jj8t5LkT7 HaOAq73qF1DcWYl5slj5U2n+Bl4rzja/26Hl+xqtoLKq9o7nBCauzkdSlLbHsJPDGgyp IJmj+UR05kO/AppHUdOgCjklrJhxNPQ8bsKYcBDXXbV4Sb+Np1vfZPSXXv5mlE3Cd87B 0zhA== X-Gm-Message-State: AOJu0YyeP/sN/6DiEYHa8EDpt/iVBHspxi+HpVrW7IuUpKI2/5HAiEXz iHRzEMq/52pPQK1eVFZ+r4Qi1MN2zzRDpzgHtms= X-Google-Smtp-Source: AGHT+IEt1v+diB7k5uf6Nsx0MzQVgdWq2pDuw6cshsS6yfUCBxTcTLGTfL3A3Vuq/L3zbnOu6rsRJjMKr+XdfR6yQEs= X-Received: by 2002:a05:6512:401d:b0:505:783f:bc65 with SMTP id br29-20020a056512401d00b00505783fbc65mr15313758lfb.66.1698864457605; Wed, 01 Nov 2023 11:47:37 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <877cn8asud.fsf@HIDDEN> <c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN> <8734xtauqj.fsf@HIDDEN> <eeabbe1f-7b2d-ade5-949c-05aea0ba85a9@HIDDEN> <CALDnm51kS6p9V7z1AT=+TFp6kM5xw5Xv_oWZFSqAuEKx=-=a2A@HIDDEN> <5181f95e-61e7-c8c4-6389-44ee57e0c749@HIDDEN> In-Reply-To: <5181f95e-61e7-c8c4-6389-44ee57e0c749@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Wed, 1 Nov 2023 18:47:25 +0000 Message-ID: <CALDnm51p7awjuw4vFMC=UByXnFUYMHsecUaSrT=Jiii5S3fgxQ@HIDDEN> Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Dmitry Gutov <dmitry@HIDDEN> Content-Type: multipart/mixed; boundary="00000000000084ce9b06091bb41d" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --00000000000084ce9b06091bb41d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 31, 2023 at 8:52=E2=80=AFPM Dmitry Gutov <dmitry@HIDDEN> wro= te: > It seems like the only code that would be concerned with it are > completion styles that also do sorting, or completion tables that would > do similar things to this "with quoting" business. But I'm not aware of > any other examples of the latter aside from what is inside Emacs itself. If orderless (which I've never tried), does some kind of scoring of completions, it probably also needs the same complications of flex. > >> Anyway, have you looked into what it would take to solve it? > > > > No, naively, I just think it's a similar situation of display and busin= ess > > logic being mixed up. Presumably the quoted stuff is just for insertio= n > > (and display?), and the unquoted stuff is what patterns/scoring should > > operate on. > > Apparently it's good for insertion, but according to that comment inside > the function, the unquoted stuff might actually be better for display. No idea what the unquoted stuff is for, so I haven't really tested it. > I'm not 100% clear which of the versions is better for > scoring/highlighting, but apparently the unquoted one. > > > But, IMO, there's no need to tackle it right now. > > > > If the thing holding you back from the lazy-hilit-2023-v4.patch is the > > completion-score propertization, I can move it to the sorting step > > in a future v5 and add spread the completion--unquoted thing a little > > bit more. > > I think that's the main blocker, yes. Alright, here goes v5 then, with this change. Note I've implemented this unquoted thing which kicks in in C-x f but I haven't actually seen any strings that have different "quoted" "non-quoted" versions. The performance of the three main patches as measured in yet another machine: ;; C-h v ;; ;; Daniel+Dmitry: 0.696340454545 ;; lazy hilit v4: 0.692849642852 ;; lazy hilit v5: 0.683088541667 ;; ;; completing-read ;; ;; Daniel+Dmitry: 0.590994909091 ;; lazy hilit v4: 0.586523307692 ;; lazy hilit v5: 0.586165466667 Nothing unexpected. So if you're satisfied with the general design now, maybe we should start looking at finer details, docstrings, style, etc. Jo=C3=A3o --00000000000084ce9b06091bb41d Content-Type: application/octet-stream; name="lazy-hilit-2023-v5.diff" Content-Disposition: attachment; filename="lazy-hilit-2023-v5.diff" Content-Transfer-Encoding: base64 Content-ID: <f_log40lhy0> X-Attachment-Id: f_log40lhy0 ZGlmZiAtLWdpdCBhL2xpc3AvaWNvbXBsZXRlLmVsIGIvbGlzcC9pY29tcGxldGUuZWwKaW5kZXgg ZTZmZGQxZjE4MzYuLjNlODg4YzhiMDZhIDEwMDY0NAotLS0gYS9saXNwL2ljb21wbGV0ZS5lbAor KysgYi9saXNwL2ljb21wbGV0ZS5lbApAQCAtNzIyLDcgKzcyMiw4IEBAIGljb21wbGV0ZS1leGhp Yml0CiAgICAgICAgICAgICAgOzsgQ2hlY2sgaWYgc3RpbGwgaW4gdGhlIHJpZ2h0IGJ1ZmZlciAo YnVnIzYxMzA4KQogICAgICAgICAgICAgIChvciAod2luZG93LW1pbmlidWZmZXItcCkgY29tcGxl dGlvbi1pbi1yZWdpb24tLWRhdGEpCiAgICAgICAgICAgICAgKGljb21wbGV0ZS1zaW1wbGUtY29t cGxldGluZy1wKSkgO1Nob3VsZG4ndCBiZSBuZWNlc3NhcnkuCi0gICAgKGxldCAoKHNhdmVkLXBv aW50IChwb2ludCkpKQorICAgIChsZXQgKChzYXZlZC1wb2ludCAocG9pbnQpKQorICAgICAgICAg IChjb21wbGV0aW9uLWxhenktaGlsaXQgdCkpCiAgICAgICAoc2F2ZS1leGN1cnNpb24KICAgICAg ICAgKGdvdG8tY2hhciAoaWNvbXBsZXRlLS1maWVsZC1lbmQpKQogICAgICAgICA7OyBJbnNlcnQg dGhlIG1hdGNoLXN0YXR1cyBpbmZvcm1hdGlvbjoKQEAgLTc1NCwxMiArNzU1LDEzIEBAIGljb21w bGV0ZS1leGhpYml0CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAob3ZlcmxheS1lbmQgcmZu LWVzaGFkb3ctb3ZlcmxheSkpKQogICAgICAgICAgIChsZXQqICgoZmllbGQtc3RyaW5nIChpY29t cGxldGUtLWZpZWxkLXN0cmluZykpCiAgICAgICAgICAgICAgICAgICh0ZXh0ICh3aGlsZS1uby1p bnB1dAorICAgICAgICAgICAgICAgICAgICAgICAgIChiZW5jaG1hcmstcHJvZ24KICAgICAgICAg ICAgICAgICAgICAgICAgICAoaWNvbXBsZXRlLWNvbXBsZXRpb25zCiAgICAgICAgICAgICAgICAg ICAgICAgICAgIGZpZWxkLXN0cmluZwogICAgICAgICAgICAgICAgICAgICAgICAgICAoaWNvbXBs ZXRlLS1jb21wbGV0aW9uLXRhYmxlKQogICAgICAgICAgICAgICAgICAgICAgICAgICAoaWNvbXBs ZXRlLS1jb21wbGV0aW9uLXByZWRpY2F0ZSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgKGlm ICh3aW5kb3ctbWluaWJ1ZmZlci1wKQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGVx IG1pbmlidWZmZXItLXJlcXVpcmUtbWF0Y2ggdCkpKSkpCisgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAoZXEgbWluaWJ1ZmZlci0tcmVxdWlyZS1tYXRjaCB0KSkpKSkpCiAgICAgICAgICAg ICAgICAgIChidWZmZXItdW5kby1saXN0IHQpCiAgICAgICAgICAgICAgICAgIGRlYWN0aXZhdGUt bWFyaykKICAgICAgICAgICAgIDs7IERvIG5vdGhpbmcgaWYgd2hpbGUtbm8taW5wdXQgd2FzIGFi b3J0ZWQuCkBAIC05MDEsNyArOTAzLDcgQEAgaWNvbXBsZXRlLS1yZW5kZXItdmVydGljYWwKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJ2ljb21wbGV0ZS1zZWxlY3RlZC1tYXRjaCAn YXBwZW5kIGNvbXApCiAgICAgIGNvbGxlY3QgKGNvbmNhdCBwcmVmaXgKICAgICAgICAgICAgICAg ICAgICAgIChtYWtlLXN0cmluZyAoLSBtYXgtcHJlZml4LWxlbiAobGVuZ3RoIHByZWZpeCkpID8g KQotICAgICAgICAgICAgICAgICAgICAgY29tcAorICAgICAgICAgICAgICAgICAgICAgKGNvbXBs ZXRpb24tbGF6eS1oaWxpdCBjb21wKQogICAgICAgICAgICAgICAgICAgICAgKG1ha2Utc3RyaW5n ICgtIG1heC1jb21wLWxlbiAobGVuZ3RoIGNvbXApKSA/ICkKICAgICAgICAgICAgICAgICAgICAg IHN1ZmZpeCkKICAgICAgaW50byBsaW5lcy1hdXgKQEAgLTEwNjcsNyArMTA2OSw4IEBAIGljb21w bGV0ZS1jb21wbGV0aW9ucwogICAgICAgICAgICAgICAgICAgKGlmICg8IHByb3NwZWN0cy1sZW4g cHJvc3BlY3RzLW1heCkKICAgICAgICAgICAgICAgICAgICAgICAocHVzaCBjb21wIHByb3NwZWN0 cykKICAgICAgICAgICAgICAgICAgICAgKHNldHEgbGltaXQgdCkpKQotICAgICAgICAgICAgICAg IChzZXRxIHByb3NwZWN0cyAobnJldmVyc2UgcHJvc3BlY3RzKSkKKyAgICAgICAgICAgICAgICAo c2V0cSBwcm9zcGVjdHMKKyAgICAgICAgICAgICAgICAgICAgICAobnJldmVyc2UgKG1hcGNhciAj J2NvbXBsZXRpb24tbGF6eS1oaWxpdCBwcm9zcGVjdHMpKSkKICAgICAgICAgICAgICAgICA7OyBE ZWNvcmF0ZSBmaXJzdCBvZiB0aGUgcHJvc3BlY3RzLgogICAgICAgICAgICAgICAgICh3aGVuIHBy b3NwZWN0cwogICAgICAgICAgICAgICAgICAgKGxldCAoKGZpcnN0IChjb3B5LXNlcXVlbmNlIChw b3AgcHJvc3BlY3RzKSkpKQpkaWZmIC0tZ2l0IGEvbGlzcC9taW5pYnVmZmVyLmVsIGIvbGlzcC9t aW5pYnVmZmVyLmVsCmluZGV4IDIxMjBlMzE3NzVlLi4yYjBmZjVjMWMzYyAxMDA2NDQKLS0tIGEv bGlzcC9taW5pYnVmZmVyLmVsCisrKyBiL2xpc3AvbWluaWJ1ZmZlci5lbApAQCAtNjc3LDYgKzY3 NywxMCBAQCBjb21wbGV0aW9uLS10d3EtYWxsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAnY29tcGxldGlvbnMtY29tbW9uLXBhcnQpCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgcXByZWZpeCkpKSkKICAgICAgICAgICAgICAgICAgICAgICAgIChx Y29tcGxldGlvbiAoY29uY2F0IHFwcmVmaXggcW5ldykpKQorICAgICAgICAgICAgICAgICAgIDs7 IEF0dGFjaCB1bnF1b3RlZCBjb21wbGV0aW9uIHN0cmluZywgd2hpY2ggaXMgbmVlZGVkCisgICAg ICAgICAgICAgICAgICAgOzsgdG8gc2NvcmUgdGhlIGNvbXBsZXRpb24gaW4gYGNvbXBsZXRpb24t LWZsZXgtc2NvcmUnLgorICAgICAgICAgICAgICAgICAgIChwdXQtdGV4dC1wcm9wZXJ0eSAwIDEg J2NvbXBsZXRpb24tLXVucXVvdGVkCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGNvbXBsZXRpb24gcWNvbXBsZXRpb24pCiAJCSAgIDs7IEZJWE1FOiBTaW1pbGFybHkgaGVy ZSwgQ3lnd2luJ3MgbWFwcGluZyB0cmlwcyB0aGlzCiAJCSAgIDs7IGFzc2VydGlvbi4KICAgICAg ICAgICAgICAgICAgICA7OyhjbC1hc3NlcnQKQEAgLTEyMzQsNiArMTIzOCw3IEBAIGNvbXBsZXRp b24tYWxsLWNvbXBsZXRpb25zCiBQT0lOVCBpcyB0aGUgcG9zaXRpb24gb2YgcG9pbnQgd2l0aGlu IFNUUklORy4KIFRoZSByZXR1cm4gdmFsdWUgaXMgYSBsaXN0IG9mIGNvbXBsZXRpb25zIGFuZCBt YXkgY29udGFpbiB0aGUgYmFzZS1zaXplCiBpbiB0aGUgbGFzdCBgY2RyJy4iCisgIChzZXRxIGNv bXBsZXRpb24tbGF6eS1oaWxpdC1mbiBuaWwpCiAgIDs7IEZJWE1FOiBXZSBuZWVkIHRvIGFkZGl0 aW9uYWxseSByZXR1cm4gdGhlIGluZm8gbmVlZGVkIGZvciB0aGUKICAgOzsgc2Vjb25kIHBhcnQg b2YgY29tcGxldGlvbi1iYXNlLXBvc2l0aW9uLgogICAoY29tcGxldGlvbi0tbnRoLWNvbXBsZXRp b24gMiBzdHJpbmcgdGFibGUgcHJlZCBwb2ludCBtZXRhZGF0YSkpCkBAIC0zNzQ5LDEwOCArMzc1 NCwyMDAgQEAgZmxleC1zY29yZS1tYXRjaC10aWdodG5lc3MKIHRoYW4gdGhlIGxhdHRlciAod2hp Y2ggaGFzIHR3byBcImhvbGVzXCIgYW5kIHRocmVlCiBvbmUtbGV0dGVyLWxvbmcgbWF0Y2hlcyku IikKIAorKGRlZnZhci1sb2NhbCBjb21wbGV0aW9uLWxhenktaGlsaXQgbmlsCisgICJJZiBub24t bmlsLCByZXF1ZXN0IGNvbXBsZXRpb24gbGF6eSBoaWdobGlnaHRpbmcuCisKK0NvbXBsZXRpb24t cHJlc2VudGluZyBmcm9udGVuZHMgbWF5IG9wdCB0byBiaW5kIHRoaXMgdmFyaWFibGUgdG8KK25v bi1uaWwgdmFsdWUgaW4gdGhlIGNvbnRleHQgb2YgY29tcGxldGlvbi1wcm9kdWNpbmcgY2FsbHMg KHN1Y2gKK2FzIGBjb21wbGV0aW9uLWFsbC1zb3J0ZWQtY29tcGxldGlvbnMnKS4gIFRoaXMgaGlu dHMgdGhlCitpbnRlcnZlbmluZyBjb21wbGV0aW9uIHN0eWxlcyB0aGF0IHRoZXkgZG8gbm90IG5l ZWQgdG8KK2ZvbnRpZnkgKGkuZS4gcHJvcGVydGl6ZSB3aXRoIHRoZSBgZmFjZScgcHJvcGVydHkp IGNvbXBsZXRpb24KK3N0cmluZ3Mgd2l0aCBoaWdobGlnaHRzIG9mIHRoZSBtYXRjaGluZyBwYXJ0 cy4KKworV2hlbiBkb2luZyBzbywgaXQgaXMgdGhlIGZyb250ZW5kIC0tIG5vdCB0aGUgc3R5bGUg LS0gd2hvIGJlY29tZXMKK3Jlc3BvbnNpYmxlIHRoaXMgZm9udGlmaWNhdGlvbi4gIFRoZSBmcm9u dGVuZCBiaW5kcyB0aGlzIHZhcmlhYmxlCit0byBub24tbmlsLCBhbmQgY2FsbHMgdGhlIGZ1bmN0 aW9uIHdpdGggdGhlIHNhbWUgbmFtZQorYGNvbXBsZXRpb24tbGF6eS1oaWxpdCcgb24gZWFjaCBj b21wbGV0aW9uIHN0cmluZyB0aGF0IGlzIHRvIGJlCitkaXNwbGF5ZWQgdG8gdGhlIHVzZXIuCisK K05vdGUgdGhhdCBvbmx5IHNvbWUgY29tcGxldGlvbiBzdHlsZXMgdGFrZSBhZHZhbnRhZ2Ugb2Yg dGhpcwordmFyaWFibGUgZm9yIG9wdGltaXphdGlvbiBwdXJwb3Nlcy4gIE90aGVyIHN0eWxlcyB3 aWxsIGlnbm9yZSB0aGUKK2hpbnQgYW5kIGdyZWVkaWx5IGZvbnRpZnkgYXMgdXN1YWwuICBJdCBp cyBzdGlsbCBzYWZlIGZvciBhCitmcm9udGVuZCB0byBjYWxsIGBjb21wbGV0aW9uLWxhenktaGls aXQnIGluIHRoZXNlIHNpdHVhdGlvbnMuCisKK1RvIGF1dGhvciBhIGNvbXBsZXRpb24gc3R5bGUg dGhhdCB0YWtlcyBhZHZhbnRhZ2Ugc2VlCitgY29tcGxldGlvbi1sYXp5LWhpbGl0LWZuJyBhbmQg bG9vayBpbiB0aGUgc291cmNlIG9mCitgY29tcGxldGlvbi1wY20tLWhpbGl0LWNvbW1vbmFsaXR5 Jy4iKQorCisoZGVmdmFyIGNvbXBsZXRpb24tbGF6eS1oaWxpdC1mbiBuaWwKKyAgIlVzZWQgYnkg Y29tcGxldGlvbnMgc3R5bGVzIHRvIGhvbm91cmluZyBgY29tcGxldGlvbi1sYXp5LWhpbGl0Jy4K K1doZW4gYSBnaXZlbiBzdHlsZSB3YW50cyB0byBlbmFibGUgc3VwcG9ydCBmb3IKK2Bjb21wbGV0 aW9uLWxhenktaGlsaXQnICh3aGljaCBzZWUpLCB0aGF0IHN0eWxlIHNob3VsZCBzZXQgdGhpcwor dmFyaWFibGUgdG8gYSBmdW5jdGlvbiBvZiBvbmUgYXJndW1lbnQsIGEgZnJlc2ggc3RyaW5nIHRv IGJlCitkaXNwbGF5ZWQgdG8gdGhlIHVzZXIuICBUaGUgZnVuY3Rpb24gaXMgcmVzcG9uc2libGUg Zm9yCitkZXN0cnVjdGl2ZWx5IGhpZ2hsaWdodGluZyB0aGUgc3RyaW5nLiIpCisKKyhkZWZ1biBj b21wbGV0aW9uLWxhenktaGlsaXQgKHN0cikKKyAgIlJldHVybiBhIGNvcHkgb2YgY29tcGxldGlv biBTVFIgdGhhdCBpcyBgZmFjZSctcHJvcGVydGl6ZWQuCitTZWUgZG9jdW1lbnRhdGlvbiBmb3Ig dmFyaWFibGUgYGNvbXBsZXRpb24tbGF6eS1oaWxpdCcgZm9yIG1vcmUKK2RldGFpbHMuIgorICAo aWYgKGFuZCBjb21wbGV0aW9uLWxhenktaGlsaXQgY29tcGxldGlvbi1sYXp5LWhpbGl0LWZuKQor ICAgICAgKGZ1bmNhbGwgY29tcGxldGlvbi1sYXp5LWhpbGl0LWZuIChjb3B5LXNlcXVlbmNlIHN0 cikpCisgICAgc3RyKSkKKworKGRlZnVuIGNvbXBsZXRpb24tLWhpbGl0LWZyb20tcmUgKHN0cmlu ZyByZWdleHApCisgICJGb250aWZ5IFNUUklORyB3aXRoIGBjb21wbGV0aW9ucy1jb21tb24tcGFy dCcgdXNpbmcgUkVHRVhQLiIKKyAgKGxldCogKChtZCAoYW5kIHJlZ2V4cCAoc3RyaW5nLW1hdGNo IHJlZ2V4cCBzdHJpbmcpIChjZGRyIChtYXRjaC1kYXRhIHQpKSkpCisgICAgICAgICAobWUgKGFu ZCBtZCAobWF0Y2gtZW5kIDApKSkKKyAgICAgICAgIChmcm9tIDApKQorICAgICh3aGlsZSBtZAor ICAgICAgKGFkZC1mYWNlLXRleHQtcHJvcGVydHkgZnJvbSAocG9wIG1kKSAnY29tcGxldGlvbnMt Y29tbW9uLXBhcnQgbmlsIHN0cmluZykKKyAgICAgIChzZXRxIGZyb20gKHBvcCBtZCkpKQorICAg ICh1bmxlc3MgKG9yIChub3QgbWUpICg9IGZyb20gbWUpKQorICAgICAgKGFkZC1mYWNlLXRleHQt cHJvcGVydHkgZnJvbSBtZSAnY29tcGxldGlvbnMtY29tbW9uLXBhcnQgbmlsIHN0cmluZykpCisg ICAgc3RyaW5nKSkKKworKGRlZnVuIGNvbXBsZXRpb24tLWZsZXgtc2NvcmUtMSAobWQtZ3JvdXBz IG1hdGNoLWVuZCBsZW4pCisgICJDb21wdXRlIG1hdGNoaW5nIHNjb3JlIG9mIGNvbXBsZXRpb24u CitUaGUgc2NvcmUgbGllcyBpbiB0aGUgcmFuZ2UgYmV0d2VlbiAwIGFuZCAxLCB3aGVyZSAxIGNv cnJlc3BvbmRzIHRvCit0aGUgZnVsbCBtYXRjaC4KK01ELUdST1VQUyBpcyB0aGUgXCJncm91cFwi ICBwYXJ0IG9mIHRoZSBtYXRjaCBkYXRhLgorTUFUQ0gtRU5EIGlzIHRoZSBlbmQgb2YgdGhlIG1h dGNoLgorTEVOIGlzIHRoZSBsZW5ndGggb2YgdGhlIGNvbXBsZXRpb24gc3RyaW5nLiIKKyAgKGxl dCogKChmcm9tIDApCisgICAgICAgICA7OyBUbyB1bmRlcnN0YW5kIGhvdyB0aGlzIHdvcmtzLCBj b25zaWRlciB0aGVzZSBzaW1wbGUKKyAgICAgICAgIDs7IGFzY2lpIGRpYWdyYW1zIHNob3dpbmcg aG93IHRoZSBwYXR0ZXJuICJmb28iCisgICAgICAgICA7OyBmbGV4LW1hdGNoZXMgImZhYnJvYmF6 byIsICJmYmFyYmF6b28iIGFuZAorICAgICAgICAgOzsgImJhcmZvb2JheiI6CisKKyAgICAgICAg IDs7ICAgICAgZiBhYnIgbyBiYXogbworICAgICAgICAgOzsgICAgICArIC0tLSArIC0tLSArCisK KyAgICAgICAgIDs7ICAgICAgZiBiYXJiYXogb28KKyAgICAgICAgIDs7ICAgICAgKyAtLS0tLS0g KysKKworICAgICAgICAgOzsgICAgICBiYXIgZm9vIGJhegorICAgICAgICAgOzsgICAgICAgICAg KysrCisKKyAgICAgICAgIDs7ICIrIiBpbmRpY2F0ZXMgcGFydHMgd2hlcmUgdGhlIHBhdHRlcm4g bWF0Y2hlZC4gIEEKKyAgICAgICAgIDs7ICJob2xlIiBpbiB0aGUgbWlkZGxlIG9mIHRoZSBzdHJp bmcgaXMgaW5kaWNhdGVkIGJ5CisgICAgICAgICA7OyAiLSIuICBOb3RlIHRoYXQgdGhlcmUgYXJl IG5vICJob2xlcyIgbmVhciB0aGUgZWRnZXMKKyAgICAgICAgIDs7IG9mIHRoZSBzdHJpbmcuICBU aGUgY29tcGxldGlvbiBzY29yZSBpcyBhIG51bWJlcgorICAgICAgICAgOzsgYm91bmQgYnkgKDAu LjFdIChpLmUuLCBsYXJnZXIgdGhhbiAoYnV0IG5vdCBlcXVhbAorICAgICAgICAgOzsgdG8pIHpl cm8sIGFuZCBzbWFsbGVyIG9yIGVxdWFsIHRvIG9uZSk6IHRoZSBoaWdoZXIKKyAgICAgICAgIDs7 IHRoZSBiZXR0ZXIgYW5kIG9ubHkgYSBwZXJmZWN0IG1hdGNoIChwYXR0ZXJuIGVxdWFscworICAg ICAgICAgOzsgc3RyaW5nKSB3aWxsIGhhdmUgc2NvcmUgMS4gIFRoZSBmb3JtdWxhIHRha2VzIHRo ZQorICAgICAgICAgOzsgZm9ybSBvZiBhIHF1b3RpZW50LiAgRm9yIHRoZSBudW1lcmF0b3IsIHdl IHVzZSB0aGUKKyAgICAgICAgIDs7IG51bWJlciBvZiArLCBpLmUuIHRoZSBsZW5ndGggb2YgdGhl IHBhdHRlcm4uICBGb3IKKyAgICAgICAgIDs7IHRoZSBkZW5vbWluYXRvciwgaXQgZmlyc3QgY29t cHV0ZXMKKyAgICAgICAgIDs7CisgICAgICAgICA7OyAgICAgaG9sZV9pX2NvbnRyaWIgPSAxICsg KExpLTEpXigxL3RpZ2h0bmVzcykKKyAgICAgICAgIDs7CisgICAgICAgICA7OyAsIGZvciBlYWNo IGhvbGUgImkiIG9mIGxlbmd0aCAiTGkiLCB3aGVyZSB0aWdodG5lc3MKKyAgICAgICAgIDs7IGlz IGdpdmVuIGJ5IGBmbGV4LXNjb3JlLW1hdGNoLXRpZ2h0bmVzcycuICBUaGUKKyAgICAgICAgIDs7 IGZpbmFsIHZhbHVlIGZvciB0aGUgZGVub21pbmF0b3IgaXMgdGhlbiBnaXZlbiBieToKKyAgICAg ICAgIDs7CisgICAgICAgICA7OyAgICAoU1VNX2Fjcm9zc19pKGhvbGVfaV9jb250cmliKSArIDEp ICogbGVuCisgICAgICAgICA7OworICAgICAgICAgOzsgLCB3aGVyZSAibGVuIiBpcyB0aGUgc3Ry aW5nJ3MgbGVuZ3RoLgorICAgICAgICAgKHNjb3JlLW51bWVyYXRvciAwKQorICAgICAgICAgKHNj b3JlLWRlbm9taW5hdG9yIDApCisgICAgICAgICAobGFzdC1iIDApKQorICAgICh3aGlsZSAoYW5k IG1kLWdyb3VwcyAoY2FyIG1kLWdyb3VwcykpCisgICAgICAobGV0ICgoYSBmcm9tKQorICAgICAg ICAgICAgKGIgKHBvcCBtZC1ncm91cHMpKSkKKyAgICAgICAgKHNldHEKKyAgICAgICAgIHNjb3Jl LW51bWVyYXRvciAgICgrIHNjb3JlLW51bWVyYXRvciAoLSBiIGEpKSkKKyAgICAgICAgKHVubGVz cyAob3IgKD0gYSBsYXN0LWIpCisgICAgICAgICAgICAgICAgICAgICh6ZXJvcCBsYXN0LWIpCisg ICAgICAgICAgICAgICAgICAgICg9IGEgbGVuKSkKKyAgICAgICAgICAoc2V0cQorICAgICAgICAg ICBzY29yZS1kZW5vbWluYXRvciAoKyBzY29yZS1kZW5vbWluYXRvcgorICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAxCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChleHB0 ICgtIGEgbGFzdC1iIDEpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICgv IDEuMAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmbGV4LXNjb3Jl LW1hdGNoLXRpZ2h0bmVzcykpKSkpCisgICAgICAgIChzZXRxCisgICAgICAgICBsYXN0LWIgICAg ICAgICAgICAgIGIpKQorICAgICAgKHNldHEgZnJvbSAocG9wIG1kLWdyb3VwcykpKQorICAgIDs7 IElmIGBwYXR0ZXJuJyBkb2Vzbid0IGhhdmUgYW4gZXhwbGljaXQgdHJhaWxpbmcgYW55LCB0aGUK KyAgICA7OyByZWdleCBgcmUnIHdvbid0IHByb2R1Y2UgbWF0Y2ggZGF0YSByZXByZXNlbnRpbmcg dGhlCisgICAgOzsgcmVnaW9uIGFmdGVyIHRoZSBtYXRjaC4gIFdlIG5lZWQgdG8gYWNjb3VudCB0 byBhY2NvdW50CisgICAgOzsgZm9yIHRoYXQgZXh0cmEgYml0IG9mIG1hdGNoIChidWcjNDIxNDkp LgorICAgICh1bmxlc3MgKD0gZnJvbSBtYXRjaC1lbmQpCisgICAgICAobGV0ICgoYSBmcm9tKQor ICAgICAgICAgICAgKGIgbWF0Y2gtZW5kKSkKKyAgICAgICAgKHNldHEKKyAgICAgICAgIHNjb3Jl LW51bWVyYXRvciAgICgrIHNjb3JlLW51bWVyYXRvciAoLSBiIGEpKSkKKyAgICAgICAgKHVubGVz cyAob3IgKD0gYSBsYXN0LWIpCisgICAgICAgICAgICAgICAgICAgICh6ZXJvcCBsYXN0LWIpCisg ICAgICAgICAgICAgICAgICAgICg9IGEgbGVuKSkKKyAgICAgICAgICAoc2V0cQorICAgICAgICAg ICBzY29yZS1kZW5vbWluYXRvciAoKyBzY29yZS1kZW5vbWluYXRvcgorICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAxCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChleHB0 ICgtIGEgbGFzdC1iIDEpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICgv IDEuMAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmbGV4LXNjb3Jl LW1hdGNoLXRpZ2h0bmVzcykpKSkpCisgICAgICAgIChzZXRxCisgICAgICAgICBsYXN0LWIgICAg ICAgICAgICAgIGIpKSkKKyAgICAoLyBzY29yZS1udW1lcmF0b3IgKCogbGVuICgxKyBzY29yZS1k ZW5vbWluYXRvcikpIDEuMCkpKQorCisoZGVmdmFyIGNvbXBsZXRpb24tLWZsZXgtc2NvcmUtbGFz dC1tZCBuaWwKKyAgIkhlbHBlciB2YXJpYWJsZSBmb3IgYGNvbXBsZXRpb24tLWZsZXgtc2NvcmUn LiIpCisKKyhkZWZ1biBjb21wbGV0aW9uLS1mbGV4LXNjb3JlIChzdHIgcmUgJm9wdGlvbmFsIGRv bnQtZXJyb3IpCisgICJDb21wdXRlIGZsZXggc2NvcmUgb2YgY29tcGxldGlvbiBTVFIgYmFzZWQg b24gUkUuCitJZiBET05ULUVSUk9SLCBqdXN0IHJldHVybiBuaWwgaWYgUkUgZG9lc24ndCBtYXRj aCBTVFIuIgorICAoY29uZCAoKHN0cmluZy1tYXRjaCByZSBzdHIpCisgICAgICAgICAobGV0KiAo KG1hdGNoLWVuZCAobWF0Y2gtZW5kIDApKQorICAgICAgICAgICAgICAgIChtZCAoY2RkcgorICAg ICAgICAgICAgICAgICAgICAgKHNldHEKKyAgICAgICAgICAgICAgICAgICAgICBjb21wbGV0aW9u LS1mbGV4LXNjb3JlLWxhc3QtbWQKKyAgICAgICAgICAgICAgICAgICAgICAobWF0Y2gtZGF0YSB0 IGNvbXBsZXRpb24tLWZsZXgtc2NvcmUtbGFzdC1tZCkpKSkpCisgICAgICAgICAgIChjb21wbGV0 aW9uLS1mbGV4LXNjb3JlLTEgbWQgbWF0Y2gtZW5kIChsZW5ndGggc3RyKSkpKQorICAgICAgICAo KG5vdCBkb250LWVycm9yKQorICAgICAgICAgKGVycm9yICJJbnRlcm5hbCBlcnJvcjogJXMgZG9l cyBub3QgbWF0Y2ggJXMiIHJlIHN0cikpKSkKKworKGRlZnZhciBjb21wbGV0aW9uLXBjbS0tcmVn ZXhwIG5pbAorICAiUmVnZXhwIGZyb20gUENNIHBhdHRlcm4gaW4gYGNvbXBsZXRpb24tcGNtLS1o aWxpdC1jb21tb25hbGl0eScuIikKKwogKGRlZnVuIGNvbXBsZXRpb24tcGNtLS1oaWxpdC1jb21t b25hbGl0eSAocGF0dGVybiBjb21wbGV0aW9ucykKICAgIlNob3cgd2hlcmUgYW5kIGhvdyB3ZWxs IFBBVFRFUk4gbWF0Y2hlcyBDT01QTEVUSU9OUy4KIFBBVFRFUk4sIGEgbGlzdCBvZiBzeW1ib2xz IGFuZCBzdHJpbmdzIGFzIHNlZW4KIGBjb21wbGV0aW9uLXBjbS0tbWVyZ2UtY29tcGxldGlvbnMn LCBpcyBhc3N1bWVkIHRvIG1hdGNoIGV2ZXJ5Ci1zdHJpbmcgaW4gQ09NUExFVElPTlMuICBSZXR1 cm4gYSBkZWVwIGNvcHkgb2YgQ09NUExFVElPTlMgd2hlcmUKLWVhY2ggc3RyaW5nIGlzIHByb3Bl cnRpemVkIHdpdGggYGNvbXBsZXRpb24tc2NvcmUnLCBhIG51bWJlcgotYmV0d2VlbiAwIGFuZCAx LCBhbmQgd2l0aCBmYWNlcyBgY29tcGxldGlvbnMtY29tbW9uLXBhcnQnLAotYGNvbXBsZXRpb25z LWZpcnN0LWRpZmZlcmVuY2UnIGluIHRoZSByZWxldmFudCBzZWdtZW50cy4iCitzdHJpbmcgaW4g Q09NUExFVElPTlMuCisKK0lmIGBjb21wbGV0aW9uLWxhenktaGlsaXQnIGlzIG5pbCwgcmV0dXJu IGEgZGVlcCBjb3B5IG9mCitDT01QTEVUSU9OUyB3aGVyZSBlYWNoIHN0cmluZyBpcyBwcm9wZXJ0 aXplZCB3aXRoCitgY29tcGxldGlvbi1zY29yZScsIGEgbnVtYmVyIGJldHdlZW4gMCBhbmQgMSwg YW5kIHdpdGggZmFjZXMKK2Bjb21wbGV0aW9ucy1jb21tb24tcGFydCcsIGBjb21wbGV0aW9ucy1m aXJzdC1kaWZmZXJlbmNlJyBpbiB0aGUKK3JlbGV2YW50IHNlZ21lbnRzLgorCitFbHNlLCBpZiBg Y29tcGxldGlvbi1sYXp5LWhpbGl0JyBpcyB0LCByZXR1cm4gQ09NUExFVElPTlMKK3VuY2hhbmdl ZCwgYnV0IHNldHVwIGEgc3VpdGFibGUgYGNvbXBsZXRpb24tbGF6eS1oaWxpdC1mbicgKHdoaWNo CitzZWUpIGZvciBsYXRlciBsYXp5IGhpZ2hsaWdodGluZyIKKyAgKHNldHEgY29tcGxldGlvbi1w Y20tLXJlZ2V4cCBuaWwKKyAgICAgICAgY29tcGxldGlvbi1sYXp5LWhpbGl0LWZuIG5pbCkKICAg KGNvbmQKICAgICgoYW5kIGNvbXBsZXRpb25zIChjbC1sb29wIGZvciBlIGluIHBhdHRlcm4gdGhl cmVpcyAoc3RyaW5ncCBlKSkpCiAgICAgKGxldCogKChyZSAoY29tcGxldGlvbi1wY20tLXBhdHRl cm4tPnJlZ2V4IHBhdHRlcm4gJ2dyb3VwKSkKLSAgICAgICAgICAgKHBvaW50LWlkeCAoY29tcGxl dGlvbi1wY20tLXBhdHRlcm4tcG9pbnQtaWR4IHBhdHRlcm4pKQotICAgICAgICAgICAoY2FzZS1m b2xkLXNlYXJjaCBjb21wbGV0aW9uLWlnbm9yZS1jYXNlKQotICAgICAgICAgICBsYXN0LW1kKQot ICAgICAgKG1hcGNhcgotICAgICAgIChsYW1iZGEgKHN0cikKLQkgOzsgRG9uJ3QgbW9kaWZ5IHRo ZSBzdHJpbmcgaXRzZWxmLgotICAgICAgICAgKHNldHEgc3RyIChjb3B5LXNlcXVlbmNlIHN0cikp Ci0gICAgICAgICAodW5sZXNzIChzdHJpbmctbWF0Y2ggcmUgc3RyKQotICAgICAgICAgICAoZXJy b3IgIkludGVybmFsIGVycm9yOiAlcyBkb2VzIG5vdCBtYXRjaCAlcyIgcmUgc3RyKSkKLSAgICAg ICAgIChsZXQqICgocG9zIChpZiBwb2ludC1pZHggKG1hdGNoLWJlZ2lubmluZyBwb2ludC1pZHgp IChtYXRjaC1lbmQgMCkpKQotICAgICAgICAgICAgICAgIChtYXRjaC1lbmQgKG1hdGNoLWVuZCAw KSkKLSAgICAgICAgICAgICAgICAobWQgKGNkZHIgKHNldHEgbGFzdC1tZCAobWF0Y2gtZGF0YSB0 IGxhc3QtbWQpKSkpCi0gICAgICAgICAgICAgICAgKGZyb20gMCkKLSAgICAgICAgICAgICAgICAo ZW5kIChsZW5ndGggc3RyKSkKLSAgICAgICAgICAgICAgICA7OyBUbyB1bmRlcnN0YW5kIGhvdyB0 aGlzIHdvcmtzLCBjb25zaWRlciB0aGVzZSBzaW1wbGUKLSAgICAgICAgICAgICAgICA7OyBhc2Np aSBkaWFncmFtcyBzaG93aW5nIGhvdyB0aGUgcGF0dGVybiAiZm9vIgotICAgICAgICAgICAgICAg IDs7IGZsZXgtbWF0Y2hlcyAiZmFicm9iYXpvIiwgImZiYXJiYXpvbyIgYW5kCi0gICAgICAgICAg ICAgICAgOzsgImJhcmZvb2JheiI6Ci0KLSAgICAgICAgICAgICAgICA7OyAgICAgIGYgYWJyIG8g YmF6IG8KLSAgICAgICAgICAgICAgICA7OyAgICAgICsgLS0tICsgLS0tICsKLQotICAgICAgICAg ICAgICAgIDs7ICAgICAgZiBiYXJiYXogb28KLSAgICAgICAgICAgICAgICA7OyAgICAgICsgLS0t LS0tICsrCi0KLSAgICAgICAgICAgICAgICA7OyAgICAgIGJhciBmb28gYmF6Ci0gICAgICAgICAg ICAgICAgOzsgICAgICAgICAgKysrCi0KLSAgICAgICAgICAgICAgICA7OyAiKyIgaW5kaWNhdGVz IHBhcnRzIHdoZXJlIHRoZSBwYXR0ZXJuIG1hdGNoZWQuICBBCi0gICAgICAgICAgICAgICAgOzsg ImhvbGUiIGluIHRoZSBtaWRkbGUgb2YgdGhlIHN0cmluZyBpcyBpbmRpY2F0ZWQgYnkKLSAgICAg ICAgICAgICAgICA7OyAiLSIuICBOb3RlIHRoYXQgdGhlcmUgYXJlIG5vICJob2xlcyIgbmVhciB0 aGUgZWRnZXMKLSAgICAgICAgICAgICAgICA7OyBvZiB0aGUgc3RyaW5nLiAgVGhlIGNvbXBsZXRp b24gc2NvcmUgaXMgYSBudW1iZXIKLSAgICAgICAgICAgICAgICA7OyBib3VuZCBieSAoMC4uMV0g KGkuZS4sIGxhcmdlciB0aGFuIChidXQgbm90IGVxdWFsCi0gICAgICAgICAgICAgICAgOzsgdG8p IHplcm8sIGFuZCBzbWFsbGVyIG9yIGVxdWFsIHRvIG9uZSk6IHRoZSBoaWdoZXIKLSAgICAgICAg ICAgICAgICA7OyB0aGUgYmV0dGVyIGFuZCBvbmx5IGEgcGVyZmVjdCBtYXRjaCAocGF0dGVybiBl cXVhbHMKLSAgICAgICAgICAgICAgICA7OyBzdHJpbmcpIHdpbGwgaGF2ZSBzY29yZSAxLiAgVGhl IGZvcm11bGEgdGFrZXMgdGhlCi0gICAgICAgICAgICAgICAgOzsgZm9ybSBvZiBhIHF1b3RpZW50 LiAgRm9yIHRoZSBudW1lcmF0b3IsIHdlIHVzZSB0aGUKLSAgICAgICAgICAgICAgICA7OyBudW1i ZXIgb2YgKywgaS5lLiB0aGUgbGVuZ3RoIG9mIHRoZSBwYXR0ZXJuLiAgRm9yCi0gICAgICAgICAg ICAgICAgOzsgdGhlIGRlbm9taW5hdG9yLCBpdCBmaXJzdCBjb21wdXRlcwotICAgICAgICAgICAg ICAgIDs7Ci0gICAgICAgICAgICAgICAgOzsgICAgIGhvbGVfaV9jb250cmliID0gMSArIChMaS0x KV4oMS90aWdodG5lc3MpCi0gICAgICAgICAgICAgICAgOzsKLSAgICAgICAgICAgICAgICA7OyAs IGZvciBlYWNoIGhvbGUgImkiIG9mIGxlbmd0aCAiTGkiLCB3aGVyZSB0aWdodG5lc3MKLSAgICAg ICAgICAgICAgICA7OyBpcyBnaXZlbiBieSBgZmxleC1zY29yZS1tYXRjaC10aWdodG5lc3MnLiAg VGhlCi0gICAgICAgICAgICAgICAgOzsgZmluYWwgdmFsdWUgZm9yIHRoZSBkZW5vbWluYXRvciBp cyB0aGVuIGdpdmVuIGJ5OgotICAgICAgICAgICAgICAgIDs7Ci0gICAgICAgICAgICAgICAgOzsg ICAgKFNVTV9hY3Jvc3NfaShob2xlX2lfY29udHJpYikgKyAxKSAqIGxlbgotICAgICAgICAgICAg ICAgIDs7Ci0gICAgICAgICAgICAgICAgOzsgLCB3aGVyZSAibGVuIiBpcyB0aGUgc3RyaW5nJ3Mg bGVuZ3RoLgotICAgICAgICAgICAgICAgIChzY29yZS1udW1lcmF0b3IgMCkKLSAgICAgICAgICAg ICAgICAoc2NvcmUtZGVub21pbmF0b3IgMCkKLSAgICAgICAgICAgICAgICAobGFzdC1iIDApCi0g ICAgICAgICAgICAgICAgKHVwZGF0ZS1zY29yZS1hbmQtZmFjZQotICAgICAgICAgICAgICAgICAo bGFtYmRhIChhIGIpCi0gICAgICAgICAgICAgICAgICAgIlVwZGF0ZSBzY29yZSBhbmQgZmFjZSBn aXZlbiBtYXRjaCByYW5nZSAoQSBCKS4iCi0gICAgICAgICAgICAgICAgICAgKGFkZC1mYWNlLXRl eHQtcHJvcGVydHkgYSBiCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgJ2NvbXBsZXRpb25zLWNvbW1vbi1wYXJ0Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgbmlsIHN0cikKLSAgICAgICAgICAgICAgICAgICAoc2V0cQotICAgICAg ICAgICAgICAgICAgICBzY29yZS1udW1lcmF0b3IgICAoKyBzY29yZS1udW1lcmF0b3IgKC0gYiBh KSkpCi0gICAgICAgICAgICAgICAgICAgKHVubGVzcyAob3IgKD0gYSBsYXN0LWIpCi0gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgKHplcm9wIGxhc3QtYikKLSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAoPSBhIChsZW5ndGggc3RyKSkpCi0gICAgICAgICAgICAgICAgICAgICAo c2V0cQotICAgICAgICAgICAgICAgICAgICAgIHNjb3JlLWRlbm9taW5hdG9yICgrIHNjb3JlLWRl bm9taW5hdG9yCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMQot ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChleHB0ICgtIGEgbGFz dC1iIDEpCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg KC8gMS4wCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgZmxleC1zY29yZS1tYXRjaC10aWdodG5lc3MpKSkpKQotICAgICAgICAgICAgICAgICAgIChz ZXRxCi0gICAgICAgICAgICAgICAgICAgIGxhc3QtYiAgICAgICAgICAgICAgYikpKSkKLSAgICAg ICAgICAgKHdoaWxlIG1kCi0gICAgICAgICAgICAgKGZ1bmNhbGwgdXBkYXRlLXNjb3JlLWFuZC1m YWNlIGZyb20gKHBvcCBtZCkpCi0gICAgICAgICAgICAgKHNldHEgZnJvbSAocG9wIG1kKSkpCi0g ICAgICAgICAgIDs7IElmIGBwYXR0ZXJuJyBkb2Vzbid0IGhhdmUgYW4gZXhwbGljaXQgdHJhaWxp bmcgYW55LCB0aGUKLSAgICAgICAgICAgOzsgcmVnZXggYHJlJyB3b24ndCBwcm9kdWNlIG1hdGNo IGRhdGEgcmVwcmVzZW50aW5nIHRoZQotICAgICAgICAgICA7OyByZWdpb24gYWZ0ZXIgdGhlIG1h dGNoLiAgV2UgbmVlZCB0byBhY2NvdW50IHRvIGFjY291bnQKLSAgICAgICAgICAgOzsgZm9yIHRo YXQgZXh0cmEgYml0IG9mIG1hdGNoIChidWcjNDIxNDkpLgotICAgICAgICAgICAodW5sZXNzICg9 IGZyb20gbWF0Y2gtZW5kKQotICAgICAgICAgICAgIChmdW5jYWxsIHVwZGF0ZS1zY29yZS1hbmQt ZmFjZSBmcm9tIG1hdGNoLWVuZCkpCi0gICAgICAgICAgIChpZiAoPiAobGVuZ3RoIHN0cikgcG9z KQotICAgICAgICAgICAgICAgKGFkZC1mYWNlLXRleHQtcHJvcGVydHkKLSAgICAgICAgICAgICAg ICBwb3MgKDErIHBvcykKLSAgICAgICAgICAgICAgICAnY29tcGxldGlvbnMtZmlyc3QtZGlmZmVy ZW5jZQotICAgICAgICAgICAgICAgIG5pbCBzdHIpKQotICAgICAgICAgICAodW5sZXNzICh6ZXJv cCAobGVuZ3RoIHN0cikpCi0gICAgICAgICAgICAgKHB1dC10ZXh0LXByb3BlcnR5Ci0gICAgICAg ICAgICAgIDAgMSAnY29tcGxldGlvbi1zY29yZQotICAgICAgICAgICAgICAoLyBzY29yZS1udW1l cmF0b3IgKCogZW5kICgxKyBzY29yZS1kZW5vbWluYXRvcikpIDEuMCkgc3RyKSkpCi0gICAgICAg ICBzdHIpCi0gICAgICAgY29tcGxldGlvbnMpKSkKKyAgICAgICAgICAgKHNjb3JlIChsYW1iZGEg KHN0cikKKyAgICAgICAgICAgICAgICAgICAgKHB1dC10ZXh0LXByb3BlcnR5IDAgMSAnY29tcGxl dGlvbi1zY29yZQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGNvbXBs ZXRpb24tLWZsZXgtc2NvcmUgc3RyIHJlKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgc3RyKSkpKQorICAgICAgKGNvbmQgKGNvbXBsZXRpb24tbGF6eS1oaWxpdAorICAg ICAgICAgICAgIChzZXRxIGNvbXBsZXRpb24tbGF6eS1oaWxpdC1mbgorICAgICAgICAgICAgICAg ICAgIChsYW1iZGEgKHN0cikgKGNvbXBsZXRpb24tLWhpbGl0LWZyb20tcmUgc3RyIHJlKSkKKyAg ICAgICAgICAgICAgICAgICBjb21wbGV0aW9uLXBjbS0tcmVnZXhwIHJlKQorICAgICAgICAgICAg IGNvbXBsZXRpb25zKQorICAgICAgICAgICAgKHQKKyAgICAgICAgICAgICAobWFwY2FyCisgICAg ICAgICAgICAgIChsYW1iZGEgKHN0cikKKyAgICAgICAgICAgICAgICAoc2V0cSBzdHIgKGNvcHkt c2VxdWVuY2Ugc3RyKSkKKyAgICAgICAgICAgICAgICAoZnVuY2FsbCBzY29yZSBzdHIpCisgICAg ICAgICAgICAgICAgKGNvbXBsZXRpb24tLWhpbGl0LWZyb20tcmUgc3RyIHJlKQorICAgICAgICAg ICAgICAgIHN0cikKKyAgICAgICAgICAgICAgY29tcGxldGlvbnMpKSkpKQogICAgKHQgY29tcGxl dGlvbnMpKSkKIAogKGRlZnVuIGNvbXBsZXRpb24tcGNtLS1maW5kLWFsbC1jb21wbGV0aW9ucyAo c3RyaW5nIHRhYmxlIHByZWQgcG9pbnQKQEAgLTQyMDEsMTUgKzQyOTgsNDQgQEAgY29tcGxldGlv bi0tZmxleC1hZGp1c3QtbWV0YWRhdGEKICAgICAgICAgKGV4aXN0aW5nLWNzZgogICAgICAgICAg KGNvbXBsZXRpb24tbWV0YWRhdGEtZ2V0IG1ldGFkYXRhICdjeWNsZS1zb3J0LWZ1bmN0aW9uKSkp CiAgICAgKGNsLWZsZXQKLSAgICAgICAgKChjb21wb3NlLWZsZXgtc29ydC1mbgotICAgICAgICAg IChleGlzdGluZy1zb3J0LWZuKSA7IHdpc2ggYGNsLWZsZXQnIGhhZCBwcm9wZXIgaW5kZW50YXRp b24uLi4KLSAgICAgICAgICAobGFtYmRhIChjb21wbGV0aW9ucykKLSAgICAgICAgICAgIChzb3J0 Ci0gICAgICAgICAgICAgKGZ1bmNhbGwgZXhpc3Rpbmctc29ydC1mbiBjb21wbGV0aW9ucykKLSAg ICAgICAgICAgICAobGFtYmRhIChjMSBjMikKLSAgICAgICAgICAgICAgIChsZXQgKChzMSAoZ2V0 LXRleHQtcHJvcGVydHkgMCAnY29tcGxldGlvbi1zY29yZSBjMSkpCi0gICAgICAgICAgICAgICAg ICAgICAoczIgKGdldC10ZXh0LXByb3BlcnR5IDAgJ2NvbXBsZXRpb24tc2NvcmUgYzIpKSkKLSAg ICAgICAgICAgICAgICAgKD4gKG9yIHMxIDApIChvciBzMiAwKSkpKSkpKSkKKyAgICAgICAgKChj b21wb3NlLWZsZXgtc29ydC1mbiAoZXhpc3Rpbmctc29ydC1mbikKKyAgICAgICAgICAgKGxhbWJk YSAoY29tcGxldGlvbnMpCisgICAgICAgICAgICAgKGxldCAoKHByZS1zb3J0ZWQgKGZ1bmNhbGwg ZXhpc3Rpbmctc29ydC1mbiBjb21wbGV0aW9ucykpKQorICAgICAgICAgICAgICAgKGNvbmQgKDs7 IFRoZXJlJ3Mgbm8gdXNlZnVsIHNjb3JpbmcgdG8gYXBwbHksIHNpbmNlIHRoZQorICAgICAgICAg ICAgICAgICAgICAgIDs7IHBhdHRlcm4gaXMgZW1wdHkKKyAgICAgICAgICAgICAgICAgICAgICAo bnVsbCBjb21wbGV0aW9uLXBjbS0tcmVnZXhwKQorICAgICAgICAgICAgICAgICAgICAgIHByZS1z b3J0ZWQpCisgICAgICAgICAgICAgICAgICAgICAoY29tcGxldGlvbi1sYXp5LWhpbGl0CisgICAg ICAgICAgICAgICAgICAgICAgOzsgTGF6eSBoaWdobGlnaHQgaGFzIGJlZW4gcmVxdWVzdGVkLCBz byBkbyB0aGUKKyAgICAgICAgICAgICAgICAgICAgICA7OyBzY29yaW5nIGFuZCBzb3J0aW5nIG5v dy4KKyAgICAgICAgICAgICAgICAgICAgICAobGV0KiAoKHNvcnRlZCAoc29ydAorICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAobWFwY2FyCisgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAobGFtYmRhIChzdHIpCisgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIChjb25zCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAoLSAoY29tcGxldGlvbi0tZmxleC1zY29yZQorICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIChvciAoZ2V0LXRleHQtcHJvcGVydHkKKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAgJ2NvbXBsZXRp b24tLXVucXVvdGVkIHN0cikKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgc3RyKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGNvbXBsZXRpb24tcGNtLS1yZWdleHApKQorICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgc3RyKSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHByZS1zb3J0ZWQpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICMnY2FyLWxlc3MtdGhhbi1jYXIpKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoY2Vs bCBzb3J0ZWQpKQorICAgICAgICAgICAgICAgICAgICAgICAgOzsgUmV1c2UgdGhlIGxpc3QKKyAg ICAgICAgICAgICAgICAgICAgICAgICh3aGlsZSBjZWxsCisgICAgICAgICAgICAgICAgICAgICAg ICAgIChzZXRjYXIgY2VsbCAoY2RhciBjZWxsKSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAg KHBvcCBjZWxsKSkKKyAgICAgICAgICAgICAgICAgICAgICAgIHNvcnRlZCkpCisgICAgICAgICAg ICAgICAgICAgICAodAorICAgICAgICAgICAgICAgICAgICAgIDs7IExhenkgaGlnaGxpZ2h0IG5v dCByZXF1ZXN0ZWQsIHNvIHN0cmluZ3MgYXJlCisgICAgICAgICAgICAgICAgICAgICAgOzsgYXNz dW1lZCB0byBhbHJlYWR5IGNvbnRhaW4gYGNvbXBsZXRpb24tc2NvcmUnCisgICAgICAgICAgICAg ICAgICAgICAgOzsgKGFuZCBoaWdobGlnaHRpbmcpIGFuZCB3ZSBjYW4gZnJlZWx5IGRlc3Ryb3kK KyAgICAgICAgICAgICAgICAgICAgICA7OyBsaXN0LgorICAgICAgICAgICAgICAgICAgICAgIChz b3J0CisgICAgICAgICAgICAgICAgICAgICAgIHByZS1zb3J0ZWQKKyAgICAgICAgICAgICAgICAg ICAgICAgKGxhbWJkYSAoYzEgYzIpCisgICAgICAgICAgICAgICAgICAgICAgICAgKD4gKG9yIChn ZXQtdGV4dC1wcm9wZXJ0eSAwICdjb21wbGV0aW9uLXNjb3JlIGMxKSAwKQorICAgICAgICAgICAg ICAgICAgICAgICAgICAgIChvciAoZ2V0LXRleHQtcHJvcGVydHkgMCAnY29tcGxldGlvbi1zY29y ZSBjMikgMCkpKSkpKSkpKSkKICAgICAgIGAobWV0YWRhdGEKICAgICAgICAgLEAoYW5kIGZsZXgt aXMtZmlsdGVyaW5nLXAKICAgICAgICAgICAgICAgIGAoKGRpc3BsYXktc29ydC1mdW5jdGlvbgo= --00000000000084ce9b06091bb41d--
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 31 Oct 2023 20:52:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 31 16:52:56 2023 Received: from localhost ([127.0.0.1]:49380 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qxvjL-0004hI-W3 for submit <at> debbugs.gnu.org; Tue, 31 Oct 2023 16:52:56 -0400 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:44727) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1qxvjI-0004h2-8d for 47711 <at> debbugs.gnu.org; Tue, 31 Oct 2023 16:52:53 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id EF41032009D2; Tue, 31 Oct 2023 16:52:10 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 31 Oct 2023 16:52:11 -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= 1698785530; x=1698871930; bh=UmS9zeCKzfDDRZoWryamZWOz6AfHjirJySz LTlRqmKc=; b=HXArrWOg8Xq2fOUDtQHSumUyX6f1tX/LAFfpQ0ES4lwhWb3i1yy aZVqlmF4VstpkjSZlNOCqOuvAkph5Oa1IQRpRD8ehXiy25KS+WMiVAYoO+0vBGup 2rI5V+1pin2eSr0JK7rj5rVhg0WRRa2xX4lZpKigEkVnC9sYAYkdQlj8RPo0NZpx SH3xmt8nybriJSg1i64YMCm0vkYerHHel9K9rwSshbksff5/acbFFiiSFWt7N3Ul /Wb8tPqGsfz7VfE1KX1AteABFWZvuFFW79C+Y5FGpJNdhzNl5DvtIPJAbOIUu+Kc FLUQp1BICycbDUqqCfnPJNJ1T7Dmj5sp4CQ== 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= 1698785530; x=1698871930; bh=UmS9zeCKzfDDRZoWryamZWOz6AfHjirJySz LTlRqmKc=; b=PlxSH5AcQYogzy8SKeBBAth/4Lt2Z3M5Trd1AjqN94+Sloylf1p aLCbYVYvlAEqHadGyUyF8ZMSWweXXW3MljxOX0TaJfN0jf1QKA3ntUozm0Q6WYOB C5Y6eJq5F/L3dvQK/6jpRO/syKU+7dlQjTYQC0pa5I+yDx1vFfArl/95sPb69cqN GEgV2zx8Vf1ctSPgQPF7TlYIJ/yVsmjIIjxS6hmY+U9gxW10MOC/uYVpK1Bp9pta IQq6QZoatvqoMe06BHmO5NxfAmTW6HON2TT0gcBfVbw+1XWdq/6zDi6wD01aAm7a EoomyE4ggoU2psXmzT73wzgQUaXZGUPh3yQ== X-ME-Sender: <xms:-mhBZU9lKuXGEaAAxmGYRxHYtFgxXfM07DGRs8i3WnhmXDFM673cUQ> <xme:-mhBZcs43Nj-x21jOxq3B1mjW7DxjlFFVgTbIaB3wkW2OwGUJPNaf8NRyW7BRzqgx 6VvVqP0ysKOFJk2VGc> X-ME-Received: <xmr:-mhBZaDoTo2rW-sLF7OVDIQvREQ7Ugeul3AeDVkh42Or3nvW-8f6WPI3iWjHVG4> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddtvddgudegtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpefhffehleejffegffeugefhkeektdffgfehjedvgeejtedtudehueffgffg feejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: <xmx:-mhBZUc4_IdklpFBgSQqHRneNR4DTnGtgIL1u_tKHnSyk4NAFp3-dw> <xmx:-mhBZZOEqzDP1TyGfThcBub5x8J72cUPvkqlSOQLs_Pjhq4OHbVHaw> <xmx:-mhBZekgjgQf-H0ssWCdktjOCg2lWqF4LoGRTzYi-L7jdpEtKpnZ3w> <xmx:-mhBZapaGDsrCOZfORonTi6FngDxU4nKtv1ATiNEFB4VnnASByCCZA> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 31 Oct 2023 16:52:08 -0400 (EDT) Message-ID: <5181f95e-61e7-c8c4-6389-44ee57e0c749@HIDDEN> Date: Tue, 31 Oct 2023 22:52:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <877cn8asud.fsf@HIDDEN> <c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN> <8734xtauqj.fsf@HIDDEN> <eeabbe1f-7b2d-ade5-949c-05aea0ba85a9@HIDDEN> <CALDnm51kS6p9V7z1AT=+TFp6kM5xw5Xv_oWZFSqAuEKx=-=a2A@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <CALDnm51kS6p9V7z1AT=+TFp6kM5xw5Xv_oWZFSqAuEKx=-=a2A@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.2 (---) On 31/10/2023 12:55, João Távora wrote: >> Which keys are those? I only know about one key - 'completion-score'. > > Yes, that's the one. I suppose adding this key to the property lists of > large number of strings, which is only done once, is what's causing > the anomaly. Ah, I didn't realize that the text property/value pairs were stored as plists internally as well. And that also triggers consing. >>>> But if course it would be nice to avoid the wart, so if you have any >>>> better ideas, they are welcome. >>> >>> I'm not saying it would necessarily spread even further, but if you want >>> to do scoring "just in time" like I suggested -- presumably to >>> completely avoid propertizing strings -- that particular wart spreads a >>> little more and thus becomes something that is slightly harder to remove >>> later on. >> >> Could you describe the other places you think it might spread to? Other >> completion styles like Orderless? > > Maybe, I don't know. But here I just meant that to do that idea it spreads > only one further degree. I'm not saying it would necessarily spread even > further. It seems like the only code that would be concerned with it are completion styles that also do sorting, or completion tables that would do similar things to this "with quoting" business. But I'm not aware of any other examples of the latter aside from what is inside Emacs itself. >> Anyway, have you looked into what it would take to solve it? > > No, naively, I just think it's a similar situation of display and business > logic being mixed up. Presumably the quoted stuff is just for insertion > (and display?), and the unquoted stuff is what patterns/scoring should > operate on. Apparently it's good for insertion, but according to that comment inside the function, the unquoted stuff might actually be better for display. I'm not 100% clear which of the versions is better for scoring/highlighting, but apparently the unquoted one. > But, IMO, there's no need to tackle it right now. > > If the thing holding you back from the lazy-hilit-2023-v4.patch is the > completion-score propertization, I can move it to the sorting step > in a future v5 and add spread the completion--unquoted thing a little > bit more. I think that's the main blocker, yes.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 31 Oct 2023 10:56:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 31 06:56:37 2023 Received: from localhost ([127.0.0.1]:47515 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qxmQH-0005rq-7I for submit <at> debbugs.gnu.org; Tue, 31 Oct 2023 06:56:37 -0400 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]:48327) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1qxmQG-0005rc-5G for 47711 <at> debbugs.gnu.org; Tue, 31 Oct 2023 06:56:36 -0400 Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-507a62d4788so8403840e87.0 for <47711 <at> debbugs.gnu.org>; Tue, 31 Oct 2023 03:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698749756; x=1699354556; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=kzwa/Xk1YNxVNUHSZKfMTsmFgqRUYeZJ1ee4pc/pL6k=; b=L8lfuzteBPjYWJDwlHHtVnUCpXKaZplsrL6GkqCmb5UxC1qsjdIXjPhOOyKtFvo4S1 bJP3bSGhqKEDnRyk5GSZI0LbBJ46PvAQirn/RQtgjm8jHjgzTuyKf1pxSW4iBGWMlDIt T0yXbbRR7g03d3n2nVkDmW0dmJPEw56Ty/EMSGQ+tHcEbsvRMwmSeIdL0cUPQZ+WFjgV w2+w8WgH2y8a5doXfd2R3xfyFhaQNpuZvlcokLaqIif3DwFLq5AOSlh5Zhu8EoYoHPTj b61PVZdqO9BbTeQ9lTaA7+mpSE7GL+nbyUCT5koiA97vjH4HTvRYGsYFzsLWXiJs4JZI 3GmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698749756; x=1699354556; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kzwa/Xk1YNxVNUHSZKfMTsmFgqRUYeZJ1ee4pc/pL6k=; b=vbwS3Sytb9bzwbGzQ6fukeYgrsYNEgZFUNa/JC780vBTuZtgBsGP0eih5YuaS7FrMU MoXNiq6yFThZ8KQj+PDSoYSBZwHAnj5Xkc3R2eix/gCVIbQy4iW3m2hVfC6ROqBrcaYZ H6D4wQeDy0aphUue3LNfUNVc6PaXzoQc4xdRb8rRf9A8PKruKX5I39qZm/G4EhgYstXU O6jFEzHiTvQB4ZBFbMtbSf/+DJl5ozq9w7r/bxU/NzeFcPDIxh8QNkOX1hIb63s9Xx+I QPG1l8qweVE3Enbrv/V04m+8hdGEvU/xpM4Y0MF2KLZ1nY45gV3GH/OdQt8LjDK1z+uC jaVA== X-Gm-Message-State: AOJu0Yx64KFlbJ5tEJz2v+JZBsbpIQT5YwRCXteuTLlTkvqz/g3pHj8a GT+gKTQteWNHIghlAQ8cFW/QMN5Q1RQMitnfmkU= X-Google-Smtp-Source: AGHT+IGziVd13EFIU13Wszb9q5Mn4TsIBJ7W08ntxfbUMFXMLOgYKSfjG5irA3DKUSJRmA+LvHp/FuEJmk4t/KJ/TCw= X-Received: by 2002:a05:6512:3d0b:b0:500:9f7b:e6a4 with SMTP id d11-20020a0565123d0b00b005009f7be6a4mr11216049lfv.32.1698749756209; Tue, 31 Oct 2023 03:55:56 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <877cn8asud.fsf@HIDDEN> <c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN> <8734xtauqj.fsf@HIDDEN> <eeabbe1f-7b2d-ade5-949c-05aea0ba85a9@HIDDEN> In-Reply-To: <eeabbe1f-7b2d-ade5-949c-05aea0ba85a9@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Tue, 31 Oct 2023 10:55:44 +0000 Message-ID: <CALDnm51kS6p9V7z1AT=+TFp6kM5xw5Xv_oWZFSqAuEKx=-=a2A@HIDDEN> Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Dmitry Gutov <dmitry@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Tue, Oct 31, 2023 at 3:20=E2=80=AFAM Dmitry Gutov <dmitry@HIDDEN> wro= te: > > Hi Joao, > > On 30/10/2023 01:12, Jo=C3=A3o T=C3=A1vora wrote: > > >> Thanks. My measurements are similar, except the difference switch the > >> other way a little bit. It might depend on the particulars of the > >> individual machine anyway. > > > > Yes, it could, but I've reproduced this in different hardware. > > > > Check that you're taking enough samples, I take about 15-20 samples. > > Maybe the lazy-hilit patch pays a an extra cost upfront for the very > > first C-h v or completing-read, to create the properties keys on the > > strings, which are then reused. > > I actually do see that. At first I didn't pay much attention to such > outliers. They usually look like the second measurement here: > > Elapsed time: 0.541624s (0.164396s in 5 GCs) > Elapsed time: 0.861175s (0.415142s in 10 GCs) > Elapsed time: 0.486012s (0.057915s in 1 GCs) > Elapsed time: 0.505339s (0.055759s in 1 GCs) > Elapsed time: 0.481024s (0.057757s in 1 GCs) > Elapsed time: 0.471350s (0.056383s in 1 GCs) > Elapsed time: 0.495125s (0.056129s in 1 GCs) > Elapsed time: 0.513310s (0.058437s in 1 GCs) > Elapsed time: 0.491978s (0.057144s in 1 GCs) > > Which keys are those? I only know about one key - 'completion-score'. Yes, that's the one. I suppose adding this key to the property lists of large number of strings, which is only done once, is what's causing the anomaly. > > > This cost is ammortized very quickly, > > of course, but if you're taking the measurement immediately after Emacs > > -Q and with few samples, it skews the numbers. > > I always took around 16 samples, and now made sure to take exactly that > number, starting with "y" and then "yo", "y", etc. Although the timing > for the empty input is usually included (but it doesn't look too > different from the rest). > > Anyway, I retook the numbers a couple of times. One of the patches (the > same one) still looks a little faster, but the fluctuations between runs > are large enough to avoid making any big conclusions: As did I, and I get the same results I posted :-/ > > I think further optimization would be localized to the scoring function > > itself, not to the place where it is performed. > > Most likely, yes. It seems to be the most expensive part. But it still > seems easier to measure/tweak when it happens during a separate step, > rather than mixed in with the rest of completion-all-completions' busines= s. > > >> But if course it would be nice to avoid the wart, so if you have any > >> better ideas, they are welcome. > > > > I'm not saying it would necessarily spread even further, but if you wan= t > > to do scoring "just in time" like I suggested -- presumably to > > completely avoid propertizing strings -- that particular wart spreads a > > little more and thus becomes something that is slightly harder to remov= e > > later on. > > Could you describe the other places you think it might spread to? Other > completion styles like Orderless? Maybe, I don't know. But here I just meant that to do that idea it spreads only one further degree. I'm not saying it would necessarily spread even further. > > As long as there's only one place producing this property (as opposed to > consuming it), it seems straightforward enough to remove anyway. > > >> So far you advocated toward avoiding breaking changes while > >> implementing the present performance improvement. > > > > Both patches do that, so what I've been arguing for is simplicity and > > coherence. I don't think completion-sorted-completions and the > > complexity it brings to minibuffer.el is a step in the rigth direction, > > and the performance benefits it does undeniably bring can be achieved > > with less drastic means. > > What I meant is, solving the quote-unquote conundrum might require a > larger breaking change than the one that you wanted for this discussion. A larger change sure, not sure if "breaking" though. > Anyway, have you looked into what it would take to solve it? No, naively, I just think it's a similar situation of display and business logic being mixed up. Presumably the quoted stuff is just for insertion (and display?), and the unquoted stuff is what patterns/scoring should operate on. But, IMO, there's no need to tackle it right now. If the thing holding you back from the lazy-hilit-2023-v4.patch is the completion-score propertization, I can move it to the sorting step in a future v5 and add spread the completion--unquoted thing a little bit more. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 31 Oct 2023 03:20:50 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 30 23:20:50 2023 Received: from localhost ([127.0.0.1]:47285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qxfJC-0002ID-2L for submit <at> debbugs.gnu.org; Mon, 30 Oct 2023 23:20:50 -0400 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:54831) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1qxfJ9-0002Hy-Ss for 47711 <at> debbugs.gnu.org; Mon, 30 Oct 2023 23:20:48 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 1AD1F32009DC; Mon, 30 Oct 2023 23:20:08 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Mon, 30 Oct 2023 23:20:08 -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= 1698722407; x=1698808807; bh=iZ3Ddus2JGcBW/zvgkI4G6xCAqeLIsQt4Ej fnTeCALk=; b=l0J1UwArIqeOSt47wz9tUQwQDiTcfzfZd0V562c9H+Le7agQJ1v 53f2wJwfLuuQ/GetPzgbrViRrGKezfTmZg7UYxIEnkUX0p3d3L8oL6o0SlP2l/jm NfwHljz7OphLmteohymmxUc50z1GBns+GfHGs+5fotJn2EPtOmRSt7pNmQobn9Xq 0R/w/AyusrRySo52xK2mExX5rvbp07we1eC+uxdXUtne+iohuSo0jAJGNiA/veL6 WH99ZdQ9QsB/2u0jcRbKiFovrEJ8MQGBrE1ltFGjBWosayz1mAIGFhCjRJ8fJ3XV 6GVEMJ72JPJXJiaC40CBSXSNuixEHaRJ7ZA== 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= 1698722407; x=1698808807; bh=iZ3Ddus2JGcBW/zvgkI4G6xCAqeLIsQt4Ej fnTeCALk=; b=jUsU+avuqHZo7vrQbPWsgXBdL3D9aC+mdQcbRYgxE6u4UPIW/8d 7YDLZ0qhQS9522SqcfgzHHlb+uKlcM4wuWFZWKLjmD0JelhVcnLyuURSPNGmIPNi bWZGyzSowoQ+AKajMSDVyfibMguxReHaxKoodjKoHEPVzaCGHqYoYyc4Xl2yd5T8 BtMjkUck5rjDjc8PlT3ALAuP9ai59qpnMkoWA4c0x3jdSCwEkE9RCGpVON1BCkDg mZ2VfDNHseAoPbKUxhDyGspadiSyjcEH9gljw3eqN3ucNBzfXfFKNJvq7FwEfYkt meARotjXWnVe+Gdk1uiiFPQzI/ao9LuefVg== X-ME-Sender: <xms:Z3JAZYlU0x0XpToshJOR1wh8BNgTW5J7HDlYupG0taqsRCy1fonI9w> <xme:Z3JAZX0wMJWUum-gzyc_q-f0rIw31b7at7ELhX6K5ffqkLwUbs8eQsehZFUL_EMPA F4Fzug2n_X_6Q8yRuA> X-ME-Received: <xmr:Z3JAZWpLseEx-UtZSdee1kS2JgcOVU1SZrZy0untbS_bUle_VE6IPIebmO-vln8> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddtuddgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhephfffheeljeffgeffueeghfekkedtfffgheejvdegjeettdduheeufffggfef jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: <xmx:Z3JAZUnE2Rg9lvPdood_JrAGqsOZJjKiaSNdWGuQbSoWMyMIxPpdKw> <xmx:Z3JAZW3tobgkdWW6UE8yZnszC2J7ud3xvHQ8JHgTA2TcAVciLkEXVQ> <xmx:Z3JAZbuhpP-R0dbx3Bp1yH-bHlRS7jBOXKItXk898aw5QUN5vZpj1g> <xmx:Z3JAZbxjW59Vul79fxJiTk5KzajACM0zBN6eul27fF-63ruDRbzMnw> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 30 Oct 2023 23:20:06 -0400 (EDT) Message-ID: <eeabbe1f-7b2d-ade5-949c-05aea0ba85a9@HIDDEN> Date: Tue, 31 Oct 2023 05:20:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <877cn8asud.fsf@HIDDEN> <c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN> <8734xtauqj.fsf@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <8734xtauqj.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.2 (---) Hi Joao, On 30/10/2023 01:12, João Távora wrote: >> Thanks. My measurements are similar, except the difference switch the >> other way a little bit. It might depend on the particulars of the >> individual machine anyway. > > Yes, it could, but I've reproduced this in different hardware. > > Check that you're taking enough samples, I take about 15-20 samples. > Maybe the lazy-hilit patch pays a an extra cost upfront for the very > first C-h v or completing-read, to create the properties keys on the > strings, which are then reused. I actually do see that. At first I didn't pay much attention to such outliers. They usually look like the second measurement here: Elapsed time: 0.541624s (0.164396s in 5 GCs) Elapsed time: 0.861175s (0.415142s in 10 GCs) Elapsed time: 0.486012s (0.057915s in 1 GCs) Elapsed time: 0.505339s (0.055759s in 1 GCs) Elapsed time: 0.481024s (0.057757s in 1 GCs) Elapsed time: 0.471350s (0.056383s in 1 GCs) Elapsed time: 0.495125s (0.056129s in 1 GCs) Elapsed time: 0.513310s (0.058437s in 1 GCs) Elapsed time: 0.491978s (0.057144s in 1 GCs) Which keys are those? I only know about one key - 'completion-score'. > This cost is ammortized very quickly, > of course, but if you're taking the measurement immediately after Emacs > -Q and with few samples, it skews the numbers. I always took around 16 samples, and now made sure to take exactly that number, starting with "y" and then "yo", "y", etc. Although the timing for the empty input is usually included (but it doesn't look too different from the rest). Anyway, I retook the numbers a couple of times. One of the patches (the same one) still looks a little faster, but the fluctuations between runs are large enough to avoid making any big conclusions: d+d 300000 completing-read 0.504 C-h v 0.630 lazy-hilit-2023-v4 300000 completing-read 0.517 C-h v 0.661 d+d again 300000 completing-read 0.486 C-h v 0.587 lazy-hilit-2023-v4 again 300000 completing-read 0.519 C-h v 0.651 And to double-check, these are comparison between 0001-Add-new-completion-filter-completions-API-and-deferr-v3.diff and lazy-hilit-2023-v4.diff. 16 samples every time. And I think I dropped the run with the "spike" in all or most of the above. The first of the patches doesn't seem to cause it, though. >> All averages made using 'M-x calc-grab-region' followed by 'u M'. > > Wow, thanks for this tip. I wondered if there was an easier way than > M-x cua-rectangle-mark-mode + hand rolled avg function. No problem! I lost your snippet for avg, so had to google. :-/ rectangle-mark-mode (C-x SPC) is still part of the recipe, though. >>>> 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. >>> If we really wanted to, we could also adopt the non-propertizing >>> approach in my lazy-hilit patch, by calculating the score "just in >>> time", much like Daniel's patch does it. But it should be clear that >>> what we save in allocation in completion-pcm--hilit-commonality, we'll >>> pay for in the same amount in consing later. So no performance benefit. >> >> Not for performance, no. Although the way it separates the sorting >> into its own phase makes it easier to reason about that particular >> cost. And for 300000 symbols, scoring and sorting really take the most >> time, e.g. about 2/3rds. Which might help with optimizing it further >> down in the future, somehow, > > I think further optimization would be localized to the scoring function > itself, not to the place where it is performed. Most likely, yes. It seems to be the most expensive part. But it still seems easier to measure/tweak when it happens during a separate step, rather than mixed in with the rest of completion-all-completions' business. >> But if course it would be nice to avoid the wart, so if you have any >> better ideas, they are welcome. > > I'm not saying it would necessarily spread even further, but if you want > to do scoring "just in time" like I suggested -- presumably to > completely avoid propertizing strings -- that particular wart spreads a > little more and thus becomes something that is slightly harder to remove > later on. Could you describe the other places you think it might spread to? Other completion styles like Orderless? As long as there's only one place producing this property (as opposed to consuming it), it seems straightforward enough to remove anyway. >> So far you advocated toward avoiding breaking changes while >> implementing the present performance improvement. > > Both patches do that, so what I've been arguing for is simplicity and > coherence. I don't think completion-sorted-completions and the > complexity it brings to minibuffer.el is a step in the rigth direction, > and the performance benefits it does undeniably bring can be achieved > with less drastic means. What I meant is, solving the quote-unquote conundrum might require a larger breaking change than the one that you wanted for this discussion. Anyway, have you looked into what it would take to solve it? Such text propertization might actually work as a cheap replacement to returning "a function to ... requote them". If both highlighting and scoring functions work fine on the "unquoted" strings, then we would only need to make sure the "quoted" is used when the completion is inserted. Could we make a rule that every table-with-quoting would have to call a particular exit-function? Perhaps before the existing exit-function. That might solve a bunch of things, though I don't see a robust way to enforce this practice, given that completion-table-with-quoting works on the level of completion tables, whereas :exit-function is only specified in the capf tuple.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 29 Oct 2023 23:10:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 29 19:10:22 2023 Received: from localhost ([127.0.0.1]:43996 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qxEvF-0007K1-VP for submit <at> debbugs.gnu.org; Sun, 29 Oct 2023 19:10:22 -0400 Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]:53304) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1qxEvC-0007Jl-Dm for 47711 <at> debbugs.gnu.org; Sun, 29 Oct 2023 19:10:20 -0400 Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-31fa15f4cc6so2793657f8f.2 for <47711 <at> debbugs.gnu.org>; Sun, 29 Oct 2023 16:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698620979; x=1699225779; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=6aMavgiqBpr9zBflN1DM1z02n5HlJVd9IxOJhgBeqP0=; b=l6FYtU7z2OmGrHC5vbi/OKNH0EbIRqIiUVIiQ28fh4u8XC0lWmzP7yfvhKvKlaNpux IWa1DswhpV5egyTmqgC0YMInAaQPMhU2For4rTBqjxTWO2WtUFlapps2wARooRR8Ijzg lLqdICzE0pyz9S5ADlf29Hlz8LEvaYtLe7aHssTJQFg6Er7Iv8ELX6jw6M+L2UIcMODC 2wivmUvB+dVdVUW7Wp1YWsjJ/V0SO0Rpr1MSVBNglmm5dClpu9u204z/tY01SKW8DmGW KQaN7mqGFNX0XtT/PPUU6vkFIGgle+Gj4IN6AfpYVKZWPXuD++toK0Yp4ILqbWD3LIM6 KT4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698620979; x=1699225779; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=6aMavgiqBpr9zBflN1DM1z02n5HlJVd9IxOJhgBeqP0=; b=ceDV3pR1tt493BKHdkp0sKAmoDhvD5hRt9au6hEkAVJE7nTPUDwrS1ILj7/Mxx2tpT sd1mjOzwUUYoMdcHtEuTaX1HL8EJlAjCIS4v8jdT1ny20iF1F3pXeh0EPU8nc8Sj2LFZ K+R8871W1wX5Zu8JwXNd7CheMCK02Bye0bDQkOgg9/2rO+bKfOg3eqPoLHYgqs9O1C4U Vbz/chzRcYBMgRBiQjBW2OjTC4Z2jS5fAOV063Zw2/f58oE62D965QWsQBWM+p6+JpfO BP6FwYePI/3xPS864bboPvZazjh4+PmlEDKqCHM7/eDZB/fhAOi96Tao2C/3RRgNmLMV 7cKQ== X-Gm-Message-State: AOJu0Yy5IcBXMd5uSz/xHWOw2UvOfGICeOiWULJEiU2uNSqA8+7sRHfw MAfn4iY/keJ8vdantL8EAiqk0g1ibHi7WA== X-Google-Smtp-Source: AGHT+IE9rKReEAlCXT8WRt/Hf0/zHMTAUVzPl43HlO6Q36YAJ+n/l742lBgs3GvMWFb34fNd98Xsxg== X-Received: by 2002:a5d:5186:0:b0:32d:b06c:d30b with SMTP id k6-20020a5d5186000000b0032db06cd30bmr5962332wrv.55.1698620978886; Sun, 29 Oct 2023 16:09:38 -0700 (PDT) Received: from krug (87-196-72-1.net.novis.pt. [87.196.72.1]) by smtp.gmail.com with ESMTPSA id s4-20020a5d69c4000000b0032d829e10c0sm6890488wrw.28.2023.10.29.16.09.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 29 Oct 2023 16:09:38 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting In-Reply-To: <c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN> (Dmitry Gutov's message of "Sun, 29 Oct 2023 01:24:50 +0300") References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <877cn8asud.fsf@HIDDEN> <c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN> Date: Sun, 29 Oct 2023 23:12:36 +0000 Message-ID: <8734xtauqj.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) 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: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dmitry@HIDDEN> writes: > On 27/10/2023 20:16, Jo=C3=A3o T=C3=A1vora wrote: > Thanks. My measurements are similar, except the difference switch the > other way a little bit. It might depend on the particulars of the > individual machine anyway. Yes, it could, but I've reproduced this in different hardware. Check that you're taking enough samples, I take about 15-20 samples. Maybe the lazy-hilit patch pays a an extra cost upfront for the very first C-h v or completing-read, to create the properties keys on the strings, which are then reused. This cost is ammortized very quickly, of course, but if you're taking the measurement immediately after Emacs -Q and with few samples, it skews the numbers. > All averages made using 'M-x calc-grab-region' followed by 'u M'. Wow, thanks for this tip. I wondered if there was an easier way than M-x cua-rectangle-mark-mode + hand rolled avg function. > I just meant that your version will be easier to use in > company--match-from-capf-face (because it works on individual > completions). Ah, that was my intution too. I misunderstood you then, I thought you meant the list version would be easier and I found that odd. >>> 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. >> If we really wanted to, we could also adopt the non-propertizing >> approach in my lazy-hilit patch, by calculating the score "just in >> time", much like Daniel's patch does it. But it should be clear that >> what we save in allocation in completion-pcm--hilit-commonality, we'll >> pay for in the same amount in consing later. So no performance benefit. > > Not for performance, no. Although the way it separates the sorting > into its own phase makes it easier to reason about that particular > cost. And for 300000 symbols, scoring and sorting really take the most > time, e.g. about 2/3rds. Which might help with optimizing it further > down in the future, somehow, I think further optimization would be localized to the scoring function itself, not to the place where it is performed. > But if course it would be nice to avoid the wart, so if you have any > better ideas, they are welcome. I'm not saying it would necessarily spread even further, but if you want to do scoring "just in time" like I suggested -- presumably to completely avoid propertizing strings -- that particular wart spreads a little more and thus becomes something that is slightly harder to remove later on. > So far you advocated toward avoiding breaking changes while > implementing the present performance improvement. Both patches do that, so what I've been arguing for is simplicity and coherence. I don't think completion-sorted-completions and the complexity it brings to minibuffer.el is a step in the rigth direction, and the performance benefits it does undeniably bring can be achieved with less drastic means. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 29 Oct 2023 04:42:21 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 29 00:42:21 2023
Received: from localhost ([127.0.0.1]:40225 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qwxcy-0001io-SK
for submit <at> debbugs.gnu.org; Sun, 29 Oct 2023 00:42:21 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:22532)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qwxcw-0001iZ-IV
for 47711 <at> debbugs.gnu.org; Sun, 29 Oct 2023 00:42:19 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6E09480060;
Sun, 29 Oct 2023 00:41:40 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1698554498;
bh=Cvxbx19Q0HisO66IOuLRjPmBNohSpiCqcjIzyzZxl4U=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=b8DznH+2f9aGHPnOYOVSKO6LHPA3fP77hXmL17FGBty7RPi0aoyNTyVUvc4VTuK44
sN9eayDW1JjoqWAB+lTobtLTmBDN0r8nnf8gdig7AbKJJoq+5w9mzGkwc0X14jxFFz
wj8ne4SqMQFB2cPn02OqV7Z8seyvPkii1WBCKt+tQiDye6loRWMZf+/GB3pF7bb1aS
zN6cisaYKH4rbyOABpkefLhWKVkFLtmxSQRO43qRVjPX+3qKWMClU/EHGmvxng0oJQ
VyBexlcel4LOuasaALnUSGqCbVZA3VYkQM1fgHWcyzhxq26OxlMCwnvltF71ezQIV5
+3RRd6+0zFGWQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id AF24D80667;
Sun, 29 Oct 2023 00:41:38 -0400 (EDT)
Received: from pastel (unknown [45.72.195.71])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 74B1A12016C;
Sun, 29 Oct 2023 00:41:38 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Dmitry Gutov <dmitry@HIDDEN>
Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2]
Add new `completion-filter-completions` API and deferred highlighting
In-Reply-To: <40ddec76-751a-36cd-7f45-34de2d9d9393@HIDDEN> (Dmitry Gutov's
message of "Sun, 29 Oct 2023 04:07:35 +0200")
Message-ID: <jwvv8aqnjsw.fsf-monnier+emacs@HIDDEN>
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN>
<CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN>
<56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN>
<CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN>
<328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN>
<83fsvcbio7.fsf@HIDDEN>
<9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN>
<877cnafv39.fsf@HIDDEN>
<9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN>
<CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN>
<7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN>
<CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN>
<5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN>
<jwv5y2stc2f.fsf-monnier+emacs@HIDDEN>
<bc621b6e-236a-736c-0723-0c17292ee5ee@HIDDEN>
<jwvsf5wqc33.fsf-monnier+emacs@HIDDEN>
<1504b2e4-42d9-5d7b-eaa2-c7b7d5ca02ba@HIDDEN>
<jwvsf5wrmfn.fsf-monnier+emacs@HIDDEN>
<40ddec76-751a-36cd-7f45-34de2d9d9393@HIDDEN>
Date: Sun, 29 Oct 2023 00:41:37 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.001 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47711
Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
=?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>,
47711 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> FWIW, this neat structure might not help too much: the most popular external
> completion backend (the LSP language servers, collectively) don't accept
> regexps or globs, they just send you the lists of completions available at
> point. With the name matching method sometimes configurable per-server.
Largely agreed. The main benefit tho is that you get just *one*
pattern, rather than three (one being the prefix argument, the second
being the `pred` arg which historically was so unused that it was abused
to hold the directory for file-name completion, so lots of tables don't
obey it, and the third being the `completion-regexp-list` that most coders
forget, and those who don't end up regretting not forgetting when it was
not meant for them), so it's much more clear.
> As such, the most useful methods currently are: 1) Emacs Regexp, 2) asking
> server for whatever it thinks is suitable (the "backend" completion style).
For the backends: agreed.
For the frontends (i.e. `completion-styles`), `glob` is the more useful
one, I'd say (except for the "external" style, of course).
We might also want support for things like `or` and `and` patterns, but
I haven't managed to fit them nicely in that structure :-(
> I would also probably want to standardize on the recommended type of TO
> anyway: some of them are likely going to result in better performance
> than others.
The TO is chosen by the specific completion table, based on what it can
handle best. So it should always be "optimal".
> So I guess it's also a way to make every completion table aware of PRED?
Note also that these `pred` patterns are expected to be exclusively
looking at the string (they're used for `completion-styles` kind of
functionality), so nothing like `file-directory-p` or `fboundp` kind of
predicates here.
The `pred`s used in things like `completing-read` and `read-file-name`
would be handled elsewhere such as `completion-table-with-predicate`.
This part is still up in the air, tho.
> That should work; though it might be hard to reach the same raw performance
> as the current all-completions + completion-regexp-list.
I don't see why: currently my code actually uses `all-completions` and
`completion-regexp-list`, so as long as the pattern can be turned into
a regexp without requiring an additional PRED (that's usually the case),
it should be just as fast (at least for large tables; for small tables
we have the overhead of the various method calls and pattern
conversions, of course).
Stefan
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 29 Oct 2023 02:08:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 28 22:08:25 2023 Received: from localhost ([127.0.0.1]:39943 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qwvE1-0005uU-CQ for submit <at> debbugs.gnu.org; Sat, 28 Oct 2023 22:08:25 -0400 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:35753) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1qwvDv-0005uB-W4 for 47711 <at> debbugs.gnu.org; Sat, 28 Oct 2023 22:08:23 -0400 Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.west.internal (Postfix) with ESMTP id 47AB13200124; Sat, 28 Oct 2023 22:07:41 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Sat, 28 Oct 2023 22:07:41 -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= 1698545260; x=1698631660; bh=M2L4AzMVPpI+cMM+ECgi89zAjqlAdeMTBeZ 1yasdGcg=; b=rgoszCqyLHaGeAphur8+OqUwfC2ccX05ektHxQIMCgnMb/KdXP5 6N4swtYVNVouk9Zwz1NsUeJFaSm/TbEat7EP48wJ/jLCMTzNkjq7HPF/aL/fQ+k9 6hFQ0xQi8LBhH+PhylHmdN68FYo0FiQuKqUnSqN9hegCRao+L1HKaO2e/+DlqAOC Ued75JyXEmF79m34MBa1TioTwCG7cI1tnd2fs6gIRx0WLK0dq2keVxdJIAC23FG9 5d6Fmi4KWqDz2NcAIL3T2Ct3seh/5ry3uBT5i1uFJf5yVZh/b1i7SSxDX6TBVwxR a75BXts31zemALkXYrp9RGbtjQSZQYa9eDw== 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= 1698545260; x=1698631660; bh=M2L4AzMVPpI+cMM+ECgi89zAjqlAdeMTBeZ 1yasdGcg=; b=Gs7WVvNmTpY75g5usva1NDs9NQMkwSnMe9nfCLZY5OSBTvxQL+N xjtGCuuKrRdXcaIgFVWirNQD4lcM17T+YLI9pnon00kdI8ILDsxwasjTYh+JfJiW 3/A4KUw200TuerbPwpIB8M7MRRpDoKiUjnntSxAXDVTrUF7aQodsS8hsfOrE/+Ww G83gF4iUykrg08E0zwLPo0NUFizQ5Cbt49mNmnu7hcESnX5wrqLE17ADPkc1YQ2E Rn67hoLGiZF2+/KR1QTYWx856e6BrvglcPMcEnlYvrrEX+at3Zi9Lvt85ojg5UKA nQui3hERSCurDBxcGpDH+xDo6EakEOSZTfw== X-ME-Sender: <xms:bL49Zfcm_Iuh4iAYGEeD3JCNRb5R1XKQzDoumirKAE0fjJV-kbg6-Q> <xme:bL49ZVOdCIv1Sps8W-KURt3Fev8TbY8aJ_pJkhxXA9jr95jIzdG5VBy0OS5kR7tl6 8kVtmcXfJZIrjdNbFw> X-ME-Received: <xmr:bL49ZYjm5-mB_hWCLzttqh8JJMGNVwo2_gfsDpVR6Koq3dOL9P8U_hqIHYV19Do> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrleejgdehgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpefhffehleejffegffeugefhkeektdffgfehjedvgeejtedtudehueffgffgfeej heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: <xmx:bL49ZQ_EHqtRGwV3jgIBPWuQeIv6g04-axaTpdTPfno7d_jdR8haxQ> <xmx:bL49Zbu4VnwvoCTZPyK5-P0tDM9S8ughfJjSpaHFy6jkdL1_MXrufQ> <xmx:bL49ZfFFL9KFtCyNasOyAGZ69YYDhYVyBMH8fevue8EfxR_2-rYhxQ> <xmx:bL49ZbIYBiUfje02ei7AkpJDSgtdumzDZB1KDbakWf72fvdFlYDF0g> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 28 Oct 2023 22:07:38 -0400 (EDT) Message-ID: <40ddec76-751a-36cd-7f45-34de2d9d9393@HIDDEN> Date: Sun, 29 Oct 2023 04:07:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Content-Language: en-US To: Stefan Monnier <monnier@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <jwv5y2stc2f.fsf-monnier+emacs@HIDDEN> <bc621b6e-236a-736c-0723-0c17292ee5ee@HIDDEN> <jwvsf5wqc33.fsf-monnier+emacs@HIDDEN> <1504b2e4-42d9-5d7b-eaa2-c7b7d5ca02ba@HIDDEN> <jwvsf5wrmfn.fsf-monnier+emacs@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <jwvsf5wrmfn.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.2 (---) On 27/10/2023 21:12, Stefan Monnier wrote: >>> More seriously, since it's a dynbound variable it can have unwanted >>> effects in nested calls to `all/try-completions`, so it's safer to >>> ignore that variable because its binding is not always "meant for us" 🙁 >> I guess it would be more precise if it was a function argument, e.g. the >> first argument to 'fancy-all-completions' or somesuch that all completion >> tables are supposed to use inside. OTOH, I suppose that might hinder those >> that use external programs. > In my "work in progress" (not touched since last December 🙁 ), > I replace `all-completions` with: > > (cl-defgeneric completion-table-fetch-matches ( table pattern > &optional pre session) > "Return candidates matching PATTERN in the completion TABLE. > For tables with subfields, PRE is the text found before PATTERN such that > (let ((len (length PRE))) > (equal (completion-table-boundaries TABLE PRE len) (cons len len))) > > Return a list of strings or a list of cons cells whose car is a string. > SESSION if non-nil is a hash-table where we can stash arbitrary auxiliary > info to avoid recomputing it between calls of the same \"session\".") > > `pattern`s can take various shapes. In my WiP code, I implement 4 kinds > of patterns: prefix, glob, regexp, and predicate. Now, we don't want > completion tables to have to handle each and every one of those pattern > kinds (the set of which is extensible via CLOS methods), so there's > a middleman: > > (cl-defgeneric completion-pattern-convert (to pattern) > "Convert PATTERN to be of type TO. > Returns a pair (PRED . NEWPATTERN) where NEWPATTERN is of type TO > and should match everything that PATTERN matches. PRED is nil > if NEWPATTERN matches exactly the same candidates as PATTERN > and otherwise it is a function that takes a candidate and returns non-nil if the > candidate also matches PATTERN. PRED should not presume that the candidate > has already been filtered by NEWPATTERN." FWIW, this neat structure might not help too much: the most popular external completion backend (the LSP language servers, collectively) don't accept regexps or globs, they just send you the lists of completions available at point. With the name matching method sometimes configurable per-server. As such, the most useful methods currently are: 1) Emacs Regexp, 2) asking server for whatever it thinks is suitable (the "backend" completion style). I would also probably want to standardize on the recommended type of TO anyway: some of them are likely going to result in better performance than others. BTW, this reminds me about urgrep in GNU ELPA, which I think includes converters between different flavors of regexp. Something to keep in mind for the occasional completion table that's based on a Grep-like tool. > So the fallback definition of `completion-table-fetch-matches`, which > relies on the old API looks like: > > (defun completion-table--fetch-legacy (table pattern &optional pre _session) > (pcase-let ((`(,pred . ,regexp) > (completion-pattern-convert 'regexp pattern)) > (`(,ppred . ,prefix) > (completion-pattern-convert 'prefix pattern))) > (let ((matches > (let ((completion-regexp-list (if ppred (list regexp))) > (case-fold-search completion-ignore-case)) > (all-completions (concat pre prefix) table)))) > (if (null pred) > matches > (seq-filter pred matches))))) > > This is of course incorrect because `all-completions` could ignore > `completion-regexp-list`, in which case we should use `ppred` instead of > `pred` on the last 3 lines 😄 > > It has the disadvantage that every completion-table basically needs to > start by calling `completion-pattern-convert` so as to convert the > pattern to the format that it supports. But I think it's still better > than the current API where completion tables "have to" obey the prefix > string, the `completion-regexp-list`, and the predicate (and where the > latter two are often nil so tables tends to ignore them, and since > tables ignore them callers don't use them, etc...). So I guess it's also a way to make every completion table aware of PRED? That should work; though it might be hard to reach the same raw performance as the current all-completions + completion-regexp-list.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 28 Oct 2023 22:25:40 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 28 18:25:40 2023 Received: from localhost ([127.0.0.1]:39770 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qwrkR-0008Rp-Pf for submit <at> debbugs.gnu.org; Sat, 28 Oct 2023 18:25:40 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:60985) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1qwrkM-0008RR-C8 for 47711 <at> debbugs.gnu.org; Sat, 28 Oct 2023 18:25:38 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1E3C35C0129; Sat, 28 Oct 2023 18:24:56 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sat, 28 Oct 2023 18:24:56 -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= 1698531896; x=1698618296; bh=nf4kMJot6EJZiVhkpKbPRgNc78nBCOY3SOC RJxE/bow=; b=KNcJ3kH9/zHCpLGs3xTDL1ylU03whUVhsJl9pVODnBqYrjsQELS QqZHsHn+ROTIFS5eCU3oSTGVj0VpoV9RpW1lK0o7C6e91KiqDVEPmrp/1SorTNbf Row/083GcvcsMztUWsj1L1gUU/SS4K17ps/f8IpzbSlqijIAhRM9fPTY3+wpCS6s YMJk5O3qSRsxG0JiT0sjNKS47u9hzh6e5AFY3dDafMWpsuYqICTUTFyJQSulbgEL ytGbH3BmIf5H8dm/liKipPstm49gyBXYF6kA2JkqJwMW22Dd4Nv+lY5a4Dk1gQlG CBSA8enJWJF06+M29iTe/dCd0ckqgQBs8QQ== 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= 1698531896; x=1698618296; bh=nf4kMJot6EJZiVhkpKbPRgNc78nBCOY3SOC RJxE/bow=; b=gABs6itfTuowYpM06QW2Zvzi6r/wRqIvOKGTChfeQmcgokGBDMK b0ukvIt8EWbOrGU92IETCP4GI+s29gCfkcyto56LayNvWIIEoigIWjtV8zBhkuC6 aAvhWMXIYpLBQaAaiFd8nzv62xtIQv/WRhYImg+EM+ID7HB9sObMuLKbXQMxe2Wd V82mbFbVYO5Hct8OqQHd/FNY0biEXVV68C98tCJ1L2u5avAkWG3MtdZKQUvelWC8 Z6tl+rJ4kIJ3vVaMo3F+/TMtTIvsNRPbaa6Ztv2UQMQbP90Zmnc8Imo/Liqq6ukL LNIXD5y9E4DzXgJ1SgyjBQQs7n/0iJVu13Q== X-ME-Sender: <xms:N4o9Zcribea4eIh6mYLCB5E982xl5kKi8zVUei_8pMPfNsKIVAFs7w> <xme:N4o9ZSoouVzzE-fVoahhT8m2Wj6cLHhhSz_yyyQBjT84MsCmneqOu3UQWGHkLTYss mac78rp44FiiuMM51g> X-ME-Received: <xmr:N4o9ZRMuBD-sAXA79ub6YgFcLMYe1aF_e_oPKWK-lq74HhPr7kBrTG4K5M-qSyE> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrleejgdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpefftedtvdevuedvffffvdethedvveektedvhfdtfffhfeeklefhleeuhfehvdel jeenucffohhmrghinhepughifhhfrdhhvghrvgdpghhithhhuhgsrdgtohhmnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehg uhhtohhvrdguvghv X-ME-Proxy: <xmx:N4o9ZT4clM40z1iRuqj5F1f9Srf36vx9cyeMeTFY9wt5fEq4ypXYJg> <xmx:N4o9Zb5-2w-7-FJi5n1mNjtq0HgVEUG8H_WEwYu96vcNY6DiFz0VPw> <xmx:N4o9ZThHYhAm3FyoouqfKx_IW08Ssfkfl8RAiFmvz6R1gu5RXx2FCA> <xmx:OIo9Zdlbpx8uecrMsj0BjFjgSZPjw9d8TZsSRS7AAWYqdA_REwximw> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 28 Oct 2023 18:24:53 -0400 (EDT) Message-ID: <c52b9196-b947-5598-b584-b1703e16cb49@HIDDEN> Date: Sun, 29 Oct 2023 01:24:50 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <877cn8asud.fsf@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <877cn8asud.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.2 (---) On 27/10/2023 20:16, João Távora wrote: > My attempts to fix the optimization to work correctly in all cases > complicated the code and then slowed down the bare completion-read case. > Not worth it IMO, therefore I have reverted it in the branch and in the > latest patch I attach (lazy-hilit-2023-v4.diff). Here are the latest > measurements for the "yoyo" test, now considering the C-h v scenario: > > ;; Daniel+Dmitry completin-read: 0.834s avg > ;; Daniel+Dmitry C-h v: 0.988s avg > > ;; lazy-hilit completing-read: 0.825s avg > ;; lazy-hilit C-h v: 0.946s avg > > Again, this shows my patch to be about 2-4% faster, though not really > relevant. > > Again, the optimization I removed, if it were done correctly (which it > wasn't) could maybe shave off another 8-9% off that. Thanks. My measurements are similar, except the difference switch the other way a little bit. It might depend on the particulars of the individual machine anyway. I also tried to compare the perf for 150K symbols, in case either the filtering or the sorting (which should have different complexities) would come to the front, but no such luck: lazy-hilit 300000 completing-read 0.6063497 C-h v 0.72435995 150000 completing-read 0.316961 C-h v 0.39933575 d+d 300000 completing-read 0.571481 C-h v 0.69817995 150000 completing-read 0.308940 C-h v 0.350437 All averages made using 'M-x calc-grab-region' followed by 'u M'. >> 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. > > Don't fully follow this. Can you perhaps show two versions (or two > snippets) of the company-capf code, the handy and the non-handy version? I just meant that your version will be easier to use in company--match-from-capf-face (because it works on individual completions). >> 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. > > If we really wanted to, we could also adopt the non-propertizing > approach in my lazy-hilit patch, by calculating the score "just in > time", much like Daniel's patch does it. But it should be clear that > what we save in allocation in completion-pcm--hilit-commonality, we'll > pay for in the same amount in consing later. So no performance benefit. Not for performance, no. Although the way it separates the sorting into its own phase makes it easier to reason about that particular cost. And for 300000 symbols, scoring and sorting really take the most time, e.g. about 2/3rds. Which might help with optimizing it further down in the future, somehow, > And if we do that, don't forget there will be the ugly "unquoted" > complication to deal with. Then again, in my understanding that > complication is due to similar problem of mixing business and display > logic. That's assuming I understand this comment in minibuffer.el > correctly: > > ;; Here we choose to quote all elements returned, but a better option > ;; would be to return unquoted elements together with a function to > ;; requote them, so that *Completions* can show nicer unquoted values > ;; which only get quoted when needed by choose-completion. > > So I would look into solving that first, instead of allowing the > "unquoted" hacks to spread even further in minibuffer.el I don't really understand this quoting-requoting business, never dug into the feature or the code. But perhaps keeping the original string might even help avoid the "requoting" step? Though that would depend on which version of the string the scoring and highligher functions expect to work on. Speaking of the comment, it sounds like the said "requote function" would need to be passed up the call stack and used according to some protocol. The idea itself reminds me of the proposal described in https://github.com/company-mode/company-mode/discussions/1422 (it was also previously brought up on the lsp-mode tracker). It seems like either the completion tables would need a new method, or the capf tuples - a new function property, which all UIs using would need to start supporting in lock-step. At least that's the case if we use that to solve the requoting issue (the LSP clients' migration to use complete-function can be done more easily). So far you advocated toward avoiding breaking changes while implementing the present performance improvement. Daniel's argument that the quoting completion tables are already slow enough sounds very reasonable to me, that an extra text property round-trip won't be noticeable. And the current version of the patch is functional and passes all tests, so it's not clear which other places would the "hack" need to spead into. Unless it helps with reducing code, etc, as per my vague guess above. But if course it would be nice to avoid the wart, so if you have any better ideas, they are welcome.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 27 Oct 2023 18:13:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 27 14:13:02 2023
Received: from localhost ([127.0.0.1]:37158 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qwRKP-0008JZ-Pq
for submit <at> debbugs.gnu.org; Fri, 27 Oct 2023 14:13:02 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62316)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qwRKO-0008J7-2Q
for 47711 <at> debbugs.gnu.org; Fri, 27 Oct 2023 14:13:00 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1269710013E;
Fri, 27 Oct 2023 14:12:23 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1698430342;
bh=n51eu1FbK21yNxjOMzKMW99K0ZHoHIZcnKcWwODvDn0=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=KbD0SwiN/zVFyovUulFwGAABArqkvixZJqJYE0AvTDxqqArwfwPIzraouzEL73gLn
ut0PTnKXOpDjQyyhjW0n788Wv/rFItDKi30vwn6yLuPl+8EDyhW/a7uf19rgr6HZJN
x2/YOs1LRqM4X81YADxQXHnk+KgqDTrlMykvYnZg5tgGIBbJNec499OBh+nndeGPRt
FxS7tpEhgErZfC+Uhu9hTJPGMFuqnr+OtiKBrrFVzsEvZY1qdq6PNR7QbXjfwfv3KY
UJAyo6niMmbHnVFIMEwHstRKPNVXeXrAfPmllskNpuDC8mj2Lyn5ScqTcFOTrQhJuB
MRCWubHflXiKA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3E63E10006B;
Fri, 27 Oct 2023 14:12:22 -0400 (EDT)
Received: from pastel (unknown [45.72.195.71])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 075C812004E;
Fri, 27 Oct 2023 14:12:22 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Dmitry Gutov <dmitry@HIDDEN>
Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2]
Add new `completion-filter-completions` API and deferred highlighting
In-Reply-To: <1504b2e4-42d9-5d7b-eaa2-c7b7d5ca02ba@HIDDEN> (Dmitry Gutov's
message of "Fri, 27 Oct 2023 20:06:11 +0300")
Message-ID: <jwvsf5wrmfn.fsf-monnier+emacs@HIDDEN>
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN>
<fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN>
<3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN>
<CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN>
<56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN>
<CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN>
<328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN>
<83fsvcbio7.fsf@HIDDEN>
<9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN>
<877cnafv39.fsf@HIDDEN>
<9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN>
<CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN>
<7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN>
<CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN>
<5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN>
<jwv5y2stc2f.fsf-monnier+emacs@HIDDEN>
<bc621b6e-236a-736c-0723-0c17292ee5ee@HIDDEN>
<jwvsf5wqc33.fsf-monnier+emacs@HIDDEN>
<1504b2e4-42d9-5d7b-eaa2-c7b7d5ca02ba@HIDDEN>
Date: Fri, 27 Oct 2023 14:12:20 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.150 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47711
Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
=?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>,
47711 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>>> We could, for example, have a period when we warn about returned
>>> non-matches. string-match-p is not free, but it's not very expensive either.
>> The problem is that I dislike `completion-regexp-list` :-)
> When we do use it, we can avoid copying all the strings to a new
> list. Skipping consing this way can really move the needle at the level of
> optimization we're discussing now.
Oh, don't get me wrong, I like the functionality it offers, I just
dislike the way it works.
>> More seriously, since it's a dynbound variable it can have unwanted
>> effects in nested calls to `all/try-completions`, so it's safer to
>> ignore that variable because its binding is not always "meant for us" :-(
> I guess it would be more precise if it was a function argument, e.g. the
> first argument to 'fancy-all-completions' or somesuch that all completion
> tables are supposed to use inside. OTOH, I suppose that might hinder those
> that use external programs.
In my "work in progress" (not touched since last December :-( ),
I replace `all-completions` with:
(cl-defgeneric completion-table-fetch-matches ( table pattern
&optional pre session)
"Return candidates matching PATTERN in the completion TABLE.
For tables with subfields, PRE is the text found before PATTERN such that
(let ((len (length PRE)))
(equal (completion-table-boundaries TABLE PRE len) (cons len len)))
Return a list of strings or a list of cons cells whose car is a string.
SESSION if non-nil is a hash-table where we can stash arbitrary auxiliary
info to avoid recomputing it between calls of the same \"session\".")
`pattern`s can take various shapes. In my WiP code, I implement 4 kinds
of patterns: prefix, glob, regexp, and predicate. Now, we don't want
completion tables to have to handle each and every one of those pattern
kinds (the set of which is extensible via CLOS methods), so there's
a middleman:
(cl-defgeneric completion-pattern-convert (to pattern)
"Convert PATTERN to be of type TO.
Returns a pair (PRED . NEWPATTERN) where NEWPATTERN is of type TO
and should match everything that PATTERN matches. PRED is nil
if NEWPATTERN matches exactly the same candidates as PATTERN
and otherwise it is a function that takes a candidate and returns non-nil if the
candidate also matches PATTERN. PRED should not presume that the candidate
has already been filtered by NEWPATTERN."
So the fallback definition of `completion-table-fetch-matches`, which
relies on the old API looks like:
(defun completion-table--fetch-legacy (table pattern &optional pre _session)
(pcase-let ((`(,pred . ,regexp)
(completion-pattern-convert 'regexp pattern))
(`(,ppred . ,prefix)
(completion-pattern-convert 'prefix pattern)))
(let ((matches
(let ((completion-regexp-list (if ppred (list regexp)))
(case-fold-search completion-ignore-case))
(all-completions (concat pre prefix) table))))
(if (null pred)
matches
(seq-filter pred matches)))))
This is of course incorrect because `all-completions` could ignore
`completion-regexp-list`, in which case we should use `ppred` instead of
`pred` on the last 3 lines :-)
It has the disadvantage that every completion-table basically needs to
start by calling `completion-pattern-convert` so as to convert the
pattern to the format that it supports. But I think it's still better
than the current API where completion tables "have to" obey the prefix
string, the `completion-regexp-list`, and the predicate (and where the
latter two are often nil so tables tends to ignore them, and since
tables ignore them callers don't use them, etc...).
Stefan
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 27 Oct 2023 17:14:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 27 13:14:28 2023
Received: from localhost ([127.0.0.1]:37024 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qwQPi-0006Jp-T3
for submit <at> debbugs.gnu.org; Fri, 27 Oct 2023 13:14:27 -0400
Received: from mail-ot1-x32e.google.com ([2607:f8b0:4864:20::32e]:59426)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1qwQPf-0006JU-Ma
for 47711 <at> debbugs.gnu.org; Fri, 27 Oct 2023 13:14:24 -0400
Received: by mail-ot1-x32e.google.com with SMTP id
46e09a7af769-6c4a25f6390so1498969a34.2
for <47711 <at> debbugs.gnu.org>; Fri, 27 Oct 2023 10:13:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1698426825; x=1699031625; darn=debbugs.gnu.org;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
bh=xb8HZlLKLUOYer2snSqmXG4Smpla9VhAVUCg/sr6lIg=;
b=AQXuZGaP+KDqvLB15k2SOtUEQc688AsJJO+HE5f/SUK27oSUiuXCDMo1lNGRP3c2Ck
d7dbmoOgdOenl922AQRe7MuH8F8LQqQ9vGK7MdxuTuFvQxwyeWgC6fFPDF0UyRBxJkKh
YM4vViovT9rcPN4BhHjIImub/MVs4oiEOt9TCJpT+OgmGNH8Tf1FedfZ2OcEkCz+ZMsW
9x/MEaHD1EoNsNKGzsx6rzsmreX3c+u6CjF2X+BoADJSXXzqoM/sWLIorsi7rx/WwpG5
dw83SA8EjwxT75K+6lC3oRxtGkF/JB/G6hrtJMz8fU+ZMbHXd29WAzovBHi0vumpbRe4
+NLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1698426825; x=1699031625;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=xb8HZlLKLUOYer2snSqmXG4Smpla9VhAVUCg/sr6lIg=;
b=sOenbwdDSiPR1TQ9mtR1cNDe1Vu6AFFHxy2b26SxswCtYX0lmDlKAamgSDDiw5fF8G
cIjhBTMEv+XMHQ7JLvrLLOR8URhEAvZLitSCWpALRmQJaq0Sj41+ntIFJp1xy+1rmpF0
tSfhqAsaU2AXBjU20BM8TYU9KsXdIJu/2hkgJsQorfB8fA4/YqdwYHjL7pIf5HU6+wJs
FUHUSXaM5tMDKR1UAcgAN4VsyAk+SW91N1xN9e/zT0Qm2G/pY6djdwhiNksB+gzgM4Ek
nQJciQxrxEvt3MnBVNbEmd9Nf2G/bKhvG9Gr838JDiKx1yYepp7tHdAlQHm9gOAsf7a3
dNHQ==
X-Gm-Message-State: AOJu0YzNrvJLwYIPvqXHUfTp3xsiaacH7N93XKDOsucYNnEk03QXPC5g
n6l7FQTNqTTpq9MNal6b2Upy1+J03pdYqA==
X-Google-Smtp-Source: AGHT+IHsECQld+u4m9wYOp+7GAjRQdcfvTy3pu2TOz0kfA6mlsG8dXbKxQgbpIafhdDWJiBg61kgKA==
X-Received: by 2002:a05:6830:2b23:b0:6b4:5ed3:8246 with SMTP id
l35-20020a0568302b2300b006b45ed38246mr4825036otv.2.1698426825106;
Fri, 27 Oct 2023 10:13:45 -0700 (PDT)
Received: from krug (87-196-80-249.net.novis.pt. [87.196.80.249])
by smtp.gmail.com with ESMTPSA id
v31-20020a4a8c62000000b0057b43a25deasm445820ooj.3.2023.10.27.10.13.42
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 27 Oct 2023 10:13:44 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Dmitry Gutov <dmitry@HIDDEN>
Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2]
Add new `completion-filter-completions` API and deferred highlighting
In-Reply-To: <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> (Dmitry Gutov's
message of "Fri, 27 Oct 2023 16:29:03 +0300")
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN>
<fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN>
<3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN>
<CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN>
<56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN>
<CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN>
<328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN>
<83fsvcbio7.fsf@HIDDEN>
<9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN>
<877cnafv39.fsf@HIDDEN>
<9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN>
<CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN>
<7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN>
<CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN>
<5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN>
Date: Fri, 27 Oct 2023 18:16:42 +0100
Message-ID: <877cn8asud.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47711
Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Dmitry Gutov <dmitry@HIDDEN> writes:
> but that can't be that reason.
Indeed it isn't. But you're not far off, I think. Anyway, in the
(completing-read "" obarray) scenario, the shortcut is taken, and that
and the fact that the optimization then completing skips scoring for it
-- which is blatantly wrong -- is why it is much faster.
Looking at this, it seems that string-match with a non-group-capturing
regexp over all the matches (the thing that the change was optimizing
away) isn't that expensive in the overall gist of things.
Thus in the C-h v case, the shortcut isn't taken and the optimization
does what it should, but nothing gargantuan, around 8-9%. Also keep in
mind this yoyo case is pretty contrived and I suspect more realistic
cases would have even more modest gains.
My attempts to fix the optimization to work correctly in all cases
complicated the code and then slowed down the bare completion-read case.
Not worth it IMO, therefore I have reverted it in the branch and in the
latest patch I attach (lazy-hilit-2023-v4.diff). Here are the latest
measurements for the "yoyo" test, now considering the C-h v scenario:
;; Daniel+Dmitry completin-read: 0.834s avg
;; Daniel+Dmitry C-h v: 0.988s avg
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
;; lazy-hilit completing-read: 0.825s avg
;; lazy-hilit C-h v: 0.946s avg
Again, this shows my patch to be about 2-4% faster, though not really
relevant.
Again, the optimization I removed, if it were done correctly (which it
wasn't) could maybe shave off another 8-9% off that.
> 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.
Don't fully follow this. Can you perhaps show two versions (or two
snippets) of the company-capf code, the handy and the non-handy version?
> 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.
Maybe. Changes to calling convention can be argued for but, when
possible, they shoudn't be in with performance improvements.
> 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.
If we really wanted to, we could also adopt the non-propertizing
approach in my lazy-hilit patch, by calculating the score "just in
time", much like Daniel's patch does it. But it should be clear that
what we save in allocation in completion-pcm--hilit-commonality, we'll
pay for in the same amount in consing later. So no performance benefit.
And if we do that, don't forget there will be the ugly "unquoted"
complication to deal with. Then again, in my understanding that
complication is due to similar problem of mixing business and display
logic. That's assuming I understand this comment in minibuffer.el
correctly:
;; Here we choose to quote all elements returned, but a better option
;; would be to return unquoted elements together with a function to
;; requote them, so that *Completions* can show nicer unquoted values
;; which only get quoted when needed by choose-completion.
So I would look into solving that first, instead of allowing the
"unquoted" hacks to spread even further in minibuffer.el
> 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.
I agree on some points, and looking at this from a API-convenience
standpoint I note two things:
* To get late highlighting in Daniel's patch, one has to use a whole new
API entry function to gather completions, and another to fontify
completions. One also deprecates an existing member of the API.
* In my patch, one binds a new API varaible and uses a function to fontify
completions. No deprecations.
Even if it wasn't a much simpler change to minibuffer.el without any
backward-compatibility gymnastics, I still think the latter is much
cleaner and easier to implement for completion frontends. The fact that
there's no deprecation of one of the most important members of the API
to date makes it more confortable to understand IMO.
Jo=C3=A3o
--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline; filename=lazy-hilit-2023-v4.diff
diff --git a/lisp/icomplete.el b/lisp/icomplete.el
index e6fdd1f1836..3e888c8b06a 100644
--- a/lisp/icomplete.el
+++ b/lisp/icomplete.el
@@ -722,7 +722,8 @@ icomplete-exhibit
;; Check if still in the right buffer (bug#61308)
(or (window-minibuffer-p) completion-in-region--data)
(icomplete-simple-completing-p)) ;Shouldn't be necessary.
- (let ((saved-point (point)))
+ (let ((saved-point (point))
+ (completion-lazy-hilit t))
(save-excursion
(goto-char (icomplete--field-end))
;; Insert the match-status information:
@@ -754,12 +755,13 @@ icomplete-exhibit
(overlay-end rfn-eshadow-overlay)))
(let* ((field-string (icomplete--field-string))
(text (while-no-input
+ (benchmark-progn
(icomplete-completions
field-string
(icomplete--completion-table)
(icomplete--completion-predicate)
(if (window-minibuffer-p)
- (eq minibuffer--require-match t)))))
+ (eq minibuffer--require-match t))))))
(buffer-undo-list t)
deactivate-mark)
;; Do nothing if while-no-input was aborted.
@@ -901,7 +903,7 @@ icomplete--render-vertical
'icomplete-selected-match 'append comp)
collect (concat prefix
(make-string (- max-prefix-len (length prefix)) ? )
- comp
+ (completion-lazy-hilit comp)
(make-string (- max-comp-len (length comp)) ? )
suffix)
into lines-aux
@@ -1067,7 +1069,8 @@ icomplete-completions
(if (< prospects-len prospects-max)
(push comp prospects)
(setq limit t)))
- (setq prospects (nreverse prospects))
+ (setq prospects
+ (nreverse (mapcar #'completion-lazy-hilit prospects)))
;; Decorate first of the prospects.
(when prospects
(let ((first (copy-sequence (pop prospects))))
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 2120e31775e..cd8eeee2c78 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1234,6 +1234,7 @@ completion-all-completions
POINT is the position of point within STRING.
The return value is a list of completions and may contain the base-size
in the last `cdr'."
+ (setq completion-lazy-hilit-fn nil)
;; FIXME: We need to additionally return the info needed for the
;; second part of completion-base-position.
(completion--nth-completion 2 string table pred point metadata))
@@ -3749,108 +3750,194 @@ flex-score-match-tightness
than the latter (which has two \"holes\" and three
one-letter-long matches).")
+(defvar-local completion-lazy-hilit nil
+ "If non-nil, request completion lazy highlighting.
+
+Completion-presenting frontends may opt to bind this variable to
+non-nil value in the context of completion-producing calls (such
+as `completion-all-sorted-completions'). This hints the
+intervening completion styles that they do not need to
+fontify (i.e. propertize with the `face' property) completion
+strings with highlights of the matching parts.
+
+When doing so, it is the frontend -- not the style -- who becomes
+responsible this fontification. The frontend binds this variable
+to non-nil, and calls the function with the same name
+`completion-lazy-hilit' on each completion string that is to be
+displayed to the user.
+
+Note that only some completion styles take advantage of this
+variable for optimization purposes. Other styles will ignore the
+hint and greedily fontify as usual. It is still safe for a
+frontend to call `completion-lazy-hilit' in these situations.
+
+To author a completion style that takes advantage see
+`completion-lazy-hilit-fn' and look in the source of
+`completion-pcm--hilit-commonality'.")
+
+(defvar completion-lazy-hilit-fn nil
+ "Used by completions styles to honouring `completion-lazy-hilit'.
+When a given style wants to enable support for
+`completion-lazy-hilit' (which see), that style should set this
+variable to a function of one argument, a fresh string to be
+displayed to the user. The function is responsible for
+destructively highlighting the string.")
+
+(defun completion-lazy-hilit (str)
+ "Return a copy of completion STR that is `face'-propertized.
+See documentation for variable `completion-lazy-hilit' for more
+details."
+ (if (and completion-lazy-hilit completion-lazy-hilit-fn)
+ (funcall completion-lazy-hilit-fn (copy-sequence str))
+ str))
+
+(defun completion--hilit-from-re (string regexp)
+ "Fontify STRING with `completions-common-part' using REGEXP."
+ (let* ((md (and regexp (string-match regexp string) (cddr (match-data t))))
+ (me (and md (match-end 0)))
+ (from 0))
+ (while md
+ (add-face-text-property from (pop md) 'completions-common-part nil string)
+ (setq from (pop md)))
+ (unless (or (not me) (= from me))
+ (add-face-text-property from me 'completions-common-part nil string))
+ string))
+
+(defun completion--flex-score-1 (md-groups match-end len)
+ "Compute matching score of completion.
+The score lies in the range between 0 and 1, where 1 corresponds to
+the full match.
+MD-GROUPS is the \"group\" part of the match data.
+MATCH-END is the end of the match.
+LEN is the length of the completion string."
+ (let* ((from 0)
+ ;; To understand how this works, consider these simple
+ ;; ascii diagrams showing how the pattern "foo"
+ ;; flex-matches "fabrobazo", "fbarbazoo" and
+ ;; "barfoobaz":
+
+ ;; f abr o baz o
+ ;; + --- + --- +
+
+ ;; f barbaz oo
+ ;; + ------ ++
+
+ ;; bar foo baz
+ ;; +++
+
+ ;; "+" indicates parts where the pattern matched. A
+ ;; "hole" in the middle of the string is indicated by
+ ;; "-". Note that there are no "holes" near the edges
+ ;; of the string. The completion score is a number
+ ;; bound by (0..1] (i.e., larger than (but not equal
+ ;; to) zero, and smaller or equal to one): the higher
+ ;; the better and only a perfect match (pattern equals
+ ;; string) will have score 1. The formula takes the
+ ;; form of a quotient. For the numerator, we use the
+ ;; number of +, i.e. the length of the pattern. For
+ ;; the denominator, it first computes
+ ;;
+ ;; hole_i_contrib = 1 + (Li-1)^(1/tightness)
+ ;;
+ ;; , for each hole "i" of length "Li", where tightness
+ ;; is given by `flex-score-match-tightness'. The
+ ;; final value for the denominator is then given by:
+ ;;
+ ;; (SUM_across_i(hole_i_contrib) + 1) * len
+ ;;
+ ;; , where "len" is the string's length.
+ (score-numerator 0)
+ (score-denominator 0)
+ (last-b 0))
+ (while (and md-groups (car md-groups))
+ (let ((a from)
+ (b (pop md-groups)))
+ (setq
+ score-numerator (+ score-numerator (- b a)))
+ (unless (or (= a last-b)
+ (zerop last-b)
+ (= a len))
+ (setq
+ score-denominator (+ score-denominator
+ 1
+ (expt (- a last-b 1)
+ (/ 1.0
+ flex-score-match-tightness)))))
+ (setq
+ last-b b))
+ (setq from (pop md-groups)))
+ ;; If `pattern' doesn't have an explicit trailing any, the
+ ;; regex `re' won't produce match data representing the
+ ;; region after the match. We need to account to account
+ ;; for that extra bit of match (bug#42149).
+ (unless (= from match-end)
+ (let ((a from)
+ (b match-end))
+ (setq
+ score-numerator (+ score-numerator (- b a)))
+ (unless (or (= a last-b)
+ (zerop last-b)
+ (= a len))
+ (setq
+ score-denominator (+ score-denominator
+ 1
+ (expt (- a last-b 1)
+ (/ 1.0
+ flex-score-match-tightness)))))
+ (setq
+ last-b b)))
+ (/ score-numerator (* len (1+ score-denominator)) 1.0)))
+
+(defvar completion--flex-score-last-md nil
+ "Helper variable for `completion--flex-score'.")
+
+(defun completion--flex-score (str re &optional dont-error)
+ "Compute flex score of completion STR based on RE.
+If DONT-ERROR, just return nil if RE doesn't match STR."
+ (cond ((string-match re str)
+ (let* ((match-end (match-end 0))
+ (md (cddr
+ (setq
+ completion--flex-score-last-md
+ (match-data t completion--flex-score-last-md)))))
+ (completion--flex-score-1 md match-end (length str))))
+ ((not dont-error)
+ (error "Internal error: %s does not match %s" re str))))
+
(defun completion-pcm--hilit-commonality (pattern completions)
"Show where and how well PATTERN matches COMPLETIONS.
PATTERN, a list of symbols and strings as seen
`completion-pcm--merge-completions', is assumed to match every
-string in COMPLETIONS. Return a deep copy of COMPLETIONS where
-each string is propertized with `completion-score', a number
-between 0 and 1, and with faces `completions-common-part',
-`completions-first-difference' in the relevant segments."
+string in COMPLETIONS.
+
+If `completion-lazy-hilit' is nil, return a deep copy of
+COMPLETIONS where each string is propertized with
+`completion-score', a number between 0 and 1, and with faces
+`completions-common-part', `completions-first-difference' in the
+relevant segments.
+
+Else, if `completion-lazy-hilit' is t, return COMPLETIONS where
+each string now has a `completion-score' property and no
+highlighting."
(cond
((and completions (cl-loop for e in pattern thereis (stringp e)))
(let* ((re (completion-pcm--pattern->regex pattern 'group))
- (point-idx (completion-pcm--pattern-point-idx pattern))
- (case-fold-search completion-ignore-case)
- last-md)
- (mapcar
- (lambda (str)
- ;; Don't modify the string itself.
- (setq str (copy-sequence str))
- (unless (string-match re str)
- (error "Internal error: %s does not match %s" re str))
- (let* ((pos (if point-idx (match-beginning point-idx) (match-end 0)))
- (match-end (match-end 0))
- (md (cddr (setq last-md (match-data t last-md))))
- (from 0)
- (end (length str))
- ;; To understand how this works, consider these simple
- ;; ascii diagrams showing how the pattern "foo"
- ;; flex-matches "fabrobazo", "fbarbazoo" and
- ;; "barfoobaz":
-
- ;; f abr o baz o
- ;; + --- + --- +
-
- ;; f barbaz oo
- ;; + ------ ++
-
- ;; bar foo baz
- ;; +++
-
- ;; "+" indicates parts where the pattern matched. A
- ;; "hole" in the middle of the string is indicated by
- ;; "-". Note that there are no "holes" near the edges
- ;; of the string. The completion score is a number
- ;; bound by (0..1] (i.e., larger than (but not equal
- ;; to) zero, and smaller or equal to one): the higher
- ;; the better and only a perfect match (pattern equals
- ;; string) will have score 1. The formula takes the
- ;; form of a quotient. For the numerator, we use the
- ;; number of +, i.e. the length of the pattern. For
- ;; the denominator, it first computes
- ;;
- ;; hole_i_contrib = 1 + (Li-1)^(1/tightness)
- ;;
- ;; , for each hole "i" of length "Li", where tightness
- ;; is given by `flex-score-match-tightness'. The
- ;; final value for the denominator is then given by:
- ;;
- ;; (SUM_across_i(hole_i_contrib) + 1) * len
- ;;
- ;; , where "len" is the string's length.
- (score-numerator 0)
- (score-denominator 0)
- (last-b 0)
- (update-score-and-face
- (lambda (a b)
- "Update score and face given match range (A B)."
- (add-face-text-property a b
- 'completions-common-part
- nil str)
- (setq
- score-numerator (+ score-numerator (- b a)))
- (unless (or (= a last-b)
- (zerop last-b)
- (= a (length str)))
- (setq
- score-denominator (+ score-denominator
- 1
- (expt (- a last-b 1)
- (/ 1.0
- flex-score-match-tightness)))))
- (setq
- last-b b))))
- (while md
- (funcall update-score-and-face from (pop md))
- (setq from (pop md)))
- ;; If `pattern' doesn't have an explicit trailing any, the
- ;; regex `re' won't produce match data representing the
- ;; region after the match. We need to account to account
- ;; for that extra bit of match (bug#42149).
- (unless (= from match-end)
- (funcall update-score-and-face from match-end))
- (if (> (length str) pos)
- (add-face-text-property
- pos (1+ pos)
- 'completions-first-difference
- nil str))
- (unless (zerop (length str))
- (put-text-property
- 0 1 'completion-score
- (/ score-numerator (* end (1+ score-denominator)) 1.0) str)))
- str)
- completions)))
+ (score (lambda (str)
+ (put-text-property 0 1 'completion-score
+ (completion--flex-score str re)
+ str))))
+ (cond (completion-lazy-hilit
+ (setq completion-lazy-hilit-fn
+ (lambda (str) (completion--hilit-from-re str re)))
+ (mapc score completions))
+ (t
+ (mapcar
+ (lambda (str)
+ (setq str (copy-sequence str))
+ (funcall score str)
+ (completion--hilit-from-re str re)
+ str)
+ completions)))))
(t completions)))
(defun completion-pcm--find-all-completions (string table pred point
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 27 Oct 2023 17:06:57 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 27 13:06:57 2023 Received: from localhost ([127.0.0.1]:37010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qwQIT-00066t-1f for submit <at> debbugs.gnu.org; Fri, 27 Oct 2023 13:06:57 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:52299) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1qwQIP-00066b-6m for 47711 <at> debbugs.gnu.org; Fri, 27 Oct 2023 13:06:55 -0400 Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.nyi.internal (Postfix) with ESMTP id 6F55B5C0248; Fri, 27 Oct 2023 13:06:16 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Fri, 27 Oct 2023 13:06:16 -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= 1698426376; x=1698512776; bh=L6Iwc1Rwt2N+bYgCrKARi4fP7npiBmJau6X sKQi3mpE=; b=foTsF5EcuYcV1e5My5qhUf7/YQddsGsiOiWerhryRdRFTPZjOIZ iJCnezetdt7GBwTdloSjS7Kc/i5u6kuariOxDzPHKEIW+Vo1uXd/bf8j55dIbJ0N Jw0WtyqhHvqIjHIV0poNR5k4CC12A1F49pQ3E9amwjbmL9kSR56Yi3qHOy6k6qpz xwaqRpqmV6HFDt7gUkaWMjWO+Qhn7D9vJGR/cRvsAOtRj8nvBzSE9XmaxYtNU99D 39Nru05/694ssXPSYzjOPtSG9CRqjxXRFen3MjJyl4lQ7w7Wv5753GcvVDAUJVPi jMbuhgLrbNgwKqXex0E7XFlS+Gb020zxS2w== 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= 1698426376; x=1698512776; bh=L6Iwc1Rwt2N+bYgCrKARi4fP7npiBmJau6X sKQi3mpE=; b=st113GdfSLoBkAl6BupOlmqG+lgTNZTjhKNh/7t+UDtDk0NIgyi rbtY6OW03V6vVKyGnsITl0ui0kQvlGuRHf+GEa5AJ2VAju6FV4+MioNXzNBO/VD2 dYX2gj25qjQc6caOINGcSIefSDdpVluw+64ZgNeDAhxPOFGD3CVuy8D2EjhEVH3y LvnBy/GiVEf5rA6HqES9z27ECPKhzhtwWJlzY/2gvRDpq7xdfUE7hgXAeV39gM1Q 9Dr6MXWrw7432QEEZS5FjkDbJBR2shPrMJ+MRWTuU1xuwgNEtHn9+hU1uQlwccc/ t+7QzMNTiGpsZ5DG5NzJ632pjA698W9Lffg== X-ME-Sender: <xms:B-47ZQqHv0iWb1ibgKInMjDsWkMuZmLFNWbrZrLon-PKlRjEXMlxlQ> <xme:B-47ZWqXDX6oyYecgoA15xra6AmR6RJ3-jZoOe7u85jMlFtwTnGql5C34F_QsTEvD yVva2iYp6omn4I7A5w> X-ME-Received: <xmr:B-47ZVMM61oWVtI7HIRUp00Lztfg5peR_99PGBMaIginixuQhv--z2ZbZcDNqcc> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrleeggddutdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: <xmx:B-47ZX49jn4pibwjkHHqeG2oXGkXNXk7EFWFAr4tr7pSZCjhrodSRQ> <xmx:B-47Zf4mO95x7hui8t0a_HlzZXIfpKVxEoihRAQy1pqAF4h4Uj7Ltw> <xmx:B-47ZXhqRnuOkKOPSBMMCjElKZXrOBeNQ8yezThKW3Qa_3Mj4S1Qog> <xmx:CO47ZRmnNHHSAMX7yPNYU2EZ6hq5YwCbDiY52I1TjfcqeSfTxHUXww> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 27 Oct 2023 13:06:13 -0400 (EDT) Message-ID: <1504b2e4-42d9-5d7b-eaa2-c7b7d5ca02ba@HIDDEN> Date: Fri, 27 Oct 2023 20:06:11 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Content-Language: en-US To: Stefan Monnier <monnier@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <jwv5y2stc2f.fsf-monnier+emacs@HIDDEN> <bc621b6e-236a-736c-0723-0c17292ee5ee@HIDDEN> <jwvsf5wqc33.fsf-monnier+emacs@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <jwvsf5wqc33.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.2 (---) On 27/10/2023 19:19, Stefan Monnier wrote: >> We could, for example, have a period when we warn about returned >> non-matches. string-match-p is not free, but it's not very expensive either. > > The problem is that I dislike `completion-regexp-list` :-) When we do use it, we can avoid copying all the strings to a new list. Skipping consing this way can really move the needle at the level of optimization we're discussing now. > More seriously, since it's a dynbound variable it can have unwanted > effects in nested calls to `all/try-completions`, so it's safer to > ignore that variable because its binding is not always "meant for us" :-( I guess it would be more precise if it was a function argument, e.g. the first argument to 'fancy-all-completions' or somesuch that all completion tables are supposed to use inside. OTOH, I suppose that might hinder those that use external programs.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 27 Oct 2023 16:19:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 27 12:19:52 2023
Received: from localhost ([127.0.0.1]:36909 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qwPYq-0004VS-F6
for submit <at> debbugs.gnu.org; Fri, 27 Oct 2023 12:19:52 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7552)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qwPYl-0004Ut-GC
for 47711 <at> debbugs.gnu.org; Fri, 27 Oct 2023 12:19:47 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8C4F710013E;
Fri, 27 Oct 2023 12:19:06 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1698423545;
bh=A2vM1oYDTVF9mfzxrsubV/VtxUxn8wJ2KsQSmE3lO94=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=WdP7Q5dF+RNSG1lJyZRaShMZTCX0OfX/gUR4GrVr4U/K/dcAAl0adAwId0hbvvJHO
jAXSygyhr+yFfNNrBVH/oQtydMMemAmKLUKZi0coNs8Xpp7Dap8lCkCXqarvSMTPlS
gep2Vk+Y+t22cXCrK8olTR/u6gxKJ3Z0Vl/kyTmYOAJuKb6Tz99flwhqSP1Bcw3ij4
8gJs81gG9N7Baoi4IXtSpLkfFCgfattaa8OTpf1NgmK3v6ANmGuhj0+FLcIYiGI/Lb
uA4f6mO+D3ewzDB0HPByO938Rmt8FNmX2LF1Z7TgFvnr7JbSIkleJgYTPDJZtA0jfj
lvN1mxzkHO1xw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D57B910006B;
Fri, 27 Oct 2023 12:19:05 -0400 (EDT)
Received: from alfajor (unknown [23.233.149.155])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AE1D71202E6;
Fri, 27 Oct 2023 12:19:05 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Dmitry Gutov <dmitry@HIDDEN>
Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2]
Add new `completion-filter-completions` API and deferred highlighting
In-Reply-To: <bc621b6e-236a-736c-0723-0c17292ee5ee@HIDDEN> (Dmitry Gutov's
message of "Fri, 27 Oct 2023 18:41:34 +0300")
Message-ID: <jwvsf5wqc33.fsf-monnier+emacs@HIDDEN>
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN>
<fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN>
<3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN>
<CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN>
<56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN>
<CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN>
<328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN>
<83fsvcbio7.fsf@HIDDEN>
<9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN>
<877cnafv39.fsf@HIDDEN>
<9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN>
<CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN>
<7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN>
<CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN>
<5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN>
<jwv5y2stc2f.fsf-monnier+emacs@HIDDEN>
<bc621b6e-236a-736c-0723-0c17292ee5ee@HIDDEN>
Date: Fri, 27 Oct 2023 12:19:04 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.153 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47711
Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
=?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>,
47711 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> We could, for example, have a period when we warn about returned
> non-matches. string-match-p is not free, but it's not very expensive either.
The problem is that I dislike `completion-regexp-list` :-)
More seriously, since it's a dynbound variable it can have unwanted
effects in nested calls to `all/try-completions`, so it's safer to
ignore that variable because its binding is not always "meant for us" :-(
Stefan
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 27 Oct 2023 15:42:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 27 11:42:17 2023 Received: from localhost ([127.0.0.1]:36886 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qwOyX-0002i8-BF for submit <at> debbugs.gnu.org; Fri, 27 Oct 2023 11:42:17 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:60169) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1qwOyV-0002hh-DZ for 47711 <at> debbugs.gnu.org; Fri, 27 Oct 2023 11:42:16 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 855385C018A; Fri, 27 Oct 2023 11:41:38 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Fri, 27 Oct 2023 11:41:38 -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= 1698421298; x=1698507698; bh=OktNO0UgwmzqkT67Ko9pC7/Q3DYdXdbBrwF gkE9e8M0=; b=RzGomXAWXWy6X2ZEPKKoSrTD1iZIfzZ/f1oMN3KUw9mfWJYVDTQ rawOorTqnTp98c93oN315nnFhFMHpcXq9uI9VnVd7VY56N5k1SC8XmOaRx9ZpiAC BD5SWvaN34fwIFo4MnSEYMLDkv0ZkrnZYVxDsrdnt+MHdwhBNpaSz3sWwe16EZzp mqGqSvZoXk5tRnsz6C+4hroWxaJqt4PUBPWfzVDcG+YKfsx8XM+/UwAkgXcxCjle MCGFicQTODu1xBjkOXRTjjVsEqgAhnwCl4cMq//pU97LvfGJrgMqMZO2CbXkte9O He4gXKg5zsAvmUSfFEul4Jcf9sH1Qnv+Nog== 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= 1698421298; x=1698507698; bh=OktNO0UgwmzqkT67Ko9pC7/Q3DYdXdbBrwF gkE9e8M0=; b=r0f7zCyTbSqf8xGVzn3l6Q0r1D2C34wKa94SeALnaIo/4QeiFdz ekzZHCaONEBBModRxl6Rk4n7hMGXENG6ruLXRS9GKLGKH3e2SLw6QGylhjA1A1Fq uWVQn+dUAZ+hWLb8FYQMf9g+ia34n0GwqfqUwtOE5yjlnBPaRmdzlzMOm7wLsIIY 2j7MWU/lX4gC+GWjxauObhYL3qAMOLm2XbPSZEvNP0qP3no5H7F1NebT7N8AziTX 9SiIPMf7bVbegK8i8U9i6w5mBqbGgg1sDhf9w+8shvf0O062pkFvvBtKFKrF32SB 7sJrZpHhQmckQcbb19QgfBIl6s+gbX9DdZg== X-ME-Sender: <xms:Mto7ZSfXvt3d3e7D6M9zacCBTHrsevVborWCbCZ218jzgtl7Z0h_2w> <xme:Mto7ZcPBeFEnIRjn0aZzy3jlmw8AIMRml8pHz2DNJ9mKcarjWwuj7EWDaKio84Rwo LNvom4wESp1lTQzJWk> X-ME-Received: <xmr:Mto7ZTgKpN8NBRcZIQMulQ85YEQUVYA5RYFJrC4bxwwXeElB3TzsoDuWVXTHOU0> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrleeggdelfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeevledv veenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: <xmx:Mto7Zf8VitqvaGi_ehZA_PhUlcCq0Hr8qAbWdjFx604hlagTCX5L0A> <xmx:Mto7Zes75sFzY6k2NtsoVM5kdqIVJ-CAI93CJaMliWD-Ek2AiEyc8Q> <xmx:Mto7ZWFBZ_DXzfqs0nVO_SFhTpUcwL6Ov6wO8ZTm9rpoJ6o5WcpCZg> <xmx:Mto7ZSISmLYPl63Gq4ivw2UshmDklB5Bos6OgU8rk2AlzCVz4vPPGA> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 27 Oct 2023 11:41:36 -0400 (EDT) Message-ID: <bc621b6e-236a-736c-0723-0c17292ee5ee@HIDDEN> Date: Fri, 27 Oct 2023 18:41:34 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Content-Language: en-US To: Stefan Monnier <monnier@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> <jwv5y2stc2f.fsf-monnier+emacs@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <jwv5y2stc2f.fsf-monnier+emacs@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.2 (---) On 27/10/2023 16:46, Stefan Monnier wrote: >> BTW, all-completion's docstring also says that a COLLECTION that is >> a function should itself handle completion-regexp-list, > The key here is "should": we know how well ELisp coders follow > such recommendations. We could, for example, have a period when we warn about returned non-matches. string-match-p is not free, but it's not very expensive either. I think we should fix the discrepancy between the doc and the behavior, one way or another. If the function does obey the current phrasing, it seems like it's doing extra work if we post-filter anyway, producing extra cosing (though the result might still be beneficial if that filtering results in a much smaller list on the first try). But third-party callers of all-completions might also see the doc and decide to use completion-regexp-list, with mixed results. That seems like a pure downside.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 27 Oct 2023 13:47:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 27 09:47:38 2023
Received: from localhost ([127.0.0.1]:35382 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qwNBZ-0004bo-Rl
for submit <at> debbugs.gnu.org; Fri, 27 Oct 2023 09:47:38 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:50716)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qwNBX-0004bY-8j
for 47711 <at> debbugs.gnu.org; Fri, 27 Oct 2023 09:47:37 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 592618024B;
Fri, 27 Oct 2023 09:46:58 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1698414413;
bh=kSIC4hnWWFVwYZb/9izA6jMu9TwhO1JDGKh2vvueJ38=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=db+ZBxU6javjXClyV/xZDJxwjffXLaiN3VkbDcSwNE+pTkd6w2XNuTA5Ag1dRfhhP
xZUtsyEiZ2V3+IOCpV/GNoPXBmHriD+Ypl6yelGbmHA11pskLqKOKh9Kgr/5lhCqMF
I+IeI7zf1bMrLV7hGfmzDMRqjgZP2GhpkkOujkybTRSlFxif1wEaSMan9tx9mtRC7b
ZnWk+HVY2S0Ioe2iCQquw5mVVINCEgaAVA/xV2DLGe/8VHXQ8SZyvmgN0SetDsdH9V
jXUW6jFREn+mqLaUPuQUziTOVL6HzfbBGBLnwPNq6vWnTh4FXqI+fZYhnFsIPIcJq2
CYw7hMpImNg3Q==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7BE1080283;
Fri, 27 Oct 2023 09:46:53 -0400 (EDT)
Received: from pastel (unknown [45.72.195.71])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4909A1201F9;
Fri, 27 Oct 2023 09:46:53 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Dmitry Gutov <dmitry@HIDDEN>
Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2]
Add new `completion-filter-completions` API and deferred highlighting
In-Reply-To: <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN> (Dmitry Gutov's
message of "Fri, 27 Oct 2023 16:29:03 +0300")
Message-ID: <jwv5y2stc2f.fsf-monnier+emacs@HIDDEN>
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN>
<fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN>
<3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN>
<CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN>
<56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN>
<CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN>
<328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN>
<83fsvcbio7.fsf@HIDDEN>
<9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN>
<877cnafv39.fsf@HIDDEN>
<9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN>
<CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN>
<7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN>
<CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN>
<5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN>
Date: Fri, 27 Oct 2023 09:46:47 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.000 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47711
Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
=?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>,
47711 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> BTW, all-completion's docstring also says that a COLLECTION that is
> a function should itself handle completion-regexp-list,
The key here is "should": we know how well ELisp coders follow
such recommendations.
Stefan
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 27 Oct 2023 13:29:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 27 09:29:46 2023
Received: from localhost ([127.0.0.1]:35354 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qwMuI-00048y-FD
for submit <at> debbugs.gnu.org; Fri, 27 Oct 2023 09:29:46 -0400
Received: from out1-smtp.messagingengine.com ([66.111.4.25]:37515)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <dmitry@HIDDEN>) id 1qwMuG-00048l-3O
for 47711 <at> debbugs.gnu.org; Fri, 27 Oct 2023 09:29:45 -0400
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)
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: <xms:Irs7ZTbT-GOHOJyKoR8JZ_DY1xQozX-EDoifRp7VnT4WaAJNl2Ik5Q>
<xme:Irs7ZSaOcvBXYsMDejVvr4p1p4CGqyWZSz7vC-VLiXkmIETPKPVDLW5N8fiN2KvDM
4RauH6KnSgorHeb18M>
X-ME-Received: <xmr:Irs7ZV8C5UL6v4IO-orSUB3T41iCvK_8IhzCsY4Jk6qApa_dO6_ZDSlwDa7Wknw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrleeggdeihecutefuodetggdotefrodftvf
curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
fjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepffhmihht
rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth
gvrhhnpefhffehleejffegffeugefhkeektdffgfehjedvgeejtedtudehueffgffgfeej
heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh
hithhrhiesghhuthhovhdruggvvh
X-ME-Proxy: <xmx:Irs7ZZrIGhJnvc8wxP6dWq7hqkBxpmdueYpOBHXUccH-J4RXow4ClA>
<xmx:Irs7ZeqJ3Xt2Y50M2Yi7l9ZQkLmoiVSUecKusWs32VpGSDTnwcZUXQ>
<xmx:Irs7ZfSQ2lecsMTS9l8Ee_Fzxb41xtfZsHJE_gmWLbevW06kQn7TWw>
<xmx:I7s7ZRWhIHiBGm-CcaBV6jM41v3XrJfxhlhMP0YD3eEWkBG3bfXGNw>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
27 Oct 2023 09:29:05 -0400 (EDT)
Message-ID: <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@HIDDEN>
Date: Fri, 27 Oct 2023 16:29:03 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.13.0
Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add
new `completion-filter-completions` API and deferred highlighting
Content-Language: en-US
To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN>
<fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN>
<3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN>
<CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN>
<56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN>
<CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN>
<328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN>
<9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN>
<9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN>
<CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN>
<7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN>
<CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN>
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.2 (--)
X-Debbugs-Envelope-To: 47711
Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.2 (---)
On 27/10/2023 03:26, João Távora wrote:
> On Fri, Oct 27, 2023 at 1:11 AM Dmitry Gutov <dmitry@HIDDEN> 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.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 27 Oct 2023 00:24:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 26 20:24:45 2023 Received: from localhost ([127.0.0.1]:34725 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qwAea-0003JI-W2 for submit <at> debbugs.gnu.org; Thu, 26 Oct 2023 20:24:45 -0400 Received: from mail-lf1-x135.google.com ([2a00:1450:4864:20::135]:50653) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1qwAeX-0003J2-KK for 47711 <at> debbugs.gnu.org; Thu, 26 Oct 2023 20:24:43 -0400 Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-507975d34e8so2243108e87.1 for <47711 <at> debbugs.gnu.org>; Thu, 26 Oct 2023 17:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698366244; x=1698971044; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=6B+9ct1bOwgGHU53YyqLbL7bySOn4Xu3pXucbt30a+8=; b=S3Fu0+tz03zlTM9erttfyF3/RWYcnUsXv6zjdLe8/c0BPXsVQrfot5z2i/nNQm08So kXUsHWnk3TP8l3EGiqTeBc5OCAIV0lnqOfvTsldlaBD6OkC2tdKDZG+4Fiz+5rwC3ijb +jbRum+52dPqQosqA6xrwzSxJgExmCv4DR+Tb3txp8B2iHBCX5kkm8QlXVQEK/paJ7u/ QHkFnV0asysuiWVdRRMypD/i/9fj9xzUvLSxOfhr2CfJYkBEqqlLmBenTwR78matqw2j 5r0/xsxhN7RFd5HkGQr208btKIpOIfipn/bMX4XG7hi0GIehoSMl9JyC9GWDjBJTTzaz ckCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698366244; x=1698971044; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=6B+9ct1bOwgGHU53YyqLbL7bySOn4Xu3pXucbt30a+8=; b=tMzbHFJhbbHUZP33Bid3VquNrrWKZJyP7NsvdqComdwShT0umRyxTiDtYOPSjlHk5C UwFXNj1SWZQF4SfH2hM5zzwLxlrfQBydpKUuxPD1dplx3vAt6cQNl6f5lbQdixHSoRrJ uAikbApj8pzK3yoy+XZwwmN3yM6AubJ5CdXEz6VZ4Uwb9YimEIAk0FKvMDZjPelmAOdb +NJhlt8OQexbfEB6HVXkGOPb7FLnXVC8iyRTZfpaYg5TcGXYkJPFGYjX+cdLjOI901aa qI1PWpaGETxYVwWvCuH9PYuJWDTRaOwrqkqkYc7PbG5BM1blkxcZQgMsUl8Q9iDLpgZM gdLw== X-Gm-Message-State: AOJu0Yxifk9sAB3N3AsfjBaqNN/ONLNWLcIhzkpX8+XW/3iMJFD/XcEn bQNO2JGRR4lLkVKIefvrnuENOE2CsgCnitp14/w= X-Google-Smtp-Source: AGHT+IE0xmovwkUk9atmcHWMmcVNFj6TvFdbBvqBNF9cM2JVc53kO+1Oop1FTUc3y26WKrKDEgCbcFydTy2+CK1QEuo= X-Received: by 2002:a19:ae08:0:b0:507:a58d:24ba with SMTP id f8-20020a19ae08000000b00507a58d24bamr625891lfc.63.1698366244291; Thu, 26 Oct 2023 17:24:04 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> In-Reply-To: <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Fri, 27 Oct 2023 01:26:53 +0100 Message-ID: <CALDnm52orHVT4gNEu7xvtMoWT9JA9H3nL_P+2k=5rbEGDC_Jvw@HIDDEN> Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Dmitry Gutov <dmitry@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Fri, Oct 27, 2023 at 1:11=E2=80=AFAM Dmitry Gutov <dmitry@HIDDEN> wro= te: > > 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. 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. 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. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 27 Oct 2023 00:12:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 26 20:12:36 2023 Received: from localhost ([127.0.0.1]:34717 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qwASp-0002yt-VU for submit <at> debbugs.gnu.org; Thu, 26 Oct 2023 20:12:36 -0400 Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]:49334) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1qwASn-0002yP-B7 for 47711 <at> debbugs.gnu.org; Thu, 26 Oct 2023 20:12:34 -0400 Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-5079f9675c6so2346218e87.2 for <47711 <at> debbugs.gnu.org>; Thu, 26 Oct 2023 17:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698365516; x=1698970316; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=BzVrKqNAPvvqpX8ztcoc33GsTE11idx+mOgyNMgHYvU=; b=hqe0qzFgH9jfTWCy60VlPc5y+Z0NeJ2r5Z3QIEL/4tvjPSAs6DjgQv9KoTd4to8JWm XTjgjOfQaf8qcU5eE2k8/z4uEVPJFib6eyFCy9G/JXx2VgZlZIXKkfNJJkltzt+vEAxT f0TRujmnLE2CFwiOsonVPiKd+whmCd1nCp6dF5G5y1ZskhVGM+pLKBNbNvugS2EV046/ M0hcT20d73NTdK97vqokW98ypFpPmZshbZnP2fbJfCg8JQgdkGPsXUm84QR2uB4JBE2U dB/jZujx8g/A2TYsjwIsodYTbThCJqqsReLX+tlgtOhi8+w0yU8CPivbA54EXaw31BC6 HdSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698365516; x=1698970316; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BzVrKqNAPvvqpX8ztcoc33GsTE11idx+mOgyNMgHYvU=; b=iqF9Zq7RFw3fTZlP0SV3E2nAClTQULYmEJoTiBXTcQme5XyreFmsRqcZ4h42Hq3olg a9DQU7t994ZpgmsORV18Kc7P146HX/R0Mp5KckRoyvPDj3Ec4D2nkMfvNKV3byPvfaKh aWcYR4O01ppQWt2i+l0peHsQFuY9Z6zIKkluM+1s2SbfDxss/ILCaLh7wVzXNnbkNxzS 9471JSobZV0Ly3uNTDt1JC6g+s79yjW+En1gXHqZi9Lb2IBua9Q7JeHvyayPR+WzGHPY c4x+lsdnft3HuDurjPwRSv8Gepec0LXwGAVCGJ5bn/URcsB1xdtBT3s9Iyzq4XmdZZHc W6jQ== X-Gm-Message-State: AOJu0YxPpfVn+z21V6yGWzr+TAmaZQQ0qbdLj4sWfJXh3XYcrSyYht7g 5QHISquHxHwO+ASyOWCNtpO//Rr+D7d3VPRtGGs= X-Google-Smtp-Source: AGHT+IGSw68FJ+5lK809Lje7jL72GPCY5js2fdgX9osjH98igIUjw0h5WrwFslR6JE+odWfmXjhW7SOoajXSQhlbybE= X-Received: by 2002:a05:6512:124f:b0:500:7fc1:414b with SMTP id fb15-20020a056512124f00b005007fc1414bmr706286lfb.25.1698365515957; Thu, 26 Oct 2023 17:11:55 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> In-Reply-To: <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Fri, 27 Oct 2023 01:14:45 +0100 Message-ID: <CALDnm50nk4PXQCnAUYHn6_PeN1SWuZPAjmErDR=_eX+MNUp9Fg@HIDDEN> Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Dmitry Gutov <dmitry@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Fri, Oct 27, 2023 at 12:44=E2=80=AFAM Jo=C3=A3o T=C3=A1vora <joaotavora@= gmail.com> wrote: > > It is slower in the sorting step, though: mostly due to the extra > > consing created with the alist to-be-sorted, I guess, but also because > > of the repeated string-match call (which, while fast and much faster > > than the match-data call, is still not free). > > And is the sorting step not included in the full call to > completion-filter-completions? I don't fully understand how it works. I get it now. Neither completion-sorted-completions or completion-all-completions do the sorting. It's just that if sorting is bound to be required, completion-all-completions will do most of the work upfront, and thus sorting will be much faster in that case, compensating completely. So now I don't think that micro-benchmark is of much use. A useful such benchmark would have to be representative of the full cycle. Maybe we don't even need this benchmark, given the instrumentation in icomplete.el works well and seems precise and deterministic (just not as convenient to run). Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 27 Oct 2023 00:12:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 26 20:12:31 2023 Received: from localhost ([127.0.0.1]:34714 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qwASl-0002yZ-Hk for submit <at> debbugs.gnu.org; Thu, 26 Oct 2023 20:12:31 -0400 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:43487) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1qwASj-0002yK-1k for 47711 <at> debbugs.gnu.org; Thu, 26 Oct 2023 20:12:29 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 04B513200F81; Thu, 26 Oct 2023 20:11:50 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 26 Oct 2023 20:11:51 -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= 1698365510; x=1698451910; bh=e4ciEwM+d9fKknttNQFwU+jyKKNKmGCJUBd Lt/cGocc=; b=e5oIo8aSy7N6IBab0BneojytWxpHeuS6hhCmqME+44KENVgdEf9 SK7UgG9XKAMPR8dIuP8d/U8+KKymEpZyxGPk8JU+YFM7YJ6WCgRJeBEnVbY2QZDt fN+7CrkbM7f1Tyr9EAIPs5KZLbCwI593Q7KLIHUe9wyZ92sGE61G5kWzUEzHnZzY fc8DI+1HXSq6C5ytFAArw+nfIuiOm/FmQg5HeLLFMkbIv5FXBFop54MWEqcWavTP HePKIYgTd8rmbXh0z19Te1Hdd8sMpvODDUePsslT8WR7cSfc81qPLD0ZCo8b7nl2 jABYtaabiAVHVDjfZG0Fzeoz9Tw/fhA6aeg== 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= 1698365510; x=1698451910; bh=e4ciEwM+d9fKknttNQFwU+jyKKNKmGCJUBd Lt/cGocc=; b=fYociYSpyPVzhY7UGHGgYuQLT/qgQRj8piapYCEL15E7eYR3D+f cYJ+orD+sn/4wguKtkWJ2wDmeeHgiaRF0uFUXlGqMJN75VYwy88F0acgRTYL+AyT cGoCk1u/ZOl2+/XrmD+Wnu7yOZpcukV14SqfZaetbFZafMBIH9xZa2/bw0rYoYBf 6aK5s+Wbbe8Csg6NkVODF1bvCXCgsXujMV4Xp0bGQDhttwQ58QLJZWNkoPmyE9/c fZB6egw0cXa5VLi1bpqB6LAxDuh149U2LqGsOmuDp3udIiD9BKfeLt8X4Xs8lBgp WrpMW5vzW30atKl8GKynnQ3/twV3biVlkjw== X-ME-Sender: <xms:RgA7ZYhIGUwIrAFC3A0QNBDvtAc-brYP8xHEgGQv-Cwn9N1n7YFBGQ> <xme:RgA7ZRAuRDOmPFvG9D_U-VBq9QoM1DoV6Za_jNrGAaPHnhONuob5SZfsKsvU0vbQG w7QklFWPNAb92GsykE> X-ME-Received: <xmr:RgA7ZQFVimPU1hsZvidcVeOzzxUycLp9QzU_a37gwnXeC9qrZWDMdZ7mqgaEzV0> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrleefgdefvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpefhffehleejffegffeugefhkeektdffgfehjedvgeejtedtudehueffgffgfeej heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: <xmx:RgA7ZZSDFCpkcjhFupnmlakOkeNhrP1XyNv64AI9oeFU-H2RqVBT-w> <xmx:RgA7ZVzCpjl33ISBTC0dKWgd5yFcvwY4PUJdwTyHlhkU4CoOthcY9w> <xmx:RgA7ZX4FVtQOH_8T2Kq_WaU8HnoWNpovLOkzEBXE_BuBQjCM0R_NNQ> <xmx:RgA7Zd9cXr8OA4Ezj2KsNAYtN2Pl8tm2G9NFdqfU87K6sbCY4YaL4A> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 26 Oct 2023 20:11:48 -0400 (EDT) Message-ID: <7d14bc13-4419-816c-5708-c42988c39c02@HIDDEN> Date: Fri, 27 Oct 2023 03:11:46 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.2 (---) On 27/10/2023 02:44, João Távora wrote: >> It is slower in the sorting step, though: mostly due to the extra >> consing created with the alist to-be-sorted, I guess, but also because >> of the repeated string-match call (which, while fast and much faster >> than the match-data call, is still not free). > And is the sorting step not included in the full call to > completion-filter-completions? I don't fully understand how it works. It recomputes all the scores inside the display-sort-function. >> That's how when compared in practice using fido-vertical-mode the >> results were about the same. > But that's what matters right? Pretty much, yes. Except for some potential exotic cases where the UI or the user would want to override the sorting logic. Corfu and Vertico have such capability, but I'm not sure if it's used often. > 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.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 26 Oct 2023 23:50:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 26 19:50:06 2023 Received: from localhost ([127.0.0.1]:34701 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qwA74-0002Px-0j for submit <at> debbugs.gnu.org; Thu, 26 Oct 2023 19:50:06 -0400 Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]:59878) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1qwA6r-0002Oo-Ev for 47711 <at> debbugs.gnu.org; Thu, 26 Oct 2023 19:49:54 -0400 Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-507adc3381cso2208870e87.3 for <47711 <at> debbugs.gnu.org>; Thu, 26 Oct 2023 16:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698364156; x=1698968956; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=q/KZMNRS24o04AwjPPPYHDQomX9rImjXc+1Hk+DQtVs=; b=LLPk0NER+zbLGv20qLkH19MIghAeLSxwVUqZD2W4OeDXwugk2kyJ/n7DnMrH/Da+eh fogCQXRx6fVbZ49L2D+xKNQpdGHrxpD1x7BOPyOsyXSWbfJ/sm22Erip3LdxtG7zoBdN E6kp5MOwQ/+HdqUm1wtLM51wY7SMMiZI9vD0lhMp29/+5RpfwGcrbQBfhoajBZGpfQoE IgGJgAlSTYrEL+nOSoWUD7Ec+rID8BdzouCdC72/bAhg+EVVL/JTJm/cGHxwnQcf9kkA zIx+NSXcy/srJnaxRxfMqs2s1bkfoYHKXWZ4ezCpWYdNdvu3hQKe1W/67MQGD02QBb6Q SfKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698364156; x=1698968956; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=q/KZMNRS24o04AwjPPPYHDQomX9rImjXc+1Hk+DQtVs=; b=H9krQR/WBU/HW1HUDy33wvujOrBd53yShuDL5DZjOroXVWb5rwHIG5W/gOhgc77dzf nFY+h5rv4ixLJNryQGZRgCWxtaWSXRqAIGuRLXoGl++6PxI5Nr1gL+IFgN4WvjdM+X2r GpXp5jVkkqbLeO8zmKG4nU+PrGWU0TqCN1FeAJ1p8HwR6RnPyqjIkdZkGOQRFB03Q6fE /FtFB7CrKEeixjUU7un9oqjlsvtVZ8A7UDvsixpQAi0GMUPUrdC60IDZ2Oc4uP3JANiT mbHDUju24SWyebRotz1qXOULj2AcXQBjwtgI62fyDTFkY/aqM5ZbLKVvhG4Qpla2CRBC JOdw== X-Gm-Message-State: AOJu0Yw7WryLG7LP9E8oB/UuIbrHZehRKF123CkisFUAfGl9RkSrCzTv A6eSNUbQszMN+OFCF8vNm6TuAqdLoRcQAjmr8jo= X-Google-Smtp-Source: AGHT+IHRapnXKZSr87ikToJEEYUSwHvjgqWnDmzYWYfXlyq1RWwONyfLFMNPhPLsOGYIlIdOFooO4mf6uE8xEq9+8t0= X-Received: by 2002:ac2:4adc:0:b0:500:7685:83d with SMTP id m28-20020ac24adc000000b005007685083dmr519005lfp.48.1698364156314; Thu, 26 Oct 2023 16:49:16 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <jwv34xyk1dp.fsf-monnier+emacs@HIDDEN> <CALDnm52VJpM5L_NaCJz6vcJgH4XH4HgpFBChY4Tn-JuQpGC55g@HIDDEN> <8734xy73n7.fsf@HIDDEN> <87zg05awbw.fsf@HIDDEN> <2703531c-333f-c4a1-837b-c151ef3fd57d@HIDDEN> <87v8atarsf.fsf@HIDDEN> <785a64d1-80cd-571f-126b-594ba69f2e56@HIDDEN> In-Reply-To: <785a64d1-80cd-571f-126b-594ba69f2e56@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Fri, 27 Oct 2023 00:52:06 +0100 Message-ID: <CALDnm506soeMSDU8xGidoJ2X3XFMd+6JzNXsVBK0Vs1QFfXWpg@HIDDEN> Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Dmitry Gutov <dmitry@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Fri, Oct 27, 2023 at 12:35=E2=80=AFAM Dmitry Gutov <dmitry@HIDDEN> wr= ote: > > On 27/10/2023 02:27, Jo=C3=A3o T=C3=A1vora wrote: > > Dmitry Gutov<dmitry@HIDDEN> writes: > > > >> My understanding is it's due to the judicious call (copy-sequence > >> orig) that you added before 'put-text-property' is called. While it > >> seems like a good idea to preserve the original value, when almost all > >> of obarray matches the current input (which is the current scenario), > >> a lot of strings will be copied. > > You're right, I reproduced the regression. I thought I had taken out > > the copy-sequence, but forgot it there. In an earlier stage I suspecte= d > > that I needed the copy, but I don't think I do. Please try this new > > patch that removes it. I've also pushed it to the > > feature/completion-lazy-hilit branch. > > Yep, without copy-sequence the regression is gone. Now the input strings > are routinely mutated, though. ;-( Not sure what you mean by mutated, the strings look fine to me, does this make any visible problem? I couldn't detect it. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 26 Oct 2023 23:42:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 26 19:42:35 2023 Received: from localhost ([127.0.0.1]:34692 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qw9zl-00028P-RX for submit <at> debbugs.gnu.org; Thu, 26 Oct 2023 19:42:35 -0400 Received: from mail-lf1-x12e.google.com ([2a00:1450:4864:20::12e]:49561) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1qw9zV-00027r-Ti for 47711 <at> debbugs.gnu.org; Thu, 26 Oct 2023 19:42:33 -0400 Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-507973f3b65so2318933e87.3 for <47711 <at> debbugs.gnu.org>; Thu, 26 Oct 2023 16:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698363701; x=1698968501; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=wbZzpP8thL5Wk6dNJ8DGbP2ctAPz2XZTQIVB28HoBL4=; b=Kx3g/W6KvZixB9GFeekA1Q6oUCSKqO8OBgyCd4Pfjmy7+EdpuOReSL/Gh1nbfluvyB 93iwbVT9+srZe2rfoXpx6yC3HvXpAyANZsKl2w+dj+PdOtlhH2uASvoowUASbx9x5LWq AMKMue8Lb9lPxZgEt/WBYAh3HLii3kOeVr92LCbX1CuHqJW7lBjS76nqyTCqIoRz5m5T y/WxTRY4w/4i7rZlfQ2Uv6mDVnEg5xChUflkf7+OZBFox76cVy7BzzKr2wWppNVBlvNd UigwFtshN66TIkdiqEyxkbLKqvqWd4jlXXssipu19ixPzynoRSTw3Q/ogvwaUmymzq7v dkZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698363701; x=1698968501; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wbZzpP8thL5Wk6dNJ8DGbP2ctAPz2XZTQIVB28HoBL4=; b=YIld245BhGuJSeaG4//ucxpTd5yHo0JZzj8T+0A6px/sFItrYPncjhOyAlIwRjU/b9 gKiDlDzzijZm5EYxz7/qHwvMB6B+cR7cDnAA14/LpTJPKsrWetlkHtzeopgFdzXQf/BB wrRLREwy+/i2ro7F+HXa9BUoCaz4qJtRV7tcH+qD3oJhCY68N0ao55l0g21B/Lr2diOS Y3cXKRHR8FU4bQSqkJZjStTKxlYU/Swi8Widjej7yq1El0Kbl1IiS3ZcCCofphpGAnR4 DeOzkG+SgYF3RMxU9hMhhWGMNJuvaoKVHnkLUNplHQvaD5l7KRPQfCvXUcsj8etMRhSn 1zJw== X-Gm-Message-State: AOJu0YxOz/YtsbKIbHuz3BkrZjOCSj71TnDJ4MaUGvlu/aLDAowgi8dV U5B+y10PqIk63ECOoLGYmKa5eKNd1dmCkbYsu9E= X-Google-Smtp-Source: AGHT+IFQ/VCxnY+/umizpeU0Q1ONBXViGD+xbss6XohTerqPqlc0aQQt/XifONu6gyhD9qGsVHfedMRbYLrbketLWpw= X-Received: by 2002:a05:6512:4024:b0:4fe:49d:6ae2 with SMTP id br36-20020a056512402400b004fe049d6ae2mr856804lfb.0.1698363700513; Thu, 26 Oct 2023 16:41:40 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> In-Reply-To: <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Fri, 27 Oct 2023 00:44:30 +0100 Message-ID: <CALDnm53zb9Md8mSW4958N+bHPSg_Kkz4CM29ykB-YrHwVCun=w@HIDDEN> Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Dmitry Gutov <dmitry@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Fri, Oct 27, 2023 at 12:25=E2=80=AFAM Dmitry Gutov <dmitry@HIDDEN> wr= ote: > > On 25/10/2023 20:52, Jo=C3=A3o T=C3=A1vora wrote: > > And make sure to put 300 000 symbols in the obarray. The symbols are > > prefixed "yoyo" deliberately. > > > > (cl-loop repeat 300000 do (intern (symbol-name (gensym "yoyo")))) > > > > First a micro-benchmark: > > > > ;; Daniel's patch worked by Dmitry (v3) > > (benchmark-run 50 > > (let ((completion-styles '(flex))) > > (completion-filter-completions "" obarray 'fboundp 0 nil) > > (completion-filter-completions "yo" obarray 'fboundp 0 nil) > > (completion-filter-completions "yoo" obarray 'fboundp 0 nil) > > ));; =3D> (12.192422429999999 3 0.107881004) > > > > > > ;; lazy-hilit v4 patch attached in this email > > (benchmark-run 50 > > (let ((completion-styles '(flex)) > > (completion-lazy-hilit (cl-gensym))) > > (completion-all-completions "" obarray 'fboundp 0 nil) > > (completion-all-completions "yo" obarray 'fboundp 0 nil) > > (completion-all-completions "yoo" obarray 'fboundp 0 nil) > > ));; =3D> (12.267915333 4 0.14799709099999991) > > Note on this particular test: > > The loop on the first line only creates the symbols in the obarray, but > not functions. As a result, all the completion-all-completions calls > return nil because of the 'fboundp' predicate. When you change the > predicate argument to nil, these timings change considerably (so it's > wiser to reduce the number of repetitions to 1 or 5 at most), with > completion-filter-completions being ~2.5x faster than the other. Right, I missed this. I can reproduce it, though only around 2.0x faster h= ere. > It is slower in the sorting step, though: mostly due to the extra > consing created with the alist to-be-sorted, I guess, but also because > of the repeated string-match call (which, while fast and much faster > than the match-data call, is still not free). And is the sorting step not included in the full call to completion-filter-completions? I don't fully understand how it works. > That's how when compared in practice using fido-vertical-mode the > results were about the same. But that's what matters right? Also in the last iteration of the "yoyo" fido-vertical-mode test, results with my latest patch are quite a bit faster. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 26 Oct 2023 23:36:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 26 19:36:21 2023 Received: from localhost ([127.0.0.1]:34688 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qw9tk-0001yj-W2 for submit <at> debbugs.gnu.org; Thu, 26 Oct 2023 19:36:21 -0400 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:34251) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1qw9te-0001yQ-6u for 47711 <at> debbugs.gnu.org; Thu, 26 Oct 2023 19:36:18 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 2C05332016EF; Thu, 26 Oct 2023 19:35:37 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 26 Oct 2023 19:35:37 -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= 1698363336; x=1698449736; bh=bKE1bd2AyVhq9ECl/+D3H3r2cgqPajzlth/ O+3vmxfM=; b=SiBXOFLlMNefOdv/a5ddNZHXEGUK45nYlegHKYwRoz2SBDhz6xc oWmxFnXcRyv0xQL1cliG5BtwLvINha0Z/4+Vl8EEcuympB5AUNixdCHnnD427xn8 /fzjPXw7Apyx8zj4XdS9jloWpSwXsEapBDLngKehYfODIHKhsxuj62WXbLf/tEx0 zKB40blbHVtM8EZM8/z6WZYTQGWcUgKFearBUPmpND/sqmsZWouNgub2T3WugIf4 Hd2M3Zu2EU6rHV9AVwmb5BUMzi1EQfpn0IU4bry6VVav8DPH88nzskb7hJtLy8Rr h84QS0Idn6XnxKqhu6JkrQSHycD/JSZc70w== 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= 1698363336; x=1698449736; bh=bKE1bd2AyVhq9ECl/+D3H3r2cgqPajzlth/ O+3vmxfM=; b=G2XoutyjL9Xl6JT52HFay051LkqmX9wQvNgsRK+8XlRFNMn7vMv 8qolfe2/VDDWQZTQV+1wxMyFhgtG7KmRgpPuj68PkBNHBswIgDgQP/mV6g/QJrBi 47PB2WbtogKzwBiB1x2RDXUQ2Yr/513OVvK6YX2Qx7PL01zFM/jPCxch/Wh1i5wV 5LIKQ1lc7uZ4W4y/OJ4IVc34dWY18LOa2esPh+uIm9dvxmnXTtJAV2OaPIbOU9V3 xso2BbRQEaSPgwWTm3C2pF+Xr4Pu+mRQ19NO2sVULvz0s2zsiHy9AZaUVIdA74Lo Wfk6QTJxo+Vo/kPYoFL0xPpucrG5HdHn0Iw== X-ME-Sender: <xms:yPc6ZT90_zq-zW-PhNFn3_1sdOs241NwDliUFHW8IU-XMJuFNcDweA> <xme:yPc6Zfs0P7V4E1jvCahhBDwqVIR_5zjzJ3aCsgSrS9Dbq1AaclONvVrpEfGU0JUe8 Sbp62YrMuNKxOsZIHw> X-ME-Received: <xmr:yPc6ZRBpR27-MWQNOyBmWIokFe7jIjPpK9lEWljx7hrE73kX0m9gl9DOeV1x4Jo> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrleefgddvgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpefhffehleejffegffeugefhkeektdffgfehjedvgeejtedtudehueffgffgfeej heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: <xmx:yPc6ZfeHbxxtYAsfKETL0oQIzj8CI22O7DcJ1xWJiggv5_O6XNp_KA> <xmx:yPc6ZYOSnBWOsWKKgqjQ4RoRSne9Z2qWfkml7NLH9CwhfpPvft2HXg> <xmx:yPc6ZRmw9gqNoI-C8Q6ASJGxLkw0rHnVdKEyF9E-vJCUkt8erp_mMw> <xmx:yPc6ZdqfcYEnHv_OfVKS2fCAybiUpekUYEjdks-yKKqOqHD7DVCnlg> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 26 Oct 2023 19:35:35 -0400 (EDT) Message-ID: <785a64d1-80cd-571f-126b-594ba69f2e56@HIDDEN> Date: Fri, 27 Oct 2023 02:35:33 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <jwv34xyk1dp.fsf-monnier+emacs@HIDDEN> <CALDnm52VJpM5L_NaCJz6vcJgH4XH4HgpFBChY4Tn-JuQpGC55g@HIDDEN> <8734xy73n7.fsf@HIDDEN> <87zg05awbw.fsf@HIDDEN> <2703531c-333f-c4a1-837b-c151ef3fd57d@HIDDEN> <87v8atarsf.fsf@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <87v8atarsf.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.2 (---) On 27/10/2023 02:27, João Távora wrote: > Dmitry Gutov<dmitry@HIDDEN> writes: > >> My understanding is it's due to the judicious call (copy-sequence >> orig) that you added before 'put-text-property' is called. While it >> seems like a good idea to preserve the original value, when almost all >> of obarray matches the current input (which is the current scenario), >> a lot of strings will be copied. > You're right, I reproduced the regression. I thought I had taken out > the copy-sequence, but forgot it there. In an earlier stage I suspected > that I needed the copy, but I don't think I do. Please try this new > patch that removes it. I've also pushed it to the > feature/completion-lazy-hilit branch. Yep, without copy-sequence the regression is gone. Now the input strings are routinely mutated, though. ;-( You could do a copy a little later -- after the match succeeds and the score is computed. But for short widely-matching inputs like 'a' that would make little difference. I also experimented with hash-tables for "external" score storage. But it still comes out a little slower than either of the proposed solutions.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 26 Oct 2023 23:26:09 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 26 19:26:09 2023 Received: from localhost ([127.0.0.1]:34682 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qw9js-0001if-PF for submit <at> debbugs.gnu.org; Thu, 26 Oct 2023 19:26:09 -0400 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:35319) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1qw9jq-0001i2-6s for 47711 <at> debbugs.gnu.org; Thu, 26 Oct 2023 19:26:07 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 2EE383201541; Thu, 26 Oct 2023 19:25:29 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Thu, 26 Oct 2023 19:25:29 -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= 1698362728; x=1698449128; bh=nfYjkDQr9InYu2ZSnMZaVycFGWxe0fiRFsS XVbDazFM=; b=B9y7PGCBb2P6HAAVnAaImUe1/I78DourGqkxNFb2N8jKLlJWTUY INFOmbZskTGIu0jQ6aKEEFyD50iWxXSL50u3eKWkyerBq9ykCtUxb9NxKLjZdjZD z5AAE7x3l2kgrOSDv2/JKigSVXJjSIMaP2msl8dUrN54gA6p0SGrmv/RDjXgJiqL OWYti8CplD0PBUMijat8gxzK5BoGJiAfheMUyh5z/8ogIgYzdT3SE2p1UUcATBdK qUJAqTPi+RxHkyqde4BSc8lLX51s8SeotGbhBDZ5D04DG+FVGcO/8b+XVsTc0ObB yBYk/hrQ0JHlS9s/7F57ZSCvLcWlJAxMGoA== 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= 1698362728; x=1698449128; bh=nfYjkDQr9InYu2ZSnMZaVycFGWxe0fiRFsS XVbDazFM=; b=Uktki9Ku0b1BCRZ6V5/NEozC4bKv4U7lXJKeRnt5JfU6VtfNkom JAdwQeNWMUFNAuSBtcKrwoZsqSp8RzkgukV21G4B/a4Kf4CyQS87X/RZ0LQLRtJv JJ6UBfUg1QNJ5eFAnLjxh6jiF0qFY0sqQ0svi59CDrcX3nkkBW8H7gZ26nDjmFNA JLy9fkEhWHEfRhvyo9VrTbKQtTCNOXljIA855ilKhK5Udm+90VNTRREBCCBMAAfE u7VhtawbaXaXHEOf05jBSvXS8i/QK/dvFAXCa+YArEbqhBunDpPYD+IRfqSWi3Ti EmMyx/di/t3ou7s4KbEJMsC+h7dpOvWpEIA== X-ME-Sender: <xms:aPU6Zasl7Ab7GOkE-n-e_SE_RMO1L-z4R-x86ON5YGvObkLD79Pygw> <xme:aPU6ZffH_WfPL5eqbGaS21vOkb-KRPUBz9LsKOLKiX63wKrGK7PM4JIWAkMX2stfp wS6WjP0Y6usSw3S15s> X-ME-Received: <xmr:aPU6ZVxmyslHYL3AUj-aVoogo_vQGxNioUUiuRfc4w2QJyKg0VtzkU1FFrcuG6M> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrleefgddvvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpefhffehleejffegffeugefhkeektdffgfehjedvgeejtedtudehueffgffgfeej heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: <xmx:aPU6ZVOp1yyMQy579Uo5Hx1M6pXXlM8BuAwmYnZUjP2sSZTM5PJI4Q> <xmx:aPU6Za9uuyhukAzTvDDM3O7Yh4HBdQF7deZbDv-doRVJPbbJ0yekng> <xmx:aPU6ZdX2eQmImdYaNpOhKoLmGgwn-IC9rP-dY2XdJIJG3W1qypyarA> <xmx:aPU6ZRaCeNYq9r_rIXNTKzJcJG0F8FVU3X8SxyH39r1zHpDhtgZNYQ> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 26 Oct 2023 19:25:27 -0400 (EDT) Message-ID: <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@HIDDEN> Date: Fri, 27 Oct 2023 02:25:25 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <877cnafv39.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.2 (---) On 25/10/2023 20:52, João Távora wrote: > And make sure to put 300 000 symbols in the obarray. The symbols are > prefixed "yoyo" deliberately. > > (cl-loop repeat 300000 do (intern (symbol-name (gensym "yoyo")))) > > First a micro-benchmark: > > ;; Daniel's patch worked by Dmitry (v3) > (benchmark-run 50 > (let ((completion-styles '(flex))) > (completion-filter-completions "" obarray 'fboundp 0 nil) > (completion-filter-completions "yo" obarray 'fboundp 0 nil) > (completion-filter-completions "yoo" obarray 'fboundp 0 nil) > ));; => (12.192422429999999 3 0.107881004) > > > ;; lazy-hilit v4 patch attached in this email > (benchmark-run 50 > (let ((completion-styles '(flex)) > (completion-lazy-hilit (cl-gensym))) > (completion-all-completions "" obarray 'fboundp 0 nil) > (completion-all-completions "yo" obarray 'fboundp 0 nil) > (completion-all-completions "yoo" obarray 'fboundp 0 nil) > ));; => (12.267915333 4 0.14799709099999991) Note on this particular test: The loop on the first line only creates the symbols in the obarray, but not functions. As a result, all the completion-all-completions calls return nil because of the 'fboundp' predicate. When you change the predicate argument to nil, these timings change considerably (so it's wiser to reduce the number of repetitions to 1 or 5 at most), with completion-filter-completions being ~2.5x faster than the other. It is slower in the sorting step, though: mostly due to the extra consing created with the alist to-be-sorted, I guess, but also because of the repeated string-match call (which, while fast and much faster than the match-data call, is still not free). That's how when compared in practice using fido-vertical-mode the results were about the same.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 26 Oct 2023 23:24:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 26 19:24:53 2023
Received: from localhost ([127.0.0.1]:34677 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qw9ie-0001g4-JO
for submit <at> debbugs.gnu.org; Thu, 26 Oct 2023 19:24:53 -0400
Received: from mail-wm1-x329.google.com ([2a00:1450:4864:20::329]:46562)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1qw9ic-0001fn-53
for 47711 <at> debbugs.gnu.org; Thu, 26 Oct 2023 19:24:51 -0400
Received: by mail-wm1-x329.google.com with SMTP id
5b1f17b1804b1-4083f613272so11839015e9.1
for <47711 <at> debbugs.gnu.org>; Thu, 26 Oct 2023 16:24:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1698362653; x=1698967453; darn=debbugs.gnu.org;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
bh=W9JykNBaCOlM1IYXFyC5XGsPv0K710Mzdx6V3p/pKII=;
b=Coes1XQ/rPsW5ywW9iD2P0dODPK8F/F63ZnHR3g1/VRnpNL56B0yWNSQ7Di5VNawAw
ToxzqxogeaDdfaDMOzBo7CtrsqZ6kGT9DFqKTtZI1NsAu1PZ0ZVJ4DCkoRTme6aIpzCa
7QB9pQa+jhyy0DcuBeBHyW5EAKuTqXSan85r7aJXFXbDsKfv9BPJyeQ7i3KqVIv9eWt8
mIrs4afhDK2wcvaFl2QQvyNUMAS6yd3JX6SwSkIQ30sVOczvYyZN72LTdyo0atof/O1c
onO8n8mZTYm1+5PwTYrGLwOaA/6VgrWIa+ebS2jiCmNz7RT10qmE/qxeYs2IY6B/vuNi
gAyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1698362653; x=1698967453;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=W9JykNBaCOlM1IYXFyC5XGsPv0K710Mzdx6V3p/pKII=;
b=KMKeTZCtcj7rA7Bl7uUQa3WBq91pRrtRRgCLXM6+tvIMeAvlnOz7daz5LwMThMkdwX
4DT3Z2mFO1nSALoLqrF6CaOV5Yptg0M27Vozl7bqtkOBMr/pTllGFnJC/zHSt3ujcUWC
WmzhSWx/w3kDiwM6Xl2DOJxRPe6r5+NWpepfSfyqBAik2AwqxdID2etgteD1HaYugw3x
kzRo5uQDhVY3RVk88xg0tK07atX6vdl+UjYyEq7Y2ZqN8PrlvTIYMcrgbVEHKa1MQ/Gz
yIqyT3IsVd87azYTi39V2B0KJ5tIaXvgzX7ZmGqARKe4yHPoxJ7aWjppS/Y5VpdYfPEV
7leA==
X-Gm-Message-State: AOJu0Ywh39M5Te7mw1v+6NLxDfuaYGrNLQ18I5qiW+MiIyhFshOxrdeb
wqVkliIwCJyEAITiubjB3uDOQMC59dt5BA==
X-Google-Smtp-Source: AGHT+IHu3wjaeiBn7vxw4biETViomqDHYqCqLFzVpPM02kwPtNBNO+U08gndHWBcDINz55lwsuSDIQ==
X-Received: by 2002:a05:600c:4fcb:b0:405:367d:4656 with SMTP id
o11-20020a05600c4fcb00b00405367d4656mr951267wmq.29.1698362652435;
Thu, 26 Oct 2023 16:24:12 -0700 (PDT)
Received: from krug (87-196-80-249.net.novis.pt. [87.196.80.249])
by smtp.gmail.com with ESMTPSA id
m11-20020a05600c4f4b00b0040651505684sm196527wmq.29.2023.10.26.16.24.11
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Thu, 26 Oct 2023 16:24:11 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Dmitry Gutov <dmitry@HIDDEN>
Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2]
Add new `completion-filter-completions` API and deferred highlighting
In-Reply-To: <2703531c-333f-c4a1-837b-c151ef3fd57d@HIDDEN> (Dmitry Gutov's
message of "Fri, 27 Oct 2023 02:10:48 +0300")
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN>
<fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN>
<3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN>
<CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN>
<56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN>
<CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN>
<328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN>
<83fsvcbio7.fsf@HIDDEN>
<9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN>
<877cnafv39.fsf@HIDDEN> <jwv34xyk1dp.fsf-monnier+emacs@HIDDEN>
<CALDnm52VJpM5L_NaCJz6vcJgH4XH4HgpFBChY4Tn-JuQpGC55g@HIDDEN>
<8734xy73n7.fsf@HIDDEN> <87zg05awbw.fsf@HIDDEN>
<2703531c-333f-c4a1-837b-c151ef3fd57d@HIDDEN>
Date: Fri, 27 Oct 2023 00:27:12 +0100
Message-ID: <87v8atarsf.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47711
Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Dmitry Gutov <dmitry@HIDDEN> writes:
> My understanding is it's due to the judicious call (copy-sequence
> orig) that you added before 'put-text-property' is called. While it
> seems like a good idea to preserve the original value, when almost all
> of obarray matches the current input (which is the current scenario),
> a lot of strings will be copied.
You're right, I reproduced the regression. I thought I had taken out
the copy-sequence, but forgot it there. In an earlier stage I suspected
that I needed the copy, but I don't think I do. Please try this new
patch that removes it. I've also pushed it to the
feature/completion-lazy-hilit branch.
Jo=C3=A3o
--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline; filename=lazy-hilit-2023-v3.diff
diff --git a/lisp/icomplete.el b/lisp/icomplete.el
index e6fdd1f1836..3e888c8b06a 100644
--- a/lisp/icomplete.el
+++ b/lisp/icomplete.el
@@ -722,7 +722,8 @@ icomplete-exhibit
;; Check if still in the right buffer (bug#61308)
(or (window-minibuffer-p) completion-in-region--data)
(icomplete-simple-completing-p)) ;Shouldn't be necessary.
- (let ((saved-point (point)))
+ (let ((saved-point (point))
+ (completion-lazy-hilit t))
(save-excursion
(goto-char (icomplete--field-end))
;; Insert the match-status information:
@@ -754,12 +755,13 @@ icomplete-exhibit
(overlay-end rfn-eshadow-overlay)))
(let* ((field-string (icomplete--field-string))
(text (while-no-input
+ (benchmark-progn
(icomplete-completions
field-string
(icomplete--completion-table)
(icomplete--completion-predicate)
(if (window-minibuffer-p)
- (eq minibuffer--require-match t)))))
+ (eq minibuffer--require-match t))))))
(buffer-undo-list t)
deactivate-mark)
;; Do nothing if while-no-input was aborted.
@@ -901,7 +903,7 @@ icomplete--render-vertical
'icomplete-selected-match 'append comp)
collect (concat prefix
(make-string (- max-prefix-len (length prefix)) ? )
- comp
+ (completion-lazy-hilit comp)
(make-string (- max-comp-len (length comp)) ? )
suffix)
into lines-aux
@@ -1067,7 +1069,8 @@ icomplete-completions
(if (< prospects-len prospects-max)
(push comp prospects)
(setq limit t)))
- (setq prospects (nreverse prospects))
+ (setq prospects
+ (nreverse (mapcar #'completion-lazy-hilit prospects)))
;; Decorate first of the prospects.
(when prospects
(let ((first (copy-sequence (pop prospects))))
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 2120e31775e..ecde00dd28d 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1234,6 +1234,7 @@ completion-all-completions
POINT is the position of point within STRING.
The return value is a list of completions and may contain the base-size
in the last `cdr'."
+ (setq completion-lazy-hilit-fn nil)
;; FIXME: We need to additionally return the info needed for the
;; second part of completion-base-position.
(completion--nth-completion 2 string table pred point metadata))
@@ -3720,21 +3721,32 @@ completion-pcm--all-completions
;; Use all-completions to do an initial cull. This is a big win,
;; since all-completions is written in C!
- (let* (;; Convert search pattern to a standard regular expression.
- (regex (completion-pcm--pattern->regex pattern))
- (case-fold-search completion-ignore-case)
- (completion-regexp-list (cons regex completion-regexp-list))
- (compl (all-completions
- (concat prefix
- (if (stringp (car pattern)) (car pattern) ""))
- table pred)))
- (if (not (functionp table))
- ;; The internal functions already obeyed completion-regexp-list.
- compl
- (let ((poss ()))
- (dolist (c compl)
- (when (string-match-p regex c) (push c poss)))
- (nreverse poss))))))
+ (let* ((case-fold-search completion-ignore-case)
+ (completion-regexp-list (cons
+ ;; Convert search pattern to a
+ ;; standard regular expression.
+ (completion-pcm--pattern->regex pattern)
+ completion-regexp-list))
+ (completions (all-completions
+ (concat prefix
+ (if (stringp (car pattern)) (car pattern) ""))
+ table pred)))
+ (cond ((or (not (functionp table))
+ (cl-loop for e in pattern never (stringp e)))
+ ;; The internal functions already obeyed completion-regexp-list.
+ completions)
+ (t
+ ;; The pattern has something interesting to match, in
+ ;; which case we take the opportunity to add an early
+ ;; completion-score cookie to each completion.
+ (cl-loop with re = (completion-pcm--pattern->regex pattern 'group)
+ for comp in completions
+ for score = (completion--flex-score comp re t)
+ when score
+ do (put-text-property 0 1 'completion-score
+ score
+ comp)
+ and collect comp))))))
(defvar flex-score-match-tightness 3
"Controls how the `flex' completion style scores its matches.
@@ -3749,108 +3761,195 @@ flex-score-match-tightness
than the latter (which has two \"holes\" and three
one-letter-long matches).")
+(defvar-local completion-lazy-hilit nil
+ "If non-nil, request completion lazy highlighting.
+
+Completion-presenting frontends may opt to bind this variable to
+non-nil value in the context of completion-producing calls (such
+as `completion-all-sorted-completions'). This hints the
+intervening completion styles that they do not need to
+fontify (i.e. propertize with the `face' property) completion
+strings with highlights of the matching parts.
+
+When doing so, it is the frontend -- not the style -- who becomes
+responsible this fontification. The frontend binds this variable
+to non-nil, and calls the function with the same name
+`completion-lazy-hilit' on each completion string that is to be
+displayed to the user.
+
+Note that only some completion styles take advantage of this
+variable for optimization purposes. Other styles will ignore the
+hint and greedily fontify as usual. It is still safe for a
+frontend to call `completion-lazy-hilit' in these situations.
+
+To author a completion style that takes advantage see
+`completion-lazy-hilit-fn' and look in the source of
+`completion-pcm--hilit-commonality'.")
+
+(defvar completion-lazy-hilit-fn nil
+ "Used by completions styles to honouring `completion-lazy-hilit'.
+When a given style wants to enable support for
+`completion-lazy-hilit' (which see), that style should set this
+variable to a function of one argument, a fresh string to be
+displayed to the user. The function is responsible for
+destructively highlighting the string.")
+
+(defun completion-lazy-hilit (str)
+ "Return a copy of completion STR that is `face'-propertized.
+See documentation for variable `completion-lazy-hilit' for more
+details."
+ (if (and completion-lazy-hilit completion-lazy-hilit-fn)
+ (funcall completion-lazy-hilit-fn (copy-sequence str))
+ str))
+
+(defun completion--hilit-from-re (string regexp)
+ "Fontify STRING with `completions-common-part' using REGEXP."
+ (let* ((md (and regexp (string-match regexp string) (cddr (match-data t))))
+ (me (and md (match-end 0)))
+ (from 0))
+ (while md
+ (add-face-text-property from (pop md) 'completions-common-part nil string)
+ (setq from (pop md)))
+ (unless (or (not me) (= from me))
+ (add-face-text-property from me 'completions-common-part nil string))
+ string))
+
+(defun completion--flex-score-1 (md-groups match-end len)
+ "Compute matching score of completion.
+The score lies in the range between 0 and 1, where 1 corresponds to
+the full match.
+MD-GROUPS is the \"group\" part of the match data.
+MATCH-END is the end of the match.
+LEN is the length of the completion string."
+ (let* ((from 0)
+ ;; To understand how this works, consider these simple
+ ;; ascii diagrams showing how the pattern "foo"
+ ;; flex-matches "fabrobazo", "fbarbazoo" and
+ ;; "barfoobaz":
+
+ ;; f abr o baz o
+ ;; + --- + --- +
+
+ ;; f barbaz oo
+ ;; + ------ ++
+
+ ;; bar foo baz
+ ;; +++
+
+ ;; "+" indicates parts where the pattern matched. A
+ ;; "hole" in the middle of the string is indicated by
+ ;; "-". Note that there are no "holes" near the edges
+ ;; of the string. The completion score is a number
+ ;; bound by (0..1] (i.e., larger than (but not equal
+ ;; to) zero, and smaller or equal to one): the higher
+ ;; the better and only a perfect match (pattern equals
+ ;; string) will have score 1. The formula takes the
+ ;; form of a quotient. For the numerator, we use the
+ ;; number of +, i.e. the length of the pattern. For
+ ;; the denominator, it first computes
+ ;;
+ ;; hole_i_contrib = 1 + (Li-1)^(1/tightness)
+ ;;
+ ;; , for each hole "i" of length "Li", where tightness
+ ;; is given by `flex-score-match-tightness'. The
+ ;; final value for the denominator is then given by:
+ ;;
+ ;; (SUM_across_i(hole_i_contrib) + 1) * len
+ ;;
+ ;; , where "len" is the string's length.
+ (score-numerator 0)
+ (score-denominator 0)
+ (last-b 0))
+ (while (and md-groups (car md-groups))
+ (let ((a from)
+ (b (pop md-groups)))
+ (setq
+ score-numerator (+ score-numerator (- b a)))
+ (unless (or (= a last-b)
+ (zerop last-b)
+ (= a len))
+ (setq
+ score-denominator (+ score-denominator
+ 1
+ (expt (- a last-b 1)
+ (/ 1.0
+ flex-score-match-tightness)))))
+ (setq
+ last-b b))
+ (setq from (pop md-groups)))
+ ;; If `pattern' doesn't have an explicit trailing any, the
+ ;; regex `re' won't produce match data representing the
+ ;; region after the match. We need to account to account
+ ;; for that extra bit of match (bug#42149).
+ (unless (= from match-end)
+ (let ((a from)
+ (b match-end))
+ (setq
+ score-numerator (+ score-numerator (- b a)))
+ (unless (or (= a last-b)
+ (zerop last-b)
+ (= a len))
+ (setq
+ score-denominator (+ score-denominator
+ 1
+ (expt (- a last-b 1)
+ (/ 1.0
+ flex-score-match-tightness)))))
+ (setq
+ last-b b)))
+ (/ score-numerator (* len (1+ score-denominator)) 1.0)))
+
+(defvar completion--flex-score-last-md nil
+ "Helper variable for `completion--flex-score'.")
+
+(defun completion--flex-score (str re &optional dont-error)
+ "Compute flex score of completion STR based on RE.
+If DONT-ERROR, just return nil if RE doesn't match STR."
+ (cond ((string-match re str)
+ (let* ((match-end (match-end 0))
+ (md (cddr
+ (setq
+ completion--flex-score-last-md
+ (match-data t completion--flex-score-last-md)))))
+ (completion--flex-score-1 md match-end (length str))))
+ ((not dont-error)
+ (error "Internal error: %s does not match %s" re str))))
+
(defun completion-pcm--hilit-commonality (pattern completions)
"Show where and how well PATTERN matches COMPLETIONS.
PATTERN, a list of symbols and strings as seen
`completion-pcm--merge-completions', is assumed to match every
-string in COMPLETIONS. Return a deep copy of COMPLETIONS where
-each string is propertized with `completion-score', a number
-between 0 and 1, and with faces `completions-common-part',
-`completions-first-difference' in the relevant segments."
+string in COMPLETIONS.
+
+If `completion-lazy-hilit' is nil, return a deep copy of
+COMPLETIONS where each string is propertized with
+`completion-score', a number between 0 and 1, and with faces
+`completions-common-part', `completions-first-difference' in the
+relevant segments.
+
+Else, if `completion-lazy-hilit' is t, return COMPLETIONS where
+each string now has a `completion-score' property and no
+highlighting."
(cond
((and completions (cl-loop for e in pattern thereis (stringp e)))
(let* ((re (completion-pcm--pattern->regex pattern 'group))
- (point-idx (completion-pcm--pattern-point-idx pattern))
- (case-fold-search completion-ignore-case)
- last-md)
- (mapcar
- (lambda (str)
- ;; Don't modify the string itself.
- (setq str (copy-sequence str))
- (unless (string-match re str)
- (error "Internal error: %s does not match %s" re str))
- (let* ((pos (if point-idx (match-beginning point-idx) (match-end 0)))
- (match-end (match-end 0))
- (md (cddr (setq last-md (match-data t last-md))))
- (from 0)
- (end (length str))
- ;; To understand how this works, consider these simple
- ;; ascii diagrams showing how the pattern "foo"
- ;; flex-matches "fabrobazo", "fbarbazoo" and
- ;; "barfoobaz":
-
- ;; f abr o baz o
- ;; + --- + --- +
-
- ;; f barbaz oo
- ;; + ------ ++
-
- ;; bar foo baz
- ;; +++
-
- ;; "+" indicates parts where the pattern matched. A
- ;; "hole" in the middle of the string is indicated by
- ;; "-". Note that there are no "holes" near the edges
- ;; of the string. The completion score is a number
- ;; bound by (0..1] (i.e., larger than (but not equal
- ;; to) zero, and smaller or equal to one): the higher
- ;; the better and only a perfect match (pattern equals
- ;; string) will have score 1. The formula takes the
- ;; form of a quotient. For the numerator, we use the
- ;; number of +, i.e. the length of the pattern. For
- ;; the denominator, it first computes
- ;;
- ;; hole_i_contrib = 1 + (Li-1)^(1/tightness)
- ;;
- ;; , for each hole "i" of length "Li", where tightness
- ;; is given by `flex-score-match-tightness'. The
- ;; final value for the denominator is then given by:
- ;;
- ;; (SUM_across_i(hole_i_contrib) + 1) * len
- ;;
- ;; , where "len" is the string's length.
- (score-numerator 0)
- (score-denominator 0)
- (last-b 0)
- (update-score-and-face
- (lambda (a b)
- "Update score and face given match range (A B)."
- (add-face-text-property a b
- 'completions-common-part
- nil str)
- (setq
- score-numerator (+ score-numerator (- b a)))
- (unless (or (= a last-b)
- (zerop last-b)
- (= a (length str)))
- (setq
- score-denominator (+ score-denominator
- 1
- (expt (- a last-b 1)
- (/ 1.0
- flex-score-match-tightness)))))
- (setq
- last-b b))))
- (while md
- (funcall update-score-and-face from (pop md))
- (setq from (pop md)))
- ;; If `pattern' doesn't have an explicit trailing any, the
- ;; regex `re' won't produce match data representing the
- ;; region after the match. We need to account to account
- ;; for that extra bit of match (bug#42149).
- (unless (= from match-end)
- (funcall update-score-and-face from match-end))
- (if (> (length str) pos)
- (add-face-text-property
- pos (1+ pos)
- 'completions-first-difference
- nil str))
- (unless (zerop (length str))
- (put-text-property
- 0 1 'completion-score
- (/ score-numerator (* end (1+ score-denominator)) 1.0) str)))
- str)
- completions)))
+ (score-maybe (lambda (str)
+ (unless (get-text-property 0 'completion-score str)
+ (put-text-property 0 1 'completion-score
+ (completion--flex-score str re)
+ str)))))
+ (cond (completion-lazy-hilit
+ (setq completion-lazy-hilit-fn
+ (lambda (str) (completion--hilit-from-re str re)))
+ (mapc score-maybe completions))
+ (t
+ (mapcar
+ (lambda (str)
+ (setq str (copy-sequence str))
+ (funcall score-maybe str)
+ (completion--hilit-from-re str re)
+ str)
+ completions)))))
(t completions)))
(defun completion-pcm--find-all-completions (string table pred point
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 26 Oct 2023 23:11:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 26 19:11:35 2023 Received: from localhost ([127.0.0.1]:34671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qw9Vn-0001M8-4t for submit <at> debbugs.gnu.org; Thu, 26 Oct 2023 19:11:35 -0400 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:45441) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1qw9Vi-0001Lq-G9 for 47711 <at> debbugs.gnu.org; Thu, 26 Oct 2023 19:11:34 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 2F50832001C6; Thu, 26 Oct 2023 19:10:53 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Thu, 26 Oct 2023 19:10:53 -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= 1698361852; x=1698448252; bh=tzgnEix9LB8sXL5wpLsY1z6o4QCd+8ljipD NhAoNyaU=; b=Ea0Ckc2kQOf/jY6vUPXo61Age/d6p8JyDeFDyuejyyE4ueW8XQi XBOhZP+poXv+rUGmWwntQX0aZIPcfUNeO3n2Fcw4T6TgEeXPr3GAdper2ZglXLfB LboqrjfxpUDU2wyI/rLhS0/YCuwBvQZPIfSl/xym7HBglcrestImA2zxdHz6ipCR 6yRfldZngaa7V7pdE8zbThH8sEcHHWymb2Ik52/tmF9LQR4mVAeMBS+LVaP/gVmT KOO/ie59PCNoa0FsrQLqwYbhx8UHAkFEi16+tw0ytxj/jN0RwfZO2JJ+Ay9TOm/x mW25Dtq187JfPOd63IHUdnuUkBHw/fC3BzQ== 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= 1698361852; x=1698448252; bh=tzgnEix9LB8sXL5wpLsY1z6o4QCd+8ljipD NhAoNyaU=; b=Bej7yE2QKN9gCwqn6uMHxWh7YepbkpnbKWZ16edS6Mx1ercHAUy aEddnYACKrWz9pW6zfxEZySIHL+ZenZHV2ZvRuzLoPEnPRIvfXQtUQ6bv8hJ93SZ dlpE23i5dy8aJhQGd9wwnmUlDlce180DqpwXCRtV4PWIUo1V42bgi1oNC//36d+K REQd9pFMLz5dB8Lrr4O0GdSVtTAuMCGUsOzky/vKMR5R4JQH5IrPdDdh34zcxcfI fj9gluk6x/0BnT3hEYBfpxD6HIMT8KKhDn3cgW1m9JxUvo39qi15ucPZU9r4jB9i TGQRQdzYcl+MhqUvaLbQCrmCh/81kMcZ6nQ== X-ME-Sender: <xms:-_E6ZUoxlPCWudBLDKkqdz1XCPufwYKuEfhg4E_FB88XKZdVFfBHkg> <xme:-_E6ZaqUj3e6F560dFYUI6-_RXw__rIWvM9ecS31owMDZg4EEUAn0NUIlXp-voOPD Szmrz_bnPliL5XmgoQ> X-ME-Received: <xmr:-_E6ZZNgy1fuoVLhX1nTdhrmLr6C0hbp1aQO22OFXop8BHV-VZ4YhD8kpYBM5wE> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrleefgddulecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpefhffehleejffegffeugefhkeektdffgfehjedvgeejtedtudehueffgffgfeej heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: <xmx:_PE6Zb6cw-B4Y8qwP98-8WB6KDMGoqIbtaIVTh7eVCeqj1Mq5rkXPg> <xmx:_PE6ZT41iPFLb_U2-A8B_Mr71aF5KoueW7NiNzZtcRKcXqtlyF1nHA> <xmx:_PE6Zbj74pA4vo1Lwq4edMdPx32UdWGyEfGfC-hjiG6aQ6tY9ZyVcA> <xmx:_PE6ZVkg2jat1nPFh_mn_ULcCJrWoWupskbwse1Bqm6aTX77MkbeXA> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 26 Oct 2023 19:10:50 -0400 (EDT) Message-ID: <2703531c-333f-c4a1-837b-c151ef3fd57d@HIDDEN> Date: Fri, 27 Oct 2023 02:10:48 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, Stefan Monnier <monnier@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <jwv34xyk1dp.fsf-monnier+emacs@HIDDEN> <CALDnm52VJpM5L_NaCJz6vcJgH4XH4HgpFBChY4Tn-JuQpGC55g@HIDDEN> <8734xy73n7.fsf@HIDDEN> <87zg05awbw.fsf@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <87zg05awbw.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.2 (---) Hi Joao, Thanks for the updates and the numbers. On 27/10/2023 00:49, João Távora wrote: > João Távora<joaotavora@HIDDEN> writes: > >> So, backed by the new ability to conduct good benchmarks, I looked at >> the problem anew. I found some insight in the problem, and came up with >> a new "lazy-hilit" patch which performs just as well, if not slightly >> better, than Daniel's, while keeping the changes to lisp/minibuffer.el >> much more minimal and not adding replacement for the longstanding >> completion-all-completions. > Working on this a bit more, I've now been able to optimize the "lazy > hilit" patch even further by recognizing that in many situations we > don't need to match the "PCM" pattern to each string twice. The first > time we do it, we can calculate a score immediately and store it in the > string. The average response times for the "yo-yoo" test described > previously: This latest change in particular regressed this related scenario: ;; Use 'set' to ensure that the variables are bound. (cl-loop repeat 300000 do (set (intern (symbol-name (gensym "yoyo"))) 4)) C-h v <then type y o <backspace> o <backspace> ...> It increased the timings for that scenario from ~0.600s (with either of the latest filter-deferred patches and your previous version) to ~1s. My understanding is it's due to the judicious call (copy-sequence orig) that you added before 'put-text-property' is called. While it seems like a good idea to preserve the original value, when almost all of obarray matches the current input (which is the current scenario), a lot of strings will be copied. But (completing-read "" obarray) is not affected, and I don't see why. Maybe because it re-sorts less than icomplete? And the consing triggers the GC threshold less often (thanks to the other changes).
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 26 Oct 2023 21:46:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 26 17:46:49 2023
Received: from localhost ([127.0.0.1]:34645 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qw8Bk-0007XF-0A
for submit <at> debbugs.gnu.org; Thu, 26 Oct 2023 17:46:48 -0400
Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]:58455)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1qw8Bh-0007Wz-M5
for 47711 <at> debbugs.gnu.org; Thu, 26 Oct 2023 17:46:46 -0400
Received: by mail-wr1-x434.google.com with SMTP id
ffacd0b85a97d-307d58b3efbso900758f8f.0
for <47711 <at> debbugs.gnu.org>; Thu, 26 Oct 2023 14:46:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1698356768; x=1698961568; darn=debbugs.gnu.org;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
bh=sZT+TP0Tt9zQl4/Sj82+ly5Zcv1s+BsVANc11Ug75XQ=;
b=bgAjaPk1rFU4c6+tVz4A0w88hA51KeRa8cgS17hWiWjzf/5jQ8MPbOoTwseWa0GVHc
Kf8xzlFwBxqYxC0eSRgjcp6bmk0dsnW3LZtJo3bMD8bLW34fd8YIh4vJ+qzN4/UCert+
JXlJoT1uvJxZ73cu7b/2NtdUkzEBwXMJDd2ct+rJV72j+a4Xujlj0AR1RTj7iD71ieJR
nDMoJlvveTWTIMK7cnHLXaJD1N/AtxY01UKxrLRfv/AX9iLJu3w8UXN2NODBQYijl35B
2mWmxzUcgzI4Zfw6sEgoEPk4KA+YJgF3QMQ8avLu8j2zpJVHYFTsxxE/4amMpofs0I3V
lHqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1698356768; x=1698961568;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=sZT+TP0Tt9zQl4/Sj82+ly5Zcv1s+BsVANc11Ug75XQ=;
b=v+tQ31N9OkQILwDbilwZ6ZDwRnrYJHwEPSf1HcQCrUBl+nhnd7ERbFVynngXqcih4d
X7O7atFGHinPIxJRyDree05Zj6OoyVqoy4lcvyqmJXZrrm30g4/2uwsdwetxyQ3NBWK0
Ekf866ffT5R+1TYMjoQmUgJY8E9Iahjq/jaDc+IY9OAlW8hh+Y+s14OLAypt1W7cjw7x
iJVBGpYwrpXDAPthZ1F7FF8xlnEHY9Rn6KucVHAvki6HVVZBjbBrY3pY8WiAAGriQ5K2
mSx2GAzKMEXr0IhrMFFk2IRrnwTZOrjnZPYkVDKLv8i59sHe5VJtz5pDR+q00JF+FW5f
gFWg==
X-Gm-Message-State: AOJu0YxD907jLUo7WiOJxcTaLVkIZeIxnLsn4RJocl7J4yi3GzubgyHg
7kTjFqNqZrk2wjSZVK4mwHzuKkBMtUpxUA==
X-Google-Smtp-Source: AGHT+IGf+DhENhVd1Rfcqxsvq6+v0+gbKKRHuNF3zAgvvT7Yo+oZFqillvzPEuLfxoR4eGgb1MSvzQ==
X-Received: by 2002:a5d:4fc9:0:b0:31f:9b4f:1910 with SMTP id
h9-20020a5d4fc9000000b0031f9b4f1910mr626685wrw.63.1698356768099;
Thu, 26 Oct 2023 14:46:08 -0700 (PDT)
Received: from krug (87-196-80-249.net.novis.pt. [87.196.80.249])
by smtp.gmail.com with ESMTPSA id
g4-20020a5d46c4000000b0032d72f48555sm312973wrs.36.2023.10.26.14.46.06
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Thu, 26 Oct 2023 14:46:07 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2]
Add new `completion-filter-completions` API and deferred highlighting
In-Reply-To: <8734xy73n7.fsf@HIDDEN> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?=
=?utf-8?Q?a=22's?= message of "Wed, 25 Oct 2023 23:12:28 +0100")
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN>
<fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN>
<3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN>
<CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN>
<56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN>
<CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN>
<328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN>
<83fsvcbio7.fsf@HIDDEN>
<9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN>
<877cnafv39.fsf@HIDDEN> <jwv34xyk1dp.fsf-monnier+emacs@HIDDEN>
<CALDnm52VJpM5L_NaCJz6vcJgH4XH4HgpFBChY4Tn-JuQpGC55g@HIDDEN>
<8734xy73n7.fsf@HIDDEN>
Date: Thu, 26 Oct 2023 22:49:07 +0100
Message-ID: <87zg05awbw.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47711
Cc: Dmitry Gutov <dmitry@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
47711 <at> debbugs.gnu.org, Daniel Mendler <mail@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:
> So, backed by the new ability to conduct good benchmarks, I looked at
> the problem anew. I found some insight in the problem, and came up with
> a new "lazy-hilit" patch which performs just as well, if not slightly
> better, than Daniel's, while keeping the changes to lisp/minibuffer.el
> much more minimal and not adding replacement for the longstanding
> completion-all-completions.
Working on this a bit more, I've now been able to optimize the "lazy
hilit" patch even further by recognizing that in many situations we
don't need to match the "PCM" pattern to each string twice. The first
time we do it, we can calculate a score immediately and store it in the
string. The average response times for the "yo-yoo" test described
previously:
master: 2.604s
2021 lazy-hilit patch: 1.240s
2023 Daniel+Dmitry: 0.831s
2023 lazy-hilit v1: 0.792s
And the new one:
2023 lazy-hilit v2: 0.518s
I'm now keeping my work in a branch called
feature/completion-lazy-hilit, but I still attach the diff here.
Jo=C3=A3o
PS: for the flex style in particular, there are even more optimizations
possible. For example one could take advantage of the fact that in
flex, a longer pattern should always yield a subset of the completions
produced by a shorter pattern in the same completion session. But this
requires solid concepts of a "completion session".
--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline; filename=lazy-hilit-2023-v2.diff
diff --git a/lisp/icomplete.el b/lisp/icomplete.el
index e6fdd1f1836..3e888c8b06a 100644
--- a/lisp/icomplete.el
+++ b/lisp/icomplete.el
@@ -722,7 +722,8 @@ icomplete-exhibit
;; Check if still in the right buffer (bug#61308)
(or (window-minibuffer-p) completion-in-region--data)
(icomplete-simple-completing-p)) ;Shouldn't be necessary.
- (let ((saved-point (point)))
+ (let ((saved-point (point))
+ (completion-lazy-hilit t))
(save-excursion
(goto-char (icomplete--field-end))
;; Insert the match-status information:
@@ -754,12 +755,13 @@ icomplete-exhibit
(overlay-end rfn-eshadow-overlay)))
(let* ((field-string (icomplete--field-string))
(text (while-no-input
+ (benchmark-progn
(icomplete-completions
field-string
(icomplete--completion-table)
(icomplete--completion-predicate)
(if (window-minibuffer-p)
- (eq minibuffer--require-match t)))))
+ (eq minibuffer--require-match t))))))
(buffer-undo-list t)
deactivate-mark)
;; Do nothing if while-no-input was aborted.
@@ -901,7 +903,7 @@ icomplete--render-vertical
'icomplete-selected-match 'append comp)
collect (concat prefix
(make-string (- max-prefix-len (length prefix)) ? )
- comp
+ (completion-lazy-hilit comp)
(make-string (- max-comp-len (length comp)) ? )
suffix)
into lines-aux
@@ -1067,7 +1069,8 @@ icomplete-completions
(if (< prospects-len prospects-max)
(push comp prospects)
(setq limit t)))
- (setq prospects (nreverse prospects))
+ (setq prospects
+ (nreverse (mapcar #'completion-lazy-hilit prospects)))
;; Decorate first of the prospects.
(when prospects
(let ((first (copy-sequence (pop prospects))))
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 2120e31775e..b38eb49aba8 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1234,6 +1234,7 @@ completion-all-completions
POINT is the position of point within STRING.
The return value is a list of completions and may contain the base-size
in the last `cdr'."
+ (setq completion-lazy-hilit-fn nil)
;; FIXME: We need to additionally return the info needed for the
;; second part of completion-base-position.
(completion--nth-completion 2 string table pred point metadata))
@@ -3720,21 +3721,33 @@ completion-pcm--all-completions
;; Use all-completions to do an initial cull. This is a big win,
;; since all-completions is written in C!
- (let* (;; Convert search pattern to a standard regular expression.
- (regex (completion-pcm--pattern->regex pattern))
- (case-fold-search completion-ignore-case)
- (completion-regexp-list (cons regex completion-regexp-list))
- (compl (all-completions
- (concat prefix
- (if (stringp (car pattern)) (car pattern) ""))
- table pred)))
- (if (not (functionp table))
- ;; The internal functions already obeyed completion-regexp-list.
- compl
- (let ((poss ()))
- (dolist (c compl)
- (when (string-match-p regex c) (push c poss)))
- (nreverse poss))))))
+ (let* ((case-fold-search completion-ignore-case)
+ (completion-regexp-list (cons
+ ;; Convert search pattern to a
+ ;; standard regular expression.
+ (completion-pcm--pattern->regex pattern)
+ completion-regexp-list))
+ (completions (all-completions
+ (concat prefix
+ (if (stringp (car pattern)) (car pattern) ""))
+ table pred)))
+ (cond ((or (not (functionp table))
+ (cl-loop for e in pattern never (stringp e)))
+ ;; The internal functions already obeyed completion-regexp-list.
+ completions)
+ (t
+ ;; The pattern has something interesting to match, in
+ ;; which case we take the opportunity to add an early
+ ;; completion-score cookie to each completion.
+ (cl-loop with re = (completion-pcm--pattern->regex pattern 'group)
+ for orig in completions
+ for comp = (copy-sequence orig)
+ for score = (completion--flex-score comp re t)
+ when score
+ do (put-text-property 0 1 'completion-score
+ score
+ comp)
+ and collect comp))))))
(defvar flex-score-match-tightness 3
"Controls how the `flex' completion style scores its matches.
@@ -3749,108 +3762,195 @@ flex-score-match-tightness
than the latter (which has two \"holes\" and three
one-letter-long matches).")
+(defvar-local completion-lazy-hilit nil
+ "If non-nil, request completion lazy highlighting.
+
+Completion-presenting frontends may opt to bind this variable to
+non-nil value in the context of completion-producing calls (such
+as `completion-all-sorted-completions'). This hints the
+intervening completion styles that they do not need to
+fontify (i.e. propertize with the `face' property) completion
+strings with highlights of the matching parts.
+
+When doing so, it is the frontend -- not the style -- who becomes
+responsible this fontification. The frontend binds this variable
+to non-nil, and calls the function with the same name
+`completion-lazy-hilit' on each completion string that is to be
+displayed to the user.
+
+Note that only some completion styles take advantage of this
+variable for optimization purposes. Other styles will ignore the
+hint and greedily fontify as usual. It is still safe for a
+frontend to call `completion-lazy-hilit' in these situations.
+
+To author a completion style that takes advantage see
+`completion-lazy-hilit-fn' and look in the source of
+`completion-pcm--hilit-commonality'.")
+
+(defvar completion-lazy-hilit-fn nil
+ "Used by completions styles to honouring `completion-lazy-hilit'.
+When a given style wants to enable support for
+`completion-lazy-hilit' (which see), that style should set this
+variable to a function of one argument, a fresh string to be
+displayed to the user. The function is responsible for
+destructively highlighting the string.")
+
+(defun completion-lazy-hilit (str)
+ "Return a copy of completion STR that is `face'-propertized.
+See documentation for variable `completion-lazy-hilit' for more
+details."
+ (if (and completion-lazy-hilit completion-lazy-hilit-fn)
+ (funcall completion-lazy-hilit-fn (copy-sequence str))
+ str))
+
+(defun completion--hilit-from-re (string regexp)
+ "Fontify STRING with `completions-common-part' using REGEXP."
+ (let* ((md (and regexp (string-match regexp string) (cddr (match-data t))))
+ (me (and md (match-end 0)))
+ (from 0))
+ (while md
+ (add-face-text-property from (pop md) 'completions-common-part nil string)
+ (setq from (pop md)))
+ (unless (or (not me) (= from me))
+ (add-face-text-property from me 'completions-common-part nil string))
+ string))
+
+(defun completion--flex-score-1 (md-groups match-end len)
+ "Compute matching score of completion.
+The score lies in the range between 0 and 1, where 1 corresponds to
+the full match.
+MD-GROUPS is the \"group\" part of the match data.
+MATCH-END is the end of the match.
+LEN is the length of the completion string."
+ (let* ((from 0)
+ ;; To understand how this works, consider these simple
+ ;; ascii diagrams showing how the pattern "foo"
+ ;; flex-matches "fabrobazo", "fbarbazoo" and
+ ;; "barfoobaz":
+
+ ;; f abr o baz o
+ ;; + --- + --- +
+
+ ;; f barbaz oo
+ ;; + ------ ++
+
+ ;; bar foo baz
+ ;; +++
+
+ ;; "+" indicates parts where the pattern matched. A
+ ;; "hole" in the middle of the string is indicated by
+ ;; "-". Note that there are no "holes" near the edges
+ ;; of the string. The completion score is a number
+ ;; bound by (0..1] (i.e., larger than (but not equal
+ ;; to) zero, and smaller or equal to one): the higher
+ ;; the better and only a perfect match (pattern equals
+ ;; string) will have score 1. The formula takes the
+ ;; form of a quotient. For the numerator, we use the
+ ;; number of +, i.e. the length of the pattern. For
+ ;; the denominator, it first computes
+ ;;
+ ;; hole_i_contrib = 1 + (Li-1)^(1/tightness)
+ ;;
+ ;; , for each hole "i" of length "Li", where tightness
+ ;; is given by `flex-score-match-tightness'. The
+ ;; final value for the denominator is then given by:
+ ;;
+ ;; (SUM_across_i(hole_i_contrib) + 1) * len
+ ;;
+ ;; , where "len" is the string's length.
+ (score-numerator 0)
+ (score-denominator 0)
+ (last-b 0))
+ (while (and md-groups (car md-groups))
+ (let ((a from)
+ (b (pop md-groups)))
+ (setq
+ score-numerator (+ score-numerator (- b a)))
+ (unless (or (= a last-b)
+ (zerop last-b)
+ (= a len))
+ (setq
+ score-denominator (+ score-denominator
+ 1
+ (expt (- a last-b 1)
+ (/ 1.0
+ flex-score-match-tightness)))))
+ (setq
+ last-b b))
+ (setq from (pop md-groups)))
+ ;; If `pattern' doesn't have an explicit trailing any, the
+ ;; regex `re' won't produce match data representing the
+ ;; region after the match. We need to account to account
+ ;; for that extra bit of match (bug#42149).
+ (unless (= from match-end)
+ (let ((a from)
+ (b match-end))
+ (setq
+ score-numerator (+ score-numerator (- b a)))
+ (unless (or (= a last-b)
+ (zerop last-b)
+ (= a len))
+ (setq
+ score-denominator (+ score-denominator
+ 1
+ (expt (- a last-b 1)
+ (/ 1.0
+ flex-score-match-tightness)))))
+ (setq
+ last-b b)))
+ (/ score-numerator (* len (1+ score-denominator)) 1.0)))
+
+(defvar completion--flex-score-last-md nil
+ "Helper variable for `completion--flex-score'.")
+
+(defun completion--flex-score (str re &optional dont-error)
+ "Compute flex score of completion STR based on RE.
+If DONT-ERROR, just return nil if RE doesn't match STR."
+ (cond ((string-match re str)
+ (let* ((match-end (match-end 0))
+ (md (cddr
+ (setq
+ completion--flex-score-last-md
+ (match-data t completion--flex-score-last-md)))))
+ (completion--flex-score-1 md match-end (length str))))
+ ((not dont-error)
+ (error "Internal error: %s does not match %s" re str))))
+
(defun completion-pcm--hilit-commonality (pattern completions)
"Show where and how well PATTERN matches COMPLETIONS.
PATTERN, a list of symbols and strings as seen
`completion-pcm--merge-completions', is assumed to match every
-string in COMPLETIONS. Return a deep copy of COMPLETIONS where
-each string is propertized with `completion-score', a number
-between 0 and 1, and with faces `completions-common-part',
-`completions-first-difference' in the relevant segments."
+string in COMPLETIONS.
+
+If `completion-lazy-hilit' is nil, return a deep copy of
+COMPLETIONS where each string is propertized with
+`completion-score', a number between 0 and 1, and with faces
+`completions-common-part', `completions-first-difference' in the
+relevant segments.
+
+Else, if `completion-lazy-hilit' is t, return COMPLETIONS where
+each string now has a `completion-score' property and no
+highlighting."
(cond
((and completions (cl-loop for e in pattern thereis (stringp e)))
(let* ((re (completion-pcm--pattern->regex pattern 'group))
- (point-idx (completion-pcm--pattern-point-idx pattern))
- (case-fold-search completion-ignore-case)
- last-md)
- (mapcar
- (lambda (str)
- ;; Don't modify the string itself.
- (setq str (copy-sequence str))
- (unless (string-match re str)
- (error "Internal error: %s does not match %s" re str))
- (let* ((pos (if point-idx (match-beginning point-idx) (match-end 0)))
- (match-end (match-end 0))
- (md (cddr (setq last-md (match-data t last-md))))
- (from 0)
- (end (length str))
- ;; To understand how this works, consider these simple
- ;; ascii diagrams showing how the pattern "foo"
- ;; flex-matches "fabrobazo", "fbarbazoo" and
- ;; "barfoobaz":
-
- ;; f abr o baz o
- ;; + --- + --- +
-
- ;; f barbaz oo
- ;; + ------ ++
-
- ;; bar foo baz
- ;; +++
-
- ;; "+" indicates parts where the pattern matched. A
- ;; "hole" in the middle of the string is indicated by
- ;; "-". Note that there are no "holes" near the edges
- ;; of the string. The completion score is a number
- ;; bound by (0..1] (i.e., larger than (but not equal
- ;; to) zero, and smaller or equal to one): the higher
- ;; the better and only a perfect match (pattern equals
- ;; string) will have score 1. The formula takes the
- ;; form of a quotient. For the numerator, we use the
- ;; number of +, i.e. the length of the pattern. For
- ;; the denominator, it first computes
- ;;
- ;; hole_i_contrib = 1 + (Li-1)^(1/tightness)
- ;;
- ;; , for each hole "i" of length "Li", where tightness
- ;; is given by `flex-score-match-tightness'. The
- ;; final value for the denominator is then given by:
- ;;
- ;; (SUM_across_i(hole_i_contrib) + 1) * len
- ;;
- ;; , where "len" is the string's length.
- (score-numerator 0)
- (score-denominator 0)
- (last-b 0)
- (update-score-and-face
- (lambda (a b)
- "Update score and face given match range (A B)."
- (add-face-text-property a b
- 'completions-common-part
- nil str)
- (setq
- score-numerator (+ score-numerator (- b a)))
- (unless (or (= a last-b)
- (zerop last-b)
- (= a (length str)))
- (setq
- score-denominator (+ score-denominator
- 1
- (expt (- a last-b 1)
- (/ 1.0
- flex-score-match-tightness)))))
- (setq
- last-b b))))
- (while md
- (funcall update-score-and-face from (pop md))
- (setq from (pop md)))
- ;; If `pattern' doesn't have an explicit trailing any, the
- ;; regex `re' won't produce match data representing the
- ;; region after the match. We need to account to account
- ;; for that extra bit of match (bug#42149).
- (unless (= from match-end)
- (funcall update-score-and-face from match-end))
- (if (> (length str) pos)
- (add-face-text-property
- pos (1+ pos)
- 'completions-first-difference
- nil str))
- (unless (zerop (length str))
- (put-text-property
- 0 1 'completion-score
- (/ score-numerator (* end (1+ score-denominator)) 1.0) str)))
- str)
- completions)))
+ (score-maybe (lambda (str)
+ (unless (get-text-property 0 'completion-score str)
+ (put-text-property 0 1 'completion-score
+ (completion--flex-score str re)
+ str)))))
+ (cond (completion-lazy-hilit
+ (setq completion-lazy-hilit-fn
+ (lambda (str) (completion--hilit-from-re str re)))
+ (mapc score-maybe completions))
+ (t
+ (mapcar
+ (lambda (str)
+ (setq str (copy-sequence str))
+ (funcall score-maybe str)
+ (completion--hilit-from-re str re)
+ str)
+ completions)))))
(t completions)))
(defun completion-pcm--find-all-completions (string table pred point
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 25 Oct 2023 22:10:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 25 18:10:13 2023
Received: from localhost ([127.0.0.1]:60126 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qvm4p-0005Vo-6R
for submit <at> debbugs.gnu.org; Wed, 25 Oct 2023 18:10:13 -0400
Received: from mail-lj1-x234.google.com ([2a00:1450:4864:20::234]:58606)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1qvm4l-0005VA-EK
for 47711 <at> debbugs.gnu.org; Wed, 25 Oct 2023 18:10:09 -0400
Received: by mail-lj1-x234.google.com with SMTP id
38308e7fff4ca-2c50ec238aeso3430951fa.0
for <47711 <at> debbugs.gnu.org>; Wed, 25 Oct 2023 15:09:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1698271770; x=1698876570; darn=debbugs.gnu.org;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
bh=2xt/V143/RfG9EbJcu/uH/1YcJyVqErOPkMdg8V9P6c=;
b=CgSBRMJZpQmCkRqMNSIOJ5QXZw/LXFEmpIBUemzeohlplFIePtiBfmyopDWDifRtAR
+HKTjLMw34UeCY+/oNj64Obr52IQOeAd+Wv3F02SuMpAIEEfxVntGPtGgaYjznDJKY7h
pnrsmx9LLG/ji8AokFZ8+H9Ww624cVFTCsBuURF7hlGKysKg1tUdbUy4J1cx3df+4+Zp
Ty0pgFy2GdGAdP5qIY+s+Ttk84AZDO3h7baK8oqpG7F9MXRSDBt0MMRq/wRjuMpU1C08
E/NhfhRCcAla/fTOwlIBAKGeVrA/XUwnnMJcAz4UVpX6yS4gdt8bJM5D27ui4N0gAGkS
WuZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1698271770; x=1698876570;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=2xt/V143/RfG9EbJcu/uH/1YcJyVqErOPkMdg8V9P6c=;
b=YKqJtJKGM1AOHm9bcfQjfUdSQKCQwIsFTLn406NcGkqhQj7bwfDqs8KWXVa8hjdpF6
jDPVyQZovXVBWxCQaY9tr+ATdncdijnl8uUd9vwq3UOcksmnQ+YR7MYWg+GadT9DbV4+
G4dAVbne+t3Br1edErHpXMtF5JzjpmoHFhJsp8m5PviFOmIrfvU2+FF8unMzOUEdT/VT
aKODxDICUvKJ6sZDqm3l5KHdUjh7AD4GyvlGHhsAELjzWFHvtnn0YLM/+n5xq0aik0SF
hlrkREx8Rdibvcz5EMiKg3bOW+JXyXOP8K7hAtbYxUTbHweSZm06xfahG5Wt1Kzuo1CQ
1Q+A==
X-Gm-Message-State: AOJu0Yx2uLaKHyOCfmiA/IXyAFSXLqBisR+KgCzD1NjOppS3UcZMFgAE
o1wzoJD5HLwsU2BIdDvDw1kT1YWSkLGxKQ==
X-Google-Smtp-Source: AGHT+IFAoYKHiLNJYesK76hes3kcUkbkq4yWUSwbnvl6+4zsbJNAdi8mKgTm9MFKDl75+CakVT47vQ==
X-Received: by 2002:a2e:9882:0:b0:2c5:183d:42bf with SMTP id
b2-20020a2e9882000000b002c5183d42bfmr11454100ljj.45.1698271769869;
Wed, 25 Oct 2023 15:09:29 -0700 (PDT)
Received: from krug ([87.196.80.249]) by smtp.gmail.com with ESMTPSA id
y9-20020a7bcd89000000b00407efbc4361sm823824wmj.9.2023.10.25.15.09.28
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 25 Oct 2023 15:09:29 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2]
Add new `completion-filter-completions` API and deferred highlighting
In-Reply-To: <CALDnm52VJpM5L_NaCJz6vcJgH4XH4HgpFBChY4Tn-JuQpGC55g@HIDDEN>
(=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Wed, 25 Oct 2023
22:02:23 +0100")
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN>
<fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN>
<3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN>
<CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN>
<56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN>
<CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN>
<328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN>
<83fsvcbio7.fsf@HIDDEN>
<9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN>
<877cnafv39.fsf@HIDDEN> <jwv34xyk1dp.fsf-monnier+emacs@HIDDEN>
<CALDnm52VJpM5L_NaCJz6vcJgH4XH4HgpFBChY4Tn-JuQpGC55g@HIDDEN>
Date: Wed, 25 Oct 2023 23:12:28 +0100
Message-ID: <8734xy73n7.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47711
Cc: Dmitry Gutov <dmitry@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
47711 <at> debbugs.gnu.org, Daniel Mendler <mail@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:
>> and then get rid of the hash-table altogether?
>
> Stefan, again we think alike, I'm taking care of that, the hash table
> and the gensym aren't needed at all.
Here's a revised patch without the hash table (actually a patch on top
of the other one, but I send the two of them again).
completion-lazy-hilit is simply bound in icomplete.el's
icomplete-exhibit.
I don't recall exactly why I used to set it in the hook to a gensym in
2021. I think it was because I was setting face properties on reused
strings (not just score) and that caused problems when switching
completion styles. But I don't think that can happen anymore, so no
need for that.
>> Hmm... in order to get the right result you need to call
>> `completion-lazy-hilit` sometime after calling
>> `completion-all-completions` and before the next call to
>> `completion-all-completions` done with the same value of
>> `completion-lazy-hilit`, right?
Right, it used to be something like that, but not anymore I think. Now
the semantics, could be described informally as
"called by the frontend in the hopes that the style got the hint,
which will speed things up significantly -- but if the hint wasn't
caught that's OK too".
>> How much more expensive is it to replace the=20
>> (mapc (lambda (str)
>> (put-text-property 0 1 'completion-score (funcall score str)=
str))
>> completions))
>> with something like
>> (let ((tail `(completion-lazy-hilit (completion--hilit-from-re ,re))=
))
>> (mapc (lambda (str)
>> (add-text-properties
>> 0 1 `(completion-score ,(funcall score str) ,@tail) str))
>> completions))
I get the idea, I think but I think it would be somewhat more expensive,
at it is similar to my earlier patch which stored more stuff in every
string which Dmitry (and then I) measured to be slower. But feel free
to experiment, of course.
Jo=C3=A3o
--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
filename=0001-Allow-completion-frontends-to-highlight-completion-s.patch
From 09ac2a87cb95d31acdefa3b4920449da2cb848fb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Wed, 25 Oct 2023 13:45:01 +0100
Subject: [PATCH 1/2] Allow completion frontends to highlight completion
strings just-in-time
This allows completion-pcm--hilit-commonality to be sped up
substantially.
Introduce a new variable completion-lazy-hilit that allows for
completion frontends to opt-in an time-saving optimization by some
completions styles, such as the 'flex' and 'pcm' styles.
The variable must be bound or set by the frontend to a unique value
around a completion attempt/session. See completion-lazy-hilit
docstring for more info.
* lisp/icomplete.el (icomplete-minibuffer-setup): Set completion-lazy-hilit.
(icomplete--render-vertical): Call completion-lazy-hilit.
(icomplete-completions): Call completion-lazy-hilit.
* lisp/minibuffer.el (completion-lazy-hilit): New variable.
(completion-lazy-hilit)
(completion--hilit-from-re): New functions.
(completion--lazy-hilit-table): New variable.
(completion--flex-score-1): New helper.
(completion-pcm--hilit-commonality): Use completion-lazy-hilit.
---
lisp/icomplete.el | 9 +-
lisp/minibuffer.el | 262 +++++++++++++++++++++++++++++----------------
2 files changed, 173 insertions(+), 98 deletions(-)
diff --git a/lisp/icomplete.el b/lisp/icomplete.el
index e6fdd1f1836..a9ac0b3f040 100644
--- a/lisp/icomplete.el
+++ b/lisp/icomplete.el
@@ -545,6 +545,7 @@ icomplete-minibuffer-setup
(setq-local icomplete--initial-input (icomplete--field-string))
(setq-local completion-show-inline-help nil)
(setq icomplete--scrolled-completions nil)
+ (setq completion-lazy-hilit (cl-gensym))
(use-local-map (make-composed-keymap icomplete-minibuffer-map
(current-local-map)))
(add-hook 'post-command-hook #'icomplete-post-command-hook nil t)
@@ -754,12 +755,13 @@ icomplete-exhibit
(overlay-end rfn-eshadow-overlay)))
(let* ((field-string (icomplete--field-string))
(text (while-no-input
+ (benchmark-progn
(icomplete-completions
field-string
(icomplete--completion-table)
(icomplete--completion-predicate)
(if (window-minibuffer-p)
- (eq minibuffer--require-match t)))))
+ (eq minibuffer--require-match t))))))
(buffer-undo-list t)
deactivate-mark)
;; Do nothing if while-no-input was aborted.
@@ -901,7 +903,7 @@ icomplete--render-vertical
'icomplete-selected-match 'append comp)
collect (concat prefix
(make-string (- max-prefix-len (length prefix)) ? )
- comp
+ (completion-lazy-hilit comp)
(make-string (- max-comp-len (length comp)) ? )
suffix)
into lines-aux
@@ -1067,7 +1069,8 @@ icomplete-completions
(if (< prospects-len prospects-max)
(push comp prospects)
(setq limit t)))
- (setq prospects (nreverse prospects))
+ (setq prospects
+ (nreverse (mapcar #'completion-lazy-hilit prospects)))
;; Decorate first of the prospects.
(when prospects
(let ((first (copy-sequence (pop prospects))))
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 2120e31775e..4591f1145c8 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -3749,108 +3749,180 @@ flex-score-match-tightness
than the latter (which has two \"holes\" and three
one-letter-long matches).")
+(defvar-local completion-lazy-hilit nil
+ "If non-nil, request completion lazy hilighting.
+
+Completion-presenting frontends may opt to bind this variable to
+a unique non-nil value in the context of completion-producing
+calls (such as `completion-all-sorted-completions'). This hints
+the intervening completion styles that they do not need to
+propertize completion strings with the `face' property.
+
+When doing so, it is the frontend -- not the style -- who becomes
+responsible for `face'-propertizing only the completion strings
+that are meant to be displayed to the user. This can be done by
+calling the function `completion-lazy-hilit' which returns a
+`face'-propertized string.
+
+The value stored in this variable by the completion frontend
+should be unique to each completion attempt or session that
+utilizes the same completion style in `completion-styles-alist'.
+For frontends using the minibuffer as the locus of completion
+calls and display, setting it to a buffer-local value given by
+`gensym' is appropriate. For frontends operating entirely in a
+single command, let-binding it to `gensym' is appropriate.
+
+Note that the optimization enabled by variable is only actually
+performed some completions styles. To others, it is a harmless
+and useless hint. To author a completion style that takes
+advantage of this, look in the source of
+`completion-pcm--hilit-commonality'.")
+
+(defun completion-lazy-hilit (str)
+ "Return a copy of completion STR that is `face'-propertized.
+See documentation for variable `completion-lazy-hilit' for more
+details."
+ (completion--hilit-from-re
+ (copy-sequence str)
+ (gethash completion-lazy-hilit completion--lazy-hilit-table)))
+
+(defun completion--hilit-from-re (string regexp)
+ "Fontify STRING with `completions-common-part' using REGEXP."
+ (let* ((md (and regexp (string-match regexp string) (cddr (match-data t))))
+ (me (and md (match-end 0)))
+ (from 0))
+ (while md
+ (add-face-text-property from (pop md) 'completions-common-part nil string)
+ (setq from (pop md)))
+ (unless (or (not me) (= from me))
+ (add-face-text-property from me 'completions-common-part nil string))
+ string))
+
+(defun completion--flex-score-1 (md match-end len)
+ "Compute matching score of completion.
+The score lies in the range between 0 and 1, where 1 corresponds to
+the full match.
+MD is the match data.
+MATCH-END is the end of the match.
+LEN is the length of the completion string."
+ (let* ((from 0)
+ ;; To understand how this works, consider these simple
+ ;; ascii diagrams showing how the pattern "foo"
+ ;; flex-matches "fabrobazo", "fbarbazoo" and
+ ;; "barfoobaz":
+
+ ;; f abr o baz o
+ ;; + --- + --- +
+
+ ;; f barbaz oo
+ ;; + ------ ++
+
+ ;; bar foo baz
+ ;; +++
+
+ ;; "+" indicates parts where the pattern matched. A
+ ;; "hole" in the middle of the string is indicated by
+ ;; "-". Note that there are no "holes" near the edges
+ ;; of the string. The completion score is a number
+ ;; bound by (0..1] (i.e., larger than (but not equal
+ ;; to) zero, and smaller or equal to one): the higher
+ ;; the better and only a perfect match (pattern equals
+ ;; string) will have score 1. The formula takes the
+ ;; form of a quotient. For the numerator, we use the
+ ;; number of +, i.e. the length of the pattern. For
+ ;; the denominator, it first computes
+ ;;
+ ;; hole_i_contrib = 1 + (Li-1)^(1/tightness)
+ ;;
+ ;; , for each hole "i" of length "Li", where tightness
+ ;; is given by `flex-score-match-tightness'. The
+ ;; final value for the denominator is then given by:
+ ;;
+ ;; (SUM_across_i(hole_i_contrib) + 1) * len
+ ;;
+ ;; , where "len" is the string's length.
+ (score-numerator 0)
+ (score-denominator 0)
+ (last-b 0))
+ (while md
+ (let ((a from)
+ (b (pop md)))
+ (setq
+ score-numerator (+ score-numerator (- b a)))
+ (unless (or (= a last-b)
+ (zerop last-b)
+ (= a len))
+ (setq
+ score-denominator (+ score-denominator
+ 1
+ (expt (- a last-b 1)
+ (/ 1.0
+ flex-score-match-tightness)))))
+ (setq
+ last-b b))
+ (setq from (pop md)))
+ ;; If `pattern' doesn't have an explicit trailing any, the
+ ;; regex `re' won't produce match data representing the
+ ;; region after the match. We need to account to account
+ ;; for that extra bit of match (bug#42149).
+ (unless (= from match-end)
+ (let ((a from)
+ (b match-end))
+ (setq
+ score-numerator (+ score-numerator (- b a)))
+ (unless (or (= a last-b)
+ (zerop last-b)
+ (= a len))
+ (setq
+ score-denominator (+ score-denominator
+ 1
+ (expt (- a last-b 1)
+ (/ 1.0
+ flex-score-match-tightness)))))
+ (setq
+ last-b b)))
+ (/ score-numerator (* len (1+ score-denominator)) 1.0)))
+
+(defvar completion--lazy-hilit-table (make-hash-table :weakness 'key))
+
(defun completion-pcm--hilit-commonality (pattern completions)
"Show where and how well PATTERN matches COMPLETIONS.
PATTERN, a list of symbols and strings as seen
`completion-pcm--merge-completions', is assumed to match every
-string in COMPLETIONS. Return a deep copy of COMPLETIONS where
-each string is propertized with `completion-score', a number
-between 0 and 1, and with faces `completions-common-part',
-`completions-first-difference' in the relevant segments."
+string in COMPLETIONS.
+
+If `completion-lazy-hilit' is nil, return a deep copy of
+COMPLETIONS where each string is propertized with
+`completion-score', a number between 0 and 1, and with faces
+`completions-common-part', `completions-first-difference' in the
+relevant segments.
+
+Else, if `completion-lazy-hilit' is t, return COMPLETIONS where
+each string now has a `completion-score' property and no
+highlighting."
(cond
((and completions (cl-loop for e in pattern thereis (stringp e)))
(let* ((re (completion-pcm--pattern->regex pattern 'group))
- (point-idx (completion-pcm--pattern-point-idx pattern))
- (case-fold-search completion-ignore-case)
- last-md)
- (mapcar
- (lambda (str)
- ;; Don't modify the string itself.
- (setq str (copy-sequence str))
- (unless (string-match re str)
- (error "Internal error: %s does not match %s" re str))
- (let* ((pos (if point-idx (match-beginning point-idx) (match-end 0)))
- (match-end (match-end 0))
- (md (cddr (setq last-md (match-data t last-md))))
- (from 0)
- (end (length str))
- ;; To understand how this works, consider these simple
- ;; ascii diagrams showing how the pattern "foo"
- ;; flex-matches "fabrobazo", "fbarbazoo" and
- ;; "barfoobaz":
-
- ;; f abr o baz o
- ;; + --- + --- +
-
- ;; f barbaz oo
- ;; + ------ ++
-
- ;; bar foo baz
- ;; +++
-
- ;; "+" indicates parts where the pattern matched. A
- ;; "hole" in the middle of the string is indicated by
- ;; "-". Note that there are no "holes" near the edges
- ;; of the string. The completion score is a number
- ;; bound by (0..1] (i.e., larger than (but not equal
- ;; to) zero, and smaller or equal to one): the higher
- ;; the better and only a perfect match (pattern equals
- ;; string) will have score 1. The formula takes the
- ;; form of a quotient. For the numerator, we use the
- ;; number of +, i.e. the length of the pattern. For
- ;; the denominator, it first computes
- ;;
- ;; hole_i_contrib = 1 + (Li-1)^(1/tightness)
- ;;
- ;; , for each hole "i" of length "Li", where tightness
- ;; is given by `flex-score-match-tightness'. The
- ;; final value for the denominator is then given by:
- ;;
- ;; (SUM_across_i(hole_i_contrib) + 1) * len
- ;;
- ;; , where "len" is the string's length.
- (score-numerator 0)
- (score-denominator 0)
- (last-b 0)
- (update-score-and-face
- (lambda (a b)
- "Update score and face given match range (A B)."
- (add-face-text-property a b
- 'completions-common-part
- nil str)
- (setq
- score-numerator (+ score-numerator (- b a)))
- (unless (or (= a last-b)
- (zerop last-b)
- (= a (length str)))
- (setq
- score-denominator (+ score-denominator
- 1
- (expt (- a last-b 1)
- (/ 1.0
- flex-score-match-tightness)))))
- (setq
- last-b b))))
- (while md
- (funcall update-score-and-face from (pop md))
- (setq from (pop md)))
- ;; If `pattern' doesn't have an explicit trailing any, the
- ;; regex `re' won't produce match data representing the
- ;; region after the match. We need to account to account
- ;; for that extra bit of match (bug#42149).
- (unless (= from match-end)
- (funcall update-score-and-face from match-end))
- (if (> (length str) pos)
- (add-face-text-property
- pos (1+ pos)
- 'completions-first-difference
- nil str))
- (unless (zerop (length str))
- (put-text-property
- 0 1 'completion-score
- (/ score-numerator (* end (1+ score-denominator)) 1.0) str)))
- str)
- completions)))
+ last-md
+ (score (lambda (str)
+ (unless (string-match re str)
+ (error "Internal error: %s does not match %s" re str))
+ (let* ((match-end (match-end 0))
+ (md (cddr (setq last-md (match-data t last-md)))))
+ (completion--flex-score-1 md match-end (length str))))))
+ (cond (completion-lazy-hilit
+ (puthash completion-lazy-hilit re completion--lazy-hilit-table)
+ (mapc (lambda (str)
+ (put-text-property 0 1 'completion-score (funcall score str) str))
+ completions))
+ (t
+ (mapcar
+ (lambda (str)
+ (setq str (copy-sequence str))
+ (put-text-property 0 1 'completion-score (funcall score str) str)
+ (completion--hilit-from-re str re)
+ str)
+ completions)))))
(t completions)))
(defun completion-pcm--find-all-completions (string table pred point
--
2.39.2
--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
filename=0002-Replace-lazy-hilit-hash-table-with-something-simpler.patch
From 5c4449dc578903314f400461d13c4c08e02a18ef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Wed, 25 Oct 2023 22:36:15 +0100
Subject: [PATCH 2/2] Replace lazy hilit hash table with something simpler
* lisp/icomplete.el (icomplete-minibuffer-setup): Don't set
completion-lazy-hilit.
(icomplete-exhibit): Set it here.
* lisp/minibuffer.el (completion-lazy-hilit): Rework docstring.
(completion-lazy-hilit-fn): Rework from completion--lazy-hilit-re.
(completion--lazy-hilit-table): Delete.
(completion-pcm--hilit-commonality): Rework.
---
lisp/icomplete.el | 4 ++--
lisp/minibuffer.el | 42 +++++++++++++++++++++---------------------
2 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/lisp/icomplete.el b/lisp/icomplete.el
index a9ac0b3f040..3e888c8b06a 100644
--- a/lisp/icomplete.el
+++ b/lisp/icomplete.el
@@ -545,7 +545,6 @@ icomplete-minibuffer-setup
(setq-local icomplete--initial-input (icomplete--field-string))
(setq-local completion-show-inline-help nil)
(setq icomplete--scrolled-completions nil)
- (setq completion-lazy-hilit (cl-gensym))
(use-local-map (make-composed-keymap icomplete-minibuffer-map
(current-local-map)))
(add-hook 'post-command-hook #'icomplete-post-command-hook nil t)
@@ -723,7 +722,8 @@ icomplete-exhibit
;; Check if still in the right buffer (bug#61308)
(or (window-minibuffer-p) completion-in-region--data)
(icomplete-simple-completing-p)) ;Shouldn't be necessary.
- (let ((saved-point (point)))
+ (let ((saved-point (point))
+ (completion-lazy-hilit t))
(save-excursion
(goto-char (icomplete--field-end))
;; Insert the match-status information:
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 4591f1145c8..4a727615afb 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1234,6 +1234,7 @@ completion-all-completions
POINT is the position of point within STRING.
The return value is a list of completions and may contain the base-size
in the last `cdr'."
+ (setq completion-lazy-hilit-fn nil)
;; FIXME: We need to additionally return the info needed for the
;; second part of completion-base-position.
(completion--nth-completion 2 string table pred point metadata))
@@ -3753,24 +3754,16 @@ completion-lazy-hilit
"If non-nil, request completion lazy hilighting.
Completion-presenting frontends may opt to bind this variable to
-a unique non-nil value in the context of completion-producing
-calls (such as `completion-all-sorted-completions'). This hints
-the intervening completion styles that they do not need to
-propertize completion strings with the `face' property.
+non-nil value in the context of completion-producing calls (such
+as `completion-all-sorted-completions'). This hints the
+intervening completion styles that they do not need to propertize
+completion strings with the `face' property.
When doing so, it is the frontend -- not the style -- who becomes
responsible for `face'-propertizing only the completion strings
-that are meant to be displayed to the user. This can be done by
-calling the function `completion-lazy-hilit' which returns a
-`face'-propertized string.
-
-The value stored in this variable by the completion frontend
-should be unique to each completion attempt or session that
-utilizes the same completion style in `completion-styles-alist'.
-For frontends using the minibuffer as the locus of completion
-calls and display, setting it to a buffer-local value given by
-`gensym' is appropriate. For frontends operating entirely in a
-single command, let-binding it to `gensym' is appropriate.
+that are meant to be displayed to the user. This is done by
+calling `completion-lazy-hilit' on each such string, which
+produces the suitably propertized string.
Note that the optimization enabled by variable is only actually
performed some completions styles. To others, it is a harmless
@@ -3778,13 +3771,21 @@ completion-lazy-hilit
advantage of this, look in the source of
`completion-pcm--hilit-commonality'.")
+(defvar completion-lazy-hilit-fn nil
+ "Used by completions styles to honouring `completion-lazy-hilit'.
+When a given style wants to enable support for
+`completion-lazy-hilit' (which see), that style should set this
+variable to a function of one argument, a fresh string to be
+displayed to the user. The function is responsible for
+destructively highlighting the string.")
+
(defun completion-lazy-hilit (str)
"Return a copy of completion STR that is `face'-propertized.
See documentation for variable `completion-lazy-hilit' for more
details."
- (completion--hilit-from-re
- (copy-sequence str)
- (gethash completion-lazy-hilit completion--lazy-hilit-table)))
+ (if (and completion-lazy-hilit completion-lazy-hilit-fn)
+ (funcall completion-lazy-hilit-fn (copy-sequence str))
+ str))
(defun completion--hilit-from-re (string regexp)
"Fontify STRING with `completions-common-part' using REGEXP."
@@ -3883,8 +3884,6 @@ completion--flex-score-1
last-b b)))
(/ score-numerator (* len (1+ score-denominator)) 1.0)))
-(defvar completion--lazy-hilit-table (make-hash-table :weakness 'key))
-
(defun completion-pcm--hilit-commonality (pattern completions)
"Show where and how well PATTERN matches COMPLETIONS.
PATTERN, a list of symbols and strings as seen
@@ -3911,7 +3910,8 @@ completion-pcm--hilit-commonality
(md (cddr (setq last-md (match-data t last-md)))))
(completion--flex-score-1 md match-end (length str))))))
(cond (completion-lazy-hilit
- (puthash completion-lazy-hilit re completion--lazy-hilit-table)
+ (setq completion-lazy-hilit-fn
+ (lambda (str) (completion--hilit-from-re str re)))
(mapc (lambda (str)
(put-text-property 0 1 'completion-score (funcall score str) str))
completions))
--
2.39.2
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 25 Oct 2023 21:03:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 25 17:03:16 2023 Received: from localhost ([127.0.0.1]:60092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qvl23-0003hO-Pu for submit <at> debbugs.gnu.org; Wed, 25 Oct 2023 17:03:16 -0400 Received: from mail-lf1-x12d.google.com ([2a00:1450:4864:20::12d]:43160) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1qvl20-0003h6-FM for 47711 <at> debbugs.gnu.org; Wed, 25 Oct 2023 17:03:13 -0400 Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-507cd62472dso1561185e87.0 for <47711 <at> debbugs.gnu.org>; Wed, 25 Oct 2023 14:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698267756; x=1698872556; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JfcW8JLeZdcyrJSidN03v1iRReLwPwtvQD2QZCkEWRE=; b=V+5Vp5epWdqcIbzb3o+g8YGqZwsQ54LBGpvZaqIbfmPrGWDzCw+pdxECBqlT7J6ppR IK0GK/I/z3Bcdh5zGPQWMXsG2ONyY0NM2DHfDzq5xV3NPPxLlnrF+H2zH8/1JStpr7LO htNcKGL4A+iYtPgEXXts899fbkthFDmFkYglMp5nGqyKgwG6z6amdvUYTJxv7Hb3ZVE/ hQPHD5xxTKksVSnms1XwFo4T3/sT8XEiM6GmLqEKLrf/R1a5mUrtPCF5giY4FE52oFjp AQF3RWDbx/00St2J8cHcHaxBuPg1OS2q2QXCt/pRwb8nO1boZkgft0xlg95BdMwPzx8j HaUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698267756; x=1698872556; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JfcW8JLeZdcyrJSidN03v1iRReLwPwtvQD2QZCkEWRE=; b=gbfT0XjU3Y4KV0XsoJGTewYThlzrnhdQkS4YClfmPletPHoAklhkudfbP5B3O22mNp fF8jA3uuFmpy7U2pD2ECMvTe6eiDsi45x5bMQqhRGTbV61v/9BT/4t1Zzlue+0RcanQ+ 1ieh2HzMF3YirhZXOCwrtC2766d6yxt3+wKKFXqc95qVtk+flClQXk8VnNjYVHxhQHoA YGEb+Say25cEck/vVHXU0vo4TwLr+27qettKgD4/hTFCkrTWjQcGqji7evdZIxm6MG3T pklu5mY8AWbJjmcLNc/QMpMjeITKeF8tZiJshzYQIH7cWLv28B5/ug1LgbLA6DrKXiG8 J1DQ== X-Gm-Message-State: AOJu0Yx6tgGLyC1bStuVP6aoXHgvJ7ohRU2joiG8f9cytsrHL+8bjJCs Z7UtqB44pxwVfnqcvZpJnccu+qu8uMBn8CRam9A= X-Google-Smtp-Source: AGHT+IHJ1sXm7rLgEQESxhOU33A9K0JzqoJcMCqlncPvg4uX59ca/iMhjG4YaaxGEmp8OqmBfKy8/2IFxaTpa/HPd9g= X-Received: by 2002:a05:6512:3481:b0:4fb:a088:cfca with SMTP id v1-20020a056512348100b004fba088cfcamr220430lfr.6.1698267755890; Wed, 25 Oct 2023 14:02:35 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN> <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> <877cnafv39.fsf@HIDDEN> <jwv34xyk1dp.fsf-monnier+emacs@HIDDEN> In-Reply-To: <jwv34xyk1dp.fsf-monnier+emacs@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Wed, 25 Oct 2023 22:02:23 +0100 Message-ID: <CALDnm52VJpM5L_NaCJz6vcJgH4XH4HgpFBChY4Tn-JuQpGC55g@HIDDEN> Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Stefan Monnier <monnier@HIDDEN> Content-Type: multipart/alternative; boundary="00000000000052cc46060890c609" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Dmitry Gutov <dmitry@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 47711 <at> debbugs.gnu.org, Daniel Mendler <mail@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --00000000000052cc46060890c609 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 25, 2023, 21:52 Stefan Monnier <monnier@HIDDEN> wrote: > > > and then get rid of the hash-table altogether? > Stefan, again we think alike, I'm taking care of that, the hash table and the gensym aren't needed at all. > --00000000000052cc46060890c609 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D= "gmail_attr">On Wed, Oct 25, 2023, 21:52 Stefan Monnier <<a href=3D"mail= to:monnier@HIDDEN">monnier@HIDDEN</a>> wrote:<br></d= iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left= :1px #ccc solid;padding-left:1ex"><br> <br> and then get rid of the hash-table altogether?<br></blockquote></div></div>= <div dir=3D"auto"><br></div><div dir=3D"auto">Stefan,=C2=A0 again we think = alike, I'm taking care of that, the hash table and the gensym aren'= t needed at all.</div><div dir=3D"auto"><div class=3D"gmail_quote"><blockqu= ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s= olid;padding-left:1ex"> </blockquote></div></div></div> --00000000000052cc46060890c609--
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 25 Oct 2023 20:53:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 25 16:53:24 2023
Received: from localhost ([127.0.0.1]:60082 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qvksV-0003QV-U5
for submit <at> debbugs.gnu.org; Wed, 25 Oct 2023 16:53:24 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:22403)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qvksR-0003QD-Lw
for 47711 <at> debbugs.gnu.org; Wed, 25 Oct 2023 16:53:21 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E000D807D7;
Wed, 25 Oct 2023 16:52:43 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1698267163;
bh=7jfyvYecg45dKiMOO9dMhSmhBvK337JaISVMh9levfA=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=dIfTjaUuyl/J91ukl5HWcD7CNJQAiovNyu8JyEWMDZVgw2RaaT1M7MMFTpEFdNUWJ
L4btcqrgYTvmd5vAxeaq9sM1+KYKohVPMqjdcQllYPKgfJ4twnJbOI3MAOmE1cxQ9u
2K35nwRKUW0ga360s63EGMHQxr3w4An/Bt1yIK3Vvw/AiES5yuXRM6OXKE7nZUw7mr
KvIylc9GsEZyDzeJlayXplKsyMdkGUDjfh/btMQnSN36ut5iJakGMf1fcHfwZNPJNN
XFvKjHZ9Sif5DpOeEeRCNsJazok2Rq3hVevMdiuA/8Mtmw40m40ay4Q05qNh4wird2
Qj5zYTAMm+RoA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0F24480409;
Wed, 25 Oct 2023 16:52:43 -0400 (EDT)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id ED26C120446;
Wed, 25 Oct 2023 16:52:42 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2]
Add new `completion-filter-completions` API and deferred highlighting
In-Reply-To: <877cnafv39.fsf@HIDDEN> (=?windows-1252?Q?=22Jo=E3o_T=E1vo?=
=?windows-1252?Q?ra=22's?= message of "Wed, 25
Oct 2023 18:52:26 +0100")
Message-ID: <jwv34xyk1dp.fsf-monnier+emacs@HIDDEN>
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN>
<fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN>
<3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN>
<CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN>
<56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN>
<CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN>
<328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN>
<83fsvcbio7.fsf@HIDDEN>
<9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN>
<877cnafv39.fsf@HIDDEN>
Date: Wed, 25 Oct 2023 16:50:29 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.069 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47711
Cc: Dmitry Gutov <dmitry@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
47711 <at> debbugs.gnu.org, Daniel Mendler <mail@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
This sounds fairly reasonable: the worst-case breakage seems to be that
we may occasionally lose highlighting because the var was non-nil at the
wrong time.
Sidenote: since the hash-table uses `eq` we don't need to use `gensym`,
we can use something like `cons` instead, which is cheaper and doesn't
risk making its way into the `obarray`.
> +(defun completion-lazy-hilit (str)
> + "Return a copy of completion STR that is `face'-propertized.
> +See documentation for variable `completion-lazy-hilit' for more
> +details."
> + (completion--hilit-from-re
> + (copy-sequence str)
> + (gethash completion-lazy-hilit completion--lazy-hilit-table)))
Hmm... in order to get the right result you need to call
`completion-lazy-hilit` sometime after calling
`completion-all-completions` and before the next call to
`completion-all-completions` done with the same value of
`completion-lazy-hilit`, right?
So how important is it to use a hash-table rather than a variable
holding just "the info about the last call to
`completion-all-completions`"?
> + last-md
> + (score (lambda (str)
> + (unless (string-match re str)
> + (error "Internal error: %s does not match %s" re str))
> + (let* ((match-end (match-end 0))
> + (md (cddr (setq last-md (match-data t last-md)))))
> + (completion--flex-score-1 md match-end (length str))))))
> + (cond (completion-lazy-hilit
> + (puthash completion-lazy-hilit re completion--lazy-hilit-table)
> + (mapc (lambda (str)
> + (put-text-property 0 1 'completion-score (funcall score str) str))
> + completions))
> + (t
> + (mapcar
> + (lambda (str)
> + (setq str (copy-sequence str))
> + (put-text-property 0 1 'completion-score (funcall score str) str)
> + (completion--hilit-from-re str re)
> + str)
> + completions)))))
How much more expensive is it to replace the
(mapc (lambda (str)
(put-text-property 0 1 'completion-score (funcall score str) str))
completions))
with something like
(let ((tail `(completion-lazy-hilit (completion--hilit-from-re ,re))))
(mapc (lambda (str)
(add-text-properties
0 1 `(completion-score ,(funcall score str) ,@tail) str))
completions))
and then get rid of the hash-table altogether?
Stefan
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 25 Oct 2023 17:50:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 25 13:50:08 2023
Received: from localhost ([127.0.0.1]:59988 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qvi19-0006i7-IU
for submit <at> debbugs.gnu.org; Wed, 25 Oct 2023 13:50:08 -0400
Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]:49496)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1qvi16-0006hW-U3
for 47711 <at> debbugs.gnu.org; Wed, 25 Oct 2023 13:50:06 -0400
Received: by mail-lf1-x12b.google.com with SMTP id
2adb3069b0e04-507973f3b65so9348028e87.3
for <47711 <at> debbugs.gnu.org>; Wed, 25 Oct 2023 10:49:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1698256168; x=1698860968; darn=debbugs.gnu.org;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
bh=Ou2MdSGN8mbsbFxdlism4aJhgGQ+7nM75bj4PCHKhQ8=;
b=R7f+pw6+66h0/y3BTW3wkQaQcAqBAKMhhn2ydTVaaCtNtAf7MD0lwDwsMysAoULnAE
jq4oQ02GpnFniVED5fmxxdjVTarqmoyqzrYda3FSpOkIYLjZLGH4GsGpqNvAnWbhYqqM
zwAYiCh9d/58KEXs8XGpxX+kgfVK/IMGtkApdiFG0EfAHLA5XK1Wg7jIfFJJanLZi+Wf
VBboG4JdYM9K3PoFdmpME0T7G5De9LVYNBnUOLRkD2+ZBYQ5+5865YrQd9oEX6ijBgsd
VtOeBuK95fbmXH92ZtC/JtEOsonMKQC6w+xePHytLvHIFlzyhCQUQuuOmN3etlC7fC4W
OcNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1698256168; x=1698860968;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=Ou2MdSGN8mbsbFxdlism4aJhgGQ+7nM75bj4PCHKhQ8=;
b=WtEAFP79EY7rXu/yG/FHwdI3ME9DQR1DqnYtyo4DSwfy4kjhbt39rnJeC1FxHttKrn
WOzfRo2o4cMNo/Bh5yvsiiMEOLCYWAf2xiR8glOo6DJxgGYPVOk40zPTkjRrc3oyIxwZ
9IsUOjfiBWggbDoocyD3FSfvnRWS8pn3Vru9dC4W9qyRKZwZg8acPIf5+NRH7mcMMzlC
M7mE1/nTJAPzDA5gYDfz9TY2PhzGfGRZqYUFMzvxJx1lU391qsxoLVnt3fGiTYpkSeF+
P+TGj+UNIZ6tbjrTZzRgSb4v4jQbL6kO7oQ1IPZkwwNwiR8QGTCitILh2c9OhgHIokN1
tpLg==
X-Gm-Message-State: AOJu0Yx0ClAkMcM0pLl6znjACpdsToNTh4/NdS6/GFOZEK+eJCZNsErL
zKfXHhPM1JNWBoSG0sMEHxUPZhSwBkN/3A==
X-Google-Smtp-Source: AGHT+IHg4CoUBR3qp+4pe2jgjlsWkWe4zOvlmMTGi5bX6McJ1SZhMlIZg3pG/VWZ+ZnRkfK6Udyezw==
X-Received: by 2002:ac2:58d9:0:b0:500:b9f3:1dc4 with SMTP id
u25-20020ac258d9000000b00500b9f31dc4mr10062734lfo.68.1698256167323;
Wed, 25 Oct 2023 10:49:27 -0700 (PDT)
Received: from krug ([87.196.80.249]) by smtp.gmail.com with ESMTPSA id
c20-20020a056512325400b00507a387c4c4sm2652524lfr.229.2023.10.25.10.49.25
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 25 Oct 2023 10:49:26 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Dmitry Gutov <dmitry@HIDDEN>
Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2]
Add new `completion-filter-completions` API and deferred highlighting
In-Reply-To: <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN> (Dmitry Gutov's
message of "Wed, 25 Oct 2023 01:25:23 +0300")
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN>
<fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN>
<3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN>
<CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN>
<56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN>
<CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN>
<328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN>
<83fsvcbio7.fsf@HIDDEN>
<9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN>
Date: Wed, 25 Oct 2023 18:52:26 +0100
Message-ID: <877cnafv39.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47711
Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Dmitry Gutov <dmitry@HIDDEN> writes:
> Hi all!
>
> Time flies, doesn't it?
Indeed. First, thanks for working on this. I tried your patches and
could reproduce all your numbers with a recent master (643c67cf239).
After checking the 2021 version again (254dc6ab4) I've discovered that
2023 Emacs doesn't respond as well to the lazy-hilit patch as 2021
Emacs. It's as if the cost of string copies (that the patch optimized)
has gone down significantly. In addition, in 2021, we never had anyone
perform the needed changes for icomplete.el to work with Daniel's API.
It was only known that without those changes, icomplete.el actually
performed worse under the new patch
So, backed by the new ability to conduct good benchmarks, I looked at
the problem anew. I found some insight in the problem, and came up with
a new "lazy-hilit" patch which performs just as well, if not slightly
better, than Daniel's, while keeping the changes to lisp/minibuffer.el
much more minimal and not adding replacement for the longstanding
completion-all-completions.
Before I go into benchmarks, it's obvious to me that "lazy" or
"deferred" highlighting mean basically the same thing, which is "late"
or "just-in-time" highlighting.
I also think, as I did in 2021, that we should be careful to separate
what are performance-motivated changes from style-motivated changes.
The former are easy to discuss objectively, while the latter are much,
much more subjective.
Whatever the outcome, we're on our way to at least a faster
icomplete.el, which is of course good.
So here are the benchmarks. The setup is the following, we start Emacs
like:
src/emacs -nw -Q -f fido-vertical-mode -l ~/Downloads/benchmark.el
And make sure to put 300 000 symbols in the obarray. The symbols are
prefixed "yoyo" deliberately.
(cl-loop repeat 300000 do (intern (symbol-name (gensym "yoyo"))))
First a micro-benchmark:
;; Daniel's patch worked by Dmitry (v3)
(benchmark-run 50
(let ((completion-styles '(flex)))
(completion-filter-completions "" obarray 'fboundp 0 nil)
(completion-filter-completions "yo" obarray 'fboundp 0 nil)
(completion-filter-completions "yoo" obarray 'fboundp 0 nil)
));; =3D> (12.192422429999999 3 0.107881004)
;; lazy-hilit v4 patch attached in this email
(benchmark-run 50
(let ((completion-styles '(flex))
(completion-lazy-hilit (cl-gensym)))
(completion-all-completions "" obarray 'fboundp 0 nil)
(completion-all-completions "yo" obarray 'fboundp 0 nil)
(completion-all-completions "yoo" obarray 'fboundp 0 nil)
));; =3D> (12.267915333 4 0.14799709099999991)
Now, tests specific to icomplete.el using Dmitry's instrumentation.
This is the "yoyo" test. Evaluate:
(completing-read "" obarray)
This starts a fido-vertical-mode minibuffer. First type "yo", then
repeatedly insert and backspace a "o" to make "yoo" and "yo" in
alternating fashion.
The number of matches should be exactly 300696 for "yoo" and 301721 for
"yo". Highlighting should be correct, of course.
Observe the results printed by the instrumentation in `icomplete.el`.
Collect them from *Messages* after 18 alternations.
The results:
;; with Daniel's patch to minibuffer
;;=20
;; Elapsed time: 0.967481s (0.401923s in 8 GCs)
;; Elapsed time: 0.703229s (0.252157s in 5 GCs)
;; Elapsed time: 0.945053s (0.401540s in 8 GCs)
;; Elapsed time: 0.721198s (0.252657s in 5 GCs)
;; Elapsed time: 0.951377s (0.394238s in 8 GCs)
;; Elapsed time: 0.699232s (0.254524s in 5 GCs)
;; Elapsed time: 0.940497s (0.400292s in 8 GCs)
;; Elapsed time: 0.709986s (0.253635s in 5 GCs)
;; Elapsed time: 0.943063s (0.399020s in 8 GCs)
;; Elapsed time: 0.720825s (0.251619s in 5 GCs)
;; Elapsed time: 0.972146s (0.407665s in 8 GCs)
;; Elapsed time: 0.709619s (0.255678s in 5 GCs)
;; Elapsed time: 0.947108s (0.397916s in 8 GCs)
;; Elapsed time: 0.727231s (0.254040s in 5 GCs)
;; Elapsed time: 0.966196s (0.398492s in 8 GCs)
;; Elapsed time: 0.701558s (0.252168s in 5 GCs)
;; Elapsed time: 0.936269s (0.388110s in 8 GCs)
;; Elapsed time: 0.694050s (0.249759s in 5 GCs)
;; with my lazy-hilit patch worked minimally by Dmitry
;;=20
;; Elapsed time: 1.779906s (0.975332s in 15 GCs)
;; Elapsed time: 1.342160s (0.490314s in 5 GCs)
;; Elapsed time: 1.235759s (0.420019s in 4 GCs)
;; Elapsed time: 1.363909s (0.519521s in 5 GCs)
;; Elapsed time: 1.175773s (0.423938s in 4 GCs)
;; Elapsed time: 1.340017s (0.508744s in 5 GCs)
;; Elapsed time: 1.124552s (0.404149s in 4 GCs)
;; Elapsed time: 1.327419s (0.499433s in 5 GCs)
;; Elapsed time: 1.121927s (0.400499s in 4 GCs)
;; Elapsed time: 1.308526s (0.493652s in 5 GCs)
;; Elapsed time: 1.159132s (0.404612s in 4 GCs)
;; Elapsed time: 1.323803s (0.500754s in 5 GCs)
;; Elapsed time: 1.128562s (0.406496s in 4 GCs)
;; Elapsed time: 1.345577s (0.503971s in 5 GCs)
;; Elapsed time: 1.121691s (0.401876s in 4 GCs)
;; Elapsed time: 1.304913s (0.492255s in 5 GCs)
;; Elapsed time: 1.141926s (0.399154s in 4 GCs)
;; Elapsed time: 1.312480s (0.498205s in 5 GCs)
;; Elapsed time: 1.125095s (0.403174s in 4 GCs)
;; Elapsed time: 1.332119s (0.503671s in 5 GCs)
;; Elapsed time: 1.131561s (0.402268s in 4 GCs)
;; New lazy-hilit patch attached:
;;
;; Elapsed time: 0.902985s (0.224307s in 3 GCs)
;; Elapsed time: 0.696391s (0.079687s in 1 GCs)
;; Elapsed time: 0.896176s (0.219964s in 3 GCs)
;; Elapsed time: 0.648318s (0.074765s in 1 GCs)
;; Elapsed time: 0.906288s (0.221534s in 3 GCs)
;; Elapsed time: 0.679141s (0.079102s in 1 GCs)
;; Elapsed time: 0.889320s (0.222668s in 3 GCs)
;; Elapsed time: 0.690199s (0.076926s in 1 GCs)
;; Elapsed time: 0.912206s (0.220297s in 3 GCs)
;; Elapsed time: 0.675524s (0.078875s in 1 GCs)
;; Elapsed time: 0.907111s (0.226627s in 3 GCs)
;; Elapsed time: 0.697139s (0.079571s in 1 GCs)
;; Elapsed time: 0.906650s (0.220946s in 3 GCs)
;; Elapsed time: 0.683808s (0.078001s in 1 GCs)
;; Elapsed time: 0.912471s (0.221977s in 3 GCs)
;; Elapsed time: 0.699742s (0.079009s in 1 GCs)
;; Elapsed time: 0.897566s (0.217786s in 3 GCs)
;; Elapsed time: 0.659043s (0.076046s in 1 GCs)
Daniel+Dmitry patch v3: 0.8308954444444444s avg
Old lazy-hilit patch: 1.2390678333333334s avg
New lazy-hilit patch attached: 0.7922265555555554s avg
In conclusion:
* I think the two approaches are basically evenly matched in terms of
performance, at least for this symbol completion scenario.
* In the completion-{sorted|all}-completions micro-benchmark my patch
does very marginally worse (0.6%). Probably because of the use of a
hash table. I believe I can fix this, though.
* In the icomplete.el usability test, my new patch probably does
slightly better (4.6%). Probably because it doesn't recalculate the
regexp from the pattern every time it needs to late highlight.
* My patch doesn't suffer from the 'completion--unquoted' property
complication in Daniel+Dmitry's patch." It's possible/likely that the
additional memory needed by this property will introduce an additional
slowdown which isn't visible in the simpler symbol completion
scenario.
Both patches propose what are effectively extensions to the large, old
and complicated completion API, in my case an additional variable to
bind (or set), in Daniel's patch a brand new API entry point and the
deprecation of an existing one.
The benchmarks show that Daniel's patch is not absolutely necessary to
reap the benefits of deferred/lazy/late/just-in-time highlighting.
Looking at the two patches side-by-side it seems evident to me that one
patch is much simpler than the other. The "maybe-alist-maybe-not" flag
dedicated to completely changing the meaning of a number of
minibuffer.el functions while keeping backward compatibility is one such
item of complexity.
Therefore, since we can come up with simpler alternatives that bring
these now well-understood benefits, it won't surprise anyone that I
think we should go for the simpler choice.
Jo=C3=A3o
--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
filename=0001-Allow-completion-frontends-to-highlight-completion-s.patch
From 78057f40e53f39f0b26f4b9bf5d950b72f1c3d99 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Wed, 25 Oct 2023 13:45:01 +0100
Subject: [PATCH] Allow completion frontends to highlight completion strings
just-in-time
This allows completion-pcm--hilit-commonality to be sped up
substantially.
Introduce a new variable completion-lazy-hilit that allows for
completion frontends to opt-in an time-saving optimization by some
completions styles, such as the 'flex' and 'pcm' styles.
The variable must be bound or set by the frontend to a unique value
around a completion attempt/session. See completion-lazy-hilit
docstring for more info.
* lisp/icomplete.el (icomplete-minibuffer-setup): Set completion-lazy-hilit.
(icomplete--render-vertical): Call completion-lazy-hilit.
(icomplete-completions): Call completion-lazy-hilit.
* lisp/minibuffer.el (completion-lazy-hilit): New variable.
(completion-lazy-hilit)
(completion--hilit-from-re): New functions.
(completion--lazy-hilit-table): New variable.
(completion--flex-score-1): New helper.
(completion-pcm--hilit-commonality): Use completion-lazy-hilit.
---
lisp/icomplete.el | 9 +-
lisp/minibuffer.el | 262 +++++++++++++++++++++++++++++----------------
2 files changed, 173 insertions(+), 98 deletions(-)
diff --git a/lisp/icomplete.el b/lisp/icomplete.el
index e6fdd1f1836..a9ac0b3f040 100644
--- a/lisp/icomplete.el
+++ b/lisp/icomplete.el
@@ -545,6 +545,7 @@ icomplete-minibuffer-setup
(setq-local icomplete--initial-input (icomplete--field-string))
(setq-local completion-show-inline-help nil)
(setq icomplete--scrolled-completions nil)
+ (setq completion-lazy-hilit (cl-gensym))
(use-local-map (make-composed-keymap icomplete-minibuffer-map
(current-local-map)))
(add-hook 'post-command-hook #'icomplete-post-command-hook nil t)
@@ -754,12 +755,13 @@ icomplete-exhibit
(overlay-end rfn-eshadow-overlay)))
(let* ((field-string (icomplete--field-string))
(text (while-no-input
+ (benchmark-progn
(icomplete-completions
field-string
(icomplete--completion-table)
(icomplete--completion-predicate)
(if (window-minibuffer-p)
- (eq minibuffer--require-match t)))))
+ (eq minibuffer--require-match t))))))
(buffer-undo-list t)
deactivate-mark)
;; Do nothing if while-no-input was aborted.
@@ -901,7 +903,7 @@ icomplete--render-vertical
'icomplete-selected-match 'append comp)
collect (concat prefix
(make-string (- max-prefix-len (length prefix)) ? )
- comp
+ (completion-lazy-hilit comp)
(make-string (- max-comp-len (length comp)) ? )
suffix)
into lines-aux
@@ -1067,7 +1069,8 @@ icomplete-completions
(if (< prospects-len prospects-max)
(push comp prospects)
(setq limit t)))
- (setq prospects (nreverse prospects))
+ (setq prospects
+ (nreverse (mapcar #'completion-lazy-hilit prospects)))
;; Decorate first of the prospects.
(when prospects
(let ((first (copy-sequence (pop prospects))))
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 2120e31775e..4591f1145c8 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -3749,108 +3749,180 @@ flex-score-match-tightness
than the latter (which has two \"holes\" and three
one-letter-long matches).")
+(defvar-local completion-lazy-hilit nil
+ "If non-nil, request completion lazy hilighting.
+
+Completion-presenting frontends may opt to bind this variable to
+a unique non-nil value in the context of completion-producing
+calls (such as `completion-all-sorted-completions'). This hints
+the intervening completion styles that they do not need to
+propertize completion strings with the `face' property.
+
+When doing so, it is the frontend -- not the style -- who becomes
+responsible for `face'-propertizing only the completion strings
+that are meant to be displayed to the user. This can be done by
+calling the function `completion-lazy-hilit' which returns a
+`face'-propertized string.
+
+The value stored in this variable by the completion frontend
+should be unique to each completion attempt or session that
+utilizes the same completion style in `completion-styles-alist'.
+For frontends using the minibuffer as the locus of completion
+calls and display, setting it to a buffer-local value given by
+`gensym' is appropriate. For frontends operating entirely in a
+single command, let-binding it to `gensym' is appropriate.
+
+Note that the optimization enabled by variable is only actually
+performed some completions styles. To others, it is a harmless
+and useless hint. To author a completion style that takes
+advantage of this, look in the source of
+`completion-pcm--hilit-commonality'.")
+
+(defun completion-lazy-hilit (str)
+ "Return a copy of completion STR that is `face'-propertized.
+See documentation for variable `completion-lazy-hilit' for more
+details."
+ (completion--hilit-from-re
+ (copy-sequence str)
+ (gethash completion-lazy-hilit completion--lazy-hilit-table)))
+
+(defun completion--hilit-from-re (string regexp)
+ "Fontify STRING with `completions-common-part' using REGEXP."
+ (let* ((md (and regexp (string-match regexp string) (cddr (match-data t))))
+ (me (and md (match-end 0)))
+ (from 0))
+ (while md
+ (add-face-text-property from (pop md) 'completions-common-part nil string)
+ (setq from (pop md)))
+ (unless (or (not me) (= from me))
+ (add-face-text-property from me 'completions-common-part nil string))
+ string))
+
+(defun completion--flex-score-1 (md match-end len)
+ "Compute matching score of completion.
+The score lies in the range between 0 and 1, where 1 corresponds to
+the full match.
+MD is the match data.
+MATCH-END is the end of the match.
+LEN is the length of the completion string."
+ (let* ((from 0)
+ ;; To understand how this works, consider these simple
+ ;; ascii diagrams showing how the pattern "foo"
+ ;; flex-matches "fabrobazo", "fbarbazoo" and
+ ;; "barfoobaz":
+
+ ;; f abr o baz o
+ ;; + --- + --- +
+
+ ;; f barbaz oo
+ ;; + ------ ++
+
+ ;; bar foo baz
+ ;; +++
+
+ ;; "+" indicates parts where the pattern matched. A
+ ;; "hole" in the middle of the string is indicated by
+ ;; "-". Note that there are no "holes" near the edges
+ ;; of the string. The completion score is a number
+ ;; bound by (0..1] (i.e., larger than (but not equal
+ ;; to) zero, and smaller or equal to one): the higher
+ ;; the better and only a perfect match (pattern equals
+ ;; string) will have score 1. The formula takes the
+ ;; form of a quotient. For the numerator, we use the
+ ;; number of +, i.e. the length of the pattern. For
+ ;; the denominator, it first computes
+ ;;
+ ;; hole_i_contrib = 1 + (Li-1)^(1/tightness)
+ ;;
+ ;; , for each hole "i" of length "Li", where tightness
+ ;; is given by `flex-score-match-tightness'. The
+ ;; final value for the denominator is then given by:
+ ;;
+ ;; (SUM_across_i(hole_i_contrib) + 1) * len
+ ;;
+ ;; , where "len" is the string's length.
+ (score-numerator 0)
+ (score-denominator 0)
+ (last-b 0))
+ (while md
+ (let ((a from)
+ (b (pop md)))
+ (setq
+ score-numerator (+ score-numerator (- b a)))
+ (unless (or (= a last-b)
+ (zerop last-b)
+ (= a len))
+ (setq
+ score-denominator (+ score-denominator
+ 1
+ (expt (- a last-b 1)
+ (/ 1.0
+ flex-score-match-tightness)))))
+ (setq
+ last-b b))
+ (setq from (pop md)))
+ ;; If `pattern' doesn't have an explicit trailing any, the
+ ;; regex `re' won't produce match data representing the
+ ;; region after the match. We need to account to account
+ ;; for that extra bit of match (bug#42149).
+ (unless (= from match-end)
+ (let ((a from)
+ (b match-end))
+ (setq
+ score-numerator (+ score-numerator (- b a)))
+ (unless (or (= a last-b)
+ (zerop last-b)
+ (= a len))
+ (setq
+ score-denominator (+ score-denominator
+ 1
+ (expt (- a last-b 1)
+ (/ 1.0
+ flex-score-match-tightness)))))
+ (setq
+ last-b b)))
+ (/ score-numerator (* len (1+ score-denominator)) 1.0)))
+
+(defvar completion--lazy-hilit-table (make-hash-table :weakness 'key))
+
(defun completion-pcm--hilit-commonality (pattern completions)
"Show where and how well PATTERN matches COMPLETIONS.
PATTERN, a list of symbols and strings as seen
`completion-pcm--merge-completions', is assumed to match every
-string in COMPLETIONS. Return a deep copy of COMPLETIONS where
-each string is propertized with `completion-score', a number
-between 0 and 1, and with faces `completions-common-part',
-`completions-first-difference' in the relevant segments."
+string in COMPLETIONS.
+
+If `completion-lazy-hilit' is nil, return a deep copy of
+COMPLETIONS where each string is propertized with
+`completion-score', a number between 0 and 1, and with faces
+`completions-common-part', `completions-first-difference' in the
+relevant segments.
+
+Else, if `completion-lazy-hilit' is t, return COMPLETIONS where
+each string now has a `completion-score' property and no
+highlighting."
(cond
((and completions (cl-loop for e in pattern thereis (stringp e)))
(let* ((re (completion-pcm--pattern->regex pattern 'group))
- (point-idx (completion-pcm--pattern-point-idx pattern))
- (case-fold-search completion-ignore-case)
- last-md)
- (mapcar
- (lambda (str)
- ;; Don't modify the string itself.
- (setq str (copy-sequence str))
- (unless (string-match re str)
- (error "Internal error: %s does not match %s" re str))
- (let* ((pos (if point-idx (match-beginning point-idx) (match-end 0)))
- (match-end (match-end 0))
- (md (cddr (setq last-md (match-data t last-md))))
- (from 0)
- (end (length str))
- ;; To understand how this works, consider these simple
- ;; ascii diagrams showing how the pattern "foo"
- ;; flex-matches "fabrobazo", "fbarbazoo" and
- ;; "barfoobaz":
-
- ;; f abr o baz o
- ;; + --- + --- +
-
- ;; f barbaz oo
- ;; + ------ ++
-
- ;; bar foo baz
- ;; +++
-
- ;; "+" indicates parts where the pattern matched. A
- ;; "hole" in the middle of the string is indicated by
- ;; "-". Note that there are no "holes" near the edges
- ;; of the string. The completion score is a number
- ;; bound by (0..1] (i.e., larger than (but not equal
- ;; to) zero, and smaller or equal to one): the higher
- ;; the better and only a perfect match (pattern equals
- ;; string) will have score 1. The formula takes the
- ;; form of a quotient. For the numerator, we use the
- ;; number of +, i.e. the length of the pattern. For
- ;; the denominator, it first computes
- ;;
- ;; hole_i_contrib = 1 + (Li-1)^(1/tightness)
- ;;
- ;; , for each hole "i" of length "Li", where tightness
- ;; is given by `flex-score-match-tightness'. The
- ;; final value for the denominator is then given by:
- ;;
- ;; (SUM_across_i(hole_i_contrib) + 1) * len
- ;;
- ;; , where "len" is the string's length.
- (score-numerator 0)
- (score-denominator 0)
- (last-b 0)
- (update-score-and-face
- (lambda (a b)
- "Update score and face given match range (A B)."
- (add-face-text-property a b
- 'completions-common-part
- nil str)
- (setq
- score-numerator (+ score-numerator (- b a)))
- (unless (or (= a last-b)
- (zerop last-b)
- (= a (length str)))
- (setq
- score-denominator (+ score-denominator
- 1
- (expt (- a last-b 1)
- (/ 1.0
- flex-score-match-tightness)))))
- (setq
- last-b b))))
- (while md
- (funcall update-score-and-face from (pop md))
- (setq from (pop md)))
- ;; If `pattern' doesn't have an explicit trailing any, the
- ;; regex `re' won't produce match data representing the
- ;; region after the match. We need to account to account
- ;; for that extra bit of match (bug#42149).
- (unless (= from match-end)
- (funcall update-score-and-face from match-end))
- (if (> (length str) pos)
- (add-face-text-property
- pos (1+ pos)
- 'completions-first-difference
- nil str))
- (unless (zerop (length str))
- (put-text-property
- 0 1 'completion-score
- (/ score-numerator (* end (1+ score-denominator)) 1.0) str)))
- str)
- completions)))
+ last-md
+ (score (lambda (str)
+ (unless (string-match re str)
+ (error "Internal error: %s does not match %s" re str))
+ (let* ((match-end (match-end 0))
+ (md (cddr (setq last-md (match-data t last-md)))))
+ (completion--flex-score-1 md match-end (length str))))))
+ (cond (completion-lazy-hilit
+ (puthash completion-lazy-hilit re completion--lazy-hilit-table)
+ (mapc (lambda (str)
+ (put-text-property 0 1 'completion-score (funcall score str) str))
+ completions))
+ (t
+ (mapcar
+ (lambda (str)
+ (setq str (copy-sequence str))
+ (put-text-property 0 1 'completion-score (funcall score str) str)
+ (completion--hilit-from-re str re)
+ str)
+ completions)))))
(t completions)))
(defun completion-pcm--find-all-completions (string table pred point
--
2.39.2
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 24 Oct 2023 22:26:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 24 18:26:11 2023
Received: from localhost ([127.0.0.1]:56845 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qvPqj-00013p-DR
for submit <at> debbugs.gnu.org; Tue, 24 Oct 2023 18:26:11 -0400
Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:39819)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <dmitry@HIDDEN>) id 1qvPqe-00013G-FE
for 47711 <at> debbugs.gnu.org; Tue, 24 Oct 2023 18:26:07 -0400
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43])
by mailout.west.internal (Postfix) with ESMTP id 40D803200A1E;
Tue, 24 Oct 2023 18:25:28 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
by compute3.internal (MEProxy); Tue, 24 Oct 2023 18:25:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
:cc: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=1698186327; x=1698272727; bh=30
uxqjCwOcvpTcJVIr0Y0MBWsiNqLkdeY4m1KKCzhQQ=; b=B2AtNUw2AZw0iIM2Dt
XMdnFl7lu68tRsgQ+gD/3gxNvi5dRFIadWWK7wNSurhxOcMsMg4aF/hUNzk1pbpt
Yni5IvkJezrFCKS0pOr8c+V8EoHW+KGJzAqHuzRvXnXsnp/7xNovdicECksLPO4i
mQB/ODckTXvQf1LDTFJOWdk42xzjRM3qjVGT+EzDu6oJbhXSaN9TSXRxV+/4VDxF
uJjvtCroK+1JOL2ME8F3UgAv2++3QBSjVotWdf+JMcYd+AXhfosCA2erlajWYcXM
+0gBtEDSItCNyeNkTyqnEqnrwSSvDATabMU/K7Mb/i0faR/k+oQYxQAPRTV5ZaE+
8Q2A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc: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=1698186327; x=1698272727; bh=30uxqjCwOcvpT
cJVIr0Y0MBWsiNqLkdeY4m1KKCzhQQ=; b=nSk7xXVncAcL4lE3O77s6xXGlLqML
X/ODhgDB3mXWQ+ODyjS4MIe54kGrfXZUsXhBO8BBKcyUIKLgcD23uIZCFopkyiOh
bDjOixEMbaMhLMUVGPJMqUpfH4qznhY3/lqTCjNt+fuFSNNCkjjwfoe87B8CTAq+
TYxkWN7/Z/fMDgWgO8z5NecEC1xddzSja+N+I3vMGpWaVzXKkVQi36E4LdR6Jg5n
vesfPgW1a41RATwnQ00n2JE9E5pvtwG+gDC5ICdx4jRwQdjMZWLHGHx8G3XKN1Ly
UOhv24S7gb3yCGWaRf64R5ZTvFVu2yO+KJwMQiOGXGcFDHWmdLt33uuPw==
X-ME-Sender: <xms:V0Q4ZT0vWfXPsrKYM2HWmR7cgl0W1un8pSu9Qwpbz3b-o1c8PE12kA>
<xme:V0Q4ZSEHnFGDuFuvKGdvrvJQx7RldS_ZCFraIoCE1dGjIHxB49KFHSyEww_Qaks0z
foZ6-8BrSjTJBGxfK8>
X-ME-Received: <xmr:V0Q4ZT4HoxXWK_Qh1Wtg1L2fkbZmZGlfBr0ELKT7gykpkLs3hLXZbEDWcNnvZl4>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrkeelgddtlecutefuodetggdotefrodftvf
curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
fjughrpegtkfffgggfuffvvehfhfgjsehmtderredtfeejnecuhfhrohhmpeffmhhithhr
hicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvg
hrnhepheetkefgteeiueejuedvtddvleetffeljeetuddvfeffjeeiheehueetffevieej
necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmih
htrhihsehguhhtohhvrdguvghv
X-ME-Proxy: <xmx:V0Q4ZY0192TLPoi2rIAYEWoaWRecdMTPvso4LEt3za2Vd3iUEX_MPw>
<xmx:V0Q4ZWE_nvdreZhpbBfqLgNpHFQlW-OusdiUT1VZX6qPuIGa9sJhAA>
<xmx:V0Q4ZZ--pKdCoileetV1Ck_sOyR7we_CdmBEkG7KWEnWQvRY3P5rfg>
<xmx:V0Q4ZSC5RCLfhgoWpPFBAlVA0euKvia_Tkvhur2jiaUZyGMNq5xLFQ>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
24 Oct 2023 18:25:25 -0400 (EDT)
Content-Type: multipart/mixed; boundary="------------AUdgZRFE6FQlG2vfM1Gpkmdf"
Message-ID: <9f432d18-e70f-54c1-0173-1899fb66d176@HIDDEN>
Date: Wed, 25 Oct 2023 01:25:23 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.13.0
Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add
new `completion-filter-completions` API and deferred highlighting
Content-Language: en-US
To: Eli Zaretskii <eliz@HIDDEN>, Daniel Mendler <mail@HIDDEN>,
Stefan Monnier <monnier@HIDDEN>, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?=
<joaotavora@HIDDEN>
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN>
<fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN>
<3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN>
<CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN>
<56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN>
<CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN>
<328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <83fsvcbio7.fsf@HIDDEN>
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <83fsvcbio7.fsf@HIDDEN>
X-Spam-Score: -2.2 (--)
X-Debbugs-Envelope-To: 47711
Cc: 47711 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.2 (---)
This is a multi-part message in MIME format.
--------------AUdgZRFE6FQlG2vfM1Gpkmdf
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi all!
Time flies, doesn't it?
On 14/08/2021 10:16, Eli Zaretskii wrote:
>>> If one removes these lines, the process becomes much faster, but there is a
>>> problem with highlighting. My idea is indeed to defer highlighting by not
>>> setting the 'face property directly on that shared string, but some
>>> other property
>>> that is read later from the shared string by compliant frontents.
>>
>> I haven't done any direct benchmarking, but I'm pretty sure that this
>> approach cannot, by definition, be as fast as the non-mutating one.
>
> Daniel seems to think otherwise, AFAIU.
>
>> Because you go through the whole list and mutate all of its elements,
>> you have to perform a certain bit of work W x N times, where N is the
>> size of the whole list.
>>
>> Whereas the deferred-mutation approach will only have to do its bit
>> (which is likely more work, like, WWW) only 20 times, or 100 times, or
>> however many completions are displayed. And this is usually negligible.
>>
>> However big the difference is going to be, I can't say in advance, of
>> course, or whether it's going to be shadowed by some other performance
>> costs. But the non-mutating approach should have the best optimization
>> potential when the list is long.
>
> So I guess the suggestion to have a benchmark is still useful, because
> the estimations of which approach has better performance vary between
> you three. So maybe producing such benchmarks would be a good step?
To cross this out from my TODO, I spent most of the day rebasing both of
the proposed patches (one of them longer than the other) -- one from an
attachment here and another from a commit inside the
scratch/icomplete-lazy-highlight-attempt-2 branch, porting icomplete to
Daniel's new completion-filter-completions API (*), and benchmarking.
(*) Included in the attached patch: it needed changing just two lines
inside icomplete, but also new variable completion-all-sorted-highlight
and updates to completion--cache-all-sorted-completions and
completion-all-sorted-completions.
Both rebased patches are attached to this email for your convenience.
AFAICT, the results confirmed my expectations quoted above.
Using Joao's benchmark, with setup:
(defmacro lotsoffunctions ()
`(progn
,@(cl-loop repeat 150000
collect `(defun ,(intern (symbol-name (gensym
"heyhey"))) () 42))))
(lotsoffunctions)
I ran the comparisons for empty and non-empty inputs.
With no characters typed:
(benchmark-run 1
(let ((completion-styles '(flex))
(completion-lazy-hilit (cl-gensym)) ; might not be defined
)
;; Uncomment one of the lines below, depending on the patch used.
;; (completion-all-completions "" obarray 'fboundp 0 nil)
;; (completion-filter-completions "" obarray 'fboundp 0 nil)
))
master => 0.066
lazy-hilit => 0.045
filter-and-defer => 0.041 (but more often ~0.110 including GC, somehow)
With one character typed:
(benchmark-run 1
(let ((completion-styles '(flex))
(completion-lazy-hilit (cl-gensym)) ; might not be defined
)
;; Uncomment one of the lines below, depending on the patch used.
;; (completion-all-completions "h" obarray 'fboundp 1 nil)
;; (completion-filter-completions "h" obarray 'fboundp 1 nil)
))
master => 0.824
lazy-hilit => 0.395
filter-and-defer => 0.125 (!)
This more or less translates into the improvement in speed of
fido-vertical-mode, according to my benchmark-progn call inside
icomplete-exhibit (included in both attached patches for convenience).
For non-empty inputs (h or hh or hhe, to match the generated functions),
filter-and-defer is about 1.5x faster than lazy-hilit, like 0.450ms vs
0.640ms.
lazy-hilit is slightly faster than filter-and-defer with the empty input
(like 380ms vs 420ms), and I'm not yet sure why, but it's the scenario
with 0 highlighting (and so no flex scoring/sorting). Perhaps some
short-circuiting can be added somewhere to reach parity, or it's the
cost of extra branching somewhere for backward compatibility (which
could be removed in the future). Worth additional study.
--------------AUdgZRFE6FQlG2vfM1Gpkmdf
Content-Type: text/x-patch; charset=UTF-8;
name="0001-Add-new-completion-filter-completions-API-and-deferr-v3.diff"
Content-Disposition: attachment;
filename*0="0001-Add-new-completion-filter-completions-API-and-deferr-v3";
filename*1=".diff"
Content-Transfer-Encoding: base64
ZGlmZiAtLWdpdCBhL2xpc3AvaWNvbXBsZXRlLmVsIGIvbGlzcC9pY29tcGxldGUuZWwKaW5k
ZXggZTZmZGQxZjE4MzYuLjIzNDExM2U2MDdjIDEwMDY0NAotLS0gYS9saXNwL2ljb21wbGV0
ZS5lbAorKysgYi9saXNwL2ljb21wbGV0ZS5lbApAQCAtNzU0LDEyICs3NTQsMTMgQEAgaWNv
bXBsZXRlLWV4aGliaXQKICAgICAgICAgICAgICAgICAgICAgICAgICAgIChvdmVybGF5LWVu
ZCByZm4tZXNoYWRvdy1vdmVybGF5KSkpCiAgICAgICAgICAgKGxldCogKChmaWVsZC1zdHJp
bmcgKGljb21wbGV0ZS0tZmllbGQtc3RyaW5nKSkKICAgICAgICAgICAgICAgICAgKHRleHQg
KHdoaWxlLW5vLWlucHV0CisgICAgICAgICAgICAgICAgICAgICAgICAgKGJlbmNobWFyay1w
cm9nbgogICAgICAgICAgICAgICAgICAgICAgICAgIChpY29tcGxldGUtY29tcGxldGlvbnMK
ICAgICAgICAgICAgICAgICAgICAgICAgICAgZmllbGQtc3RyaW5nCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgIChpY29tcGxldGUtLWNvbXBsZXRpb24tdGFibGUpCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgIChpY29tcGxldGUtLWNvbXBsZXRpb24tcHJlZGljYXRlKQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAoaWYgKHdpbmRvdy1taW5pYnVmZmVyLXApCi0gICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAoZXEgbWluaWJ1ZmZlci0tcmVxdWlyZS1tYXRj
aCB0KSkpKSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChlcSBtaW5pYnVmZmVy
LS1yZXF1aXJlLW1hdGNoIHQpKSkpKSkKICAgICAgICAgICAgICAgICAgKGJ1ZmZlci11bmRv
LWxpc3QgdCkKICAgICAgICAgICAgICAgICAgZGVhY3RpdmF0ZS1tYXJrKQogICAgICAgICAg
ICAgOzsgRG8gbm90aGluZyBpZiB3aGlsZS1uby1pbnB1dCB3YXMgYWJvcnRlZC4KQEAgLTg3
OCw3ICs4NzksNyBAQCBpY29tcGxldGUtLXJlbmRlci12ZXJ0aWNhbAogICA7OyBIYWxmd2F5
IHRoZXJlLi4uCiAgIChsZXQqICgoc2VsZWN0ZWQgKHByb3BlcnRpemUgKGNhciBjb21wcykg
J2ljb21wbGV0ZS1zZWxlY3RlZCB0KSkKICAgICAgICAgIChjaG9zZW4gKGFwcGVuZCBzY3Jv
bGwtYWJvdmUgKGxpc3Qgc2VsZWN0ZWQpIHNjcm9sbC1iZWxvdykpCi0gICAgICAgICAodHVw
bGVzIChpY29tcGxldGUtLWF1Z21lbnQgbWQgY2hvc2VuKSkKKyAgICAgICAgICh0dXBsZXMg
KGljb21wbGV0ZS0tYXVnbWVudCBtZCAoZnVuY2FsbCBjb21wbGV0aW9uLWFsbC1zb3J0ZWQt
aGlnaGxpZ2h0IGNob3NlbikpKQogICAgICAgICAgbWF4LXByZWZpeC1sZW4gbWF4LWNvbXAt
bGVuIGxpbmVzIG5zZWN0aW9ucykKICAgICAoYWRkLWZhY2UtdGV4dC1wcm9wZXJ0eSAwIChs
ZW5ndGggc2VsZWN0ZWQpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJ2ljb21wbGV0
ZS1zZWxlY3RlZC1tYXRjaCAnYXBwZW5kIHNlbGVjdGVkKQpAQCAtMTA2Nyw3ICsxMDY4LDgg
QEAgaWNvbXBsZXRlLWNvbXBsZXRpb25zCiAgICAgICAgICAgICAgICAgICAoaWYgKDwgcHJv
c3BlY3RzLWxlbiBwcm9zcGVjdHMtbWF4KQogICAgICAgICAgICAgICAgICAgICAgIChwdXNo
IGNvbXAgcHJvc3BlY3RzKQogICAgICAgICAgICAgICAgICAgICAoc2V0cSBsaW1pdCB0KSkp
Ci0gICAgICAgICAgICAgICAgKHNldHEgcHJvc3BlY3RzIChucmV2ZXJzZSBwcm9zcGVjdHMp
KQorICAgICAgICAgICAgICAgIChzZXRxIHByb3NwZWN0cyAobnJldmVyc2UKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIChmdW5jYWxsIGNvbXBsZXRpb24tYWxsLXNvcnRl
ZC1oaWdobGlnaHQgcHJvc3BlY3RzKSkpCiAgICAgICAgICAgICAgICAgOzsgRGVjb3JhdGUg
Zmlyc3Qgb2YgdGhlIHByb3NwZWN0cy4KICAgICAgICAgICAgICAgICAod2hlbiBwcm9zcGVj
dHMKICAgICAgICAgICAgICAgICAgIChsZXQgKChmaXJzdCAoY29weS1zZXF1ZW5jZSAocG9w
IHByb3NwZWN0cykpKSkKZGlmZiAtLWdpdCBhL2xpc3AvbWluaWJ1ZmZlci5lbCBiL2xpc3Av
bWluaWJ1ZmZlci5lbAppbmRleCAyMTIwZTMxNzc1ZS4uZThiMjg0OWY0NWEgMTAwNjQ0Ci0t
LSBhL2xpc3AvbWluaWJ1ZmZlci5lbAorKysgYi9saXNwL21pbmlidWZmZXIuZWwKQEAgLTY3
Nyw2ICs2NzcsMTAgQEAgY29tcGxldGlvbi0tdHdxLWFsbAogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgJ2NvbXBsZXRpb25zLWNvbW1vbi1wYXJ0KQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHFwcmVmaXgpKSkpCiAgICAgICAgICAg
ICAgICAgICAgICAgICAocWNvbXBsZXRpb24gKGNvbmNhdCBxcHJlZml4IHFuZXcpKSkKKyAg
ICAgICAgICAgICAgICAgICA7OyBBdHRhY2ggdW5xdW90ZWQgY29tcGxldGlvbiBzdHJpbmcs
IHdoaWNoIGlzIG5lZWRlZAorICAgICAgICAgICAgICAgICAgIDs7IHRvIHNjb3JlIHRoZSBj
b21wbGV0aW9uIGluIGBjb21wbGV0aW9uLS1mbGV4LXNjb3JlJy4KKyAgICAgICAgICAgICAg
ICAgICAocHV0LXRleHQtcHJvcGVydHkgMCAxICdjb21wbGV0aW9uLS11bnF1b3RlZAorICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb21wbGV0aW9uIHFjb21wbGV0
aW9uKQogCQkgICA7OyBGSVhNRTogU2ltaWxhcmx5IGhlcmUsIEN5Z3dpbidzIG1hcHBpbmcg
dHJpcHMgdGhpcwogCQkgICA7OyBhc3NlcnRpb24uCiAgICAgICAgICAgICAgICAgICAgOzso
Y2wtYXNzZXJ0CkBAIC0xMTcxLDYgKzExNzUsMTcgQEAgY29tcGxldGlvbi0tc3R5bGVzCiAg
ICAgICAgIChkZWxldGUtZHVwcyAoYXBwZW5kIChjZHIgb3ZlcikgKGNvcHktc2VxdWVuY2Ug
Y29tcGxldGlvbi1zdHlsZXMpKSkKICAgICAgICBjb21wbGV0aW9uLXN0eWxlcykpKQogCiso
ZGVmdmFyIGNvbXBsZXRpb24tLXJldHVybi1hbGlzdC1mbGFnIG5pbAorICAiTm9uLW5pbCBt
ZWFucyB0byByZXR1cm4gY29tcGxldGlvbnMgaW4gYWxpc3QgZm9ybWF0LgorSWYgdGhpcyB2
YXJpYWJsZSBpcyBub24tbmlsIHRoZSBgYWxsLWNvbXBsZXRpb25zJyBmdW5jdGlvbiBvZiBh
Citjb21wbGV0aW9uIHN0eWxlIHNob3VsZCByZXR1cm4gdGhlIHJlc3VsdHMgaW4gdGhlIGFs
aXN0IGZvcm1hdCBvZgorYGNvbXBsZXRpb24tZmlsdGVyLWNvbXBsZXRpb25zJy4gIFRoaXMg
dmFyaWFibGUgaXMgcHVyZWx5IG5lZWRlZCB0bworZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxp
dHkgb2YgdGhlIGV4aXN0aW5nIGJ1aWx0aW4gY29tcGxldGlvbiBzdHlsZQorZnVuY3Rpb25z
IGFzIG9mIEVtYWNzIDI4LiAgTmV3ZXIgY29tcGxldGlvbiBzdHlsZSBmdW5jdGlvbnMgc2hv
dWxkCithbHdheXMgcmV0dXJuIHRoZWlyIHJlc3VsdHMgaW4gdGhlIGFsaXN0IGZvcm1hdCwg
c2luY2UKK2Bjb21wbGV0aW9uLWFsbC1jb21wbGV0aW9ucycgdHJhbnNwYXJlbnRseSBjb252
ZXJ0cyBiYWNrIHRvIGEgbGlzdCBvZgorY29tcGxldGlvbnMgd2l0aCBiYXNlIHNpemUgaW4g
dGhlIGxhc3QgY2RyLiIpCisKIChkZWZ1biBjb21wbGV0aW9uLS1udGgtY29tcGxldGlvbiAo
biBzdHJpbmcgdGFibGUgcHJlZCBwb2ludCBtZXRhZGF0YSkKICAgIkNhbGwgdGhlIE50aCBt
ZXRob2Qgb2YgY29tcGxldGlvbiBzdHlsZXMuIgogICA7OyBXZSBwcm92aWRlIHNwZWNpYWwg
c3VwcG9ydCBmb3IgcXVvdGluZy91bnF1b3RpbmcgaGVyZSBiZWNhdXNlIGl0IGNhbm5vdApA
QCAtMTE5Nyw2ICsxMjEyLDE1IEBAIGNvbXBsZXRpb24tLW50aC1jb21wbGV0aW9uCiAgICAg
ICAgICAgICAgICAgIDs7IHRoZSBvcmlnaW5hbCB0YWJsZSwgaW4gdGhhdCBjYXNlIQogICAg
ICAgICAgICAgICAgICAoZnVuY3Rpb25wIHRhYmxlKSkKICAgICAgICAgICAgIChsZXQgKChu
ZXcgKGZ1bmNhbGwgdGFibGUgc3RyaW5nIHBvaW50ICdjb21wbGV0aW9uLS11bnF1b3RlKSkp
CisgICAgICAgICAgICAgIDs7IEZJWE1FIEZvciBub3cgZG8gbm90IGF0dGVtcHQgZGVmZXJy
ZWQgaGlnaGxpZ2h0aW5nIGlmCisgICAgICAgICAgICAgIDs7IHF1b3RpbmcgaXMgdXNlZC4g
IE5vdCBkb2luZyBkZWZlcnJlZCBoaWdobGlnaHRpbmcgaXMKKyAgICAgICAgICAgICAgOzsg
bm90IHRvbyBzZXZlcmUgaW4gdGhpcyBjYXNlLCBzaW5jZQorICAgICAgICAgICAgICA7OyBg
Y29tcGxldGlvbi0tdHdxLWFsbCcgaXMgYWxyZWFkeSBhbiBleHBlbnNpdmUKKyAgICAgICAg
ICAgICAgOzsgZnVuY3Rpb24sIHdoaWNoIGFsbG9jYXRlcyBhbGwgY29tcGxldGlvbiBzdHJp
bmdzLiAgSW4KKyAgICAgICAgICAgICAgOzsgY29udHJhc3QgdG8gcGxhaW4gY29tcGxldGlv
biB0YWJsZXMsIHRoZSBzYXZpbmdzIG9mCisgICAgICAgICAgICAgIDs7IGRlZmVycmVkIGhp
Z2hsaWdodGluZyB3b3VsZCBiZSBtaW5pbWFsIGluIHRoZSBjYXNlIG9mCisgICAgICAgICAg
ICAgIDs7IHF1b3RlZCBjb21wbGV0aW9uIHRhYmxlcy4KKyAgICAgICAgICAgICAgKHNldHEg
Y29tcGxldGlvbi0tcmV0dXJuLWFsaXN0LWZsYWcgbmlsKQogICAgICAgICAgICAgICAoc2V0
cSBzdHJpbmcgKHBvcCBuZXcpKQogICAgICAgICAgICAgICAoc2V0cSB0YWJsZSAocG9wIG5l
dykpCiAgICAgICAgICAgICAgIChzZXRxIHBvaW50IChwb3AgbmV3KSkKQEAgLTEyMDUsMTgg
KzEyMjksMzYgQEAgY29tcGxldGlvbi0tbnRoLWNvbXBsZXRpb24KICAgICAgICAgIChyZXN1
bHQtYW5kLXN0eWxlCiAgICAgICAgICAgKHNlcS1zb21lCiAgICAgICAgICAgIChsYW1iZGEg
KHN0eWxlKQotICAgICAgICAgICAgIChsZXQgKChwcm9iZSAoZnVuY2FsbAotICAgICAgICAg
ICAgICAgICAgICAgICAgICAgKG9yIChudGggbiAoYXNzcSBzdHlsZSBjb21wbGV0aW9uLXN0
eWxlcy1hbGlzdCkpCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGVycm9yICJJ
bnZhbGlkIGNvbXBsZXRpb24gc3R5bGUgJXMiIHN0eWxlKSkKLSAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHN0cmluZyB0YWJsZSBwcmVkIHBvaW50KSkpCisgICAgICAgICAgICAgKGxl
dCogKChmdW4gKG9yIChudGggbiAoYXNzcSBzdHlsZSBjb21wbGV0aW9uLXN0eWxlcy1hbGlz
dCkpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGVycm9yICJJbnZhbGlkIGNv
bXBsZXRpb24gc3R5bGUgJXMiIHN0eWxlKSkpCisgICAgICAgICAgICAgICAgICAgIDs7IFRy
YW5zcGFyZW50bHkgdXBncmFkZSB0aGUgcmV0dXJuIHZhbHVlIGZvcgorICAgICAgICAgICAg
ICAgICAgICA7OyBleGlzdGluZyBidWlsdC1pbiBzdHlsZXMgYXMgb2YgRW1hY3MgMjguICBO
bworICAgICAgICAgICAgICAgICAgICA7OyBuZXcgc3R5bGVzIHNob3VsZCBiZSBhZGRlZCBo
ZXJlLiBOZXcgY29tcGxldGlvbgorICAgICAgICAgICAgICAgICAgICA7OyBzdHlsZXMgc2hv
dWxkIGRpcmVjdGx5IHJldHVybiB0aGUgbmV3CisgICAgICAgICAgICAgICAgICAgIDs7IGNv
bXBsZXRpb24gZm9ybWF0LmVsCisgICAgICAgICAgICAgICAgICAgIChjb21wbGV0aW9uLS1y
ZXR1cm4tYWxpc3QtZmxhZworICAgICAgICAgICAgICAgICAgICAgKGFuZCBjb21wbGV0aW9u
LS1yZXR1cm4tYWxpc3QtZmxhZworICAgICAgICAgICAgICAgICAgICAgICAgICAobWVtcSBz
dHlsZSAnKGVtYWNzMjEgZW1hY3MyMiBiYXNpYyBzdWJzdHJpbmcKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBwYXJ0aWFsLWNvbXBsZXRpb24gaW5pdGlhbHMg
ZmxleCkpKSkKKyAgICAgICAgICAgICAgICAgICAgKHByb2JlIChmdW5jYWxsIGZ1biBzdHJp
bmcgdGFibGUgcHJlZCBwb2ludCkpKQogICAgICAgICAgICAgICAgKGFuZCBwcm9iZSAoY29u
cyBwcm9iZSBzdHlsZSkpKSkKICAgICAgICAgICAgKGNvbXBsZXRpb24tLXN0eWxlcyBtZCkp
KQotICAgICAgICAgKGFkanVzdC1mbiAoZ2V0IChjZHIgcmVzdWx0LWFuZC1zdHlsZSkgJ2Nv
bXBsZXRpb24tLWFkanVzdC1tZXRhZGF0YSkpKQotICAgICh3aGVuIChhbmQgYWRqdXN0LWZu
IG1ldGFkYXRhKQotICAgICAgKHNldGNkciBtZXRhZGF0YSAoY2RyIChmdW5jYWxsIGFkanVz
dC1mbiBtZXRhZGF0YSkpKSkKKyAgICAgICAgIChzdHlsZS1tZCAoZ2V0IChjZHIgcmVzdWx0
LWFuZC1zdHlsZSkgJ2NvbXBsZXRpb24tLXN0eWxlLW1ldGFkYXRhKSkKKyAgICAgICAgIChy
ZXN1bHQgKGNhciByZXN1bHQtYW5kLXN0eWxlKSkpCisgICAgKHdoZW4gKGFuZCBzdHlsZS1t
ZCBtZXRhZGF0YSkKKyAgICAgIChzZXRjZHIgbWV0YWRhdGEgKGNkciAoZnVuY2FsbCBzdHls
ZS1tZAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cmluZyB0YWJs
ZSBwcmVkIHBvaW50IG1ldGFkYXRhKSkpKQorICAgICh3aGVuIChhbmQgKG5vdCBjb21wbGV0
aW9uLS1yZXR1cm4tYWxpc3QtZmxhZykgKD0gbiAyKSAoY29uc3AgKGNhciByZXN1bHQpKSkK
KyAgICAgIDs7IEdpdmUgdGhlIGNvbXBsZXRpb24gc3R5bGVzIHNvbWUgZnJlZWRvbSEgIElm
IHRoZXkgYXJlCisgICAgICA7OyB0YXJnZXRpbmcgRW1hY3MgMjggdXB3YXJkcyBvbmx5LCB0
aGV5IG1heSByZXR1cm4gYSByZXN1bHQKKyAgICAgIDs7IHdpdGggZGVmZXJyZWQgaGlnaGxp
Z2h0aW5nLiAgV2UgY29udmVydCBiYWNrIHRvIHRoZSBvbGQKKyAgICAgIDs7IGZvcm1hdCBo
ZXJlIGJ5IGFwcGx5aW5nIHRoZSBoaWdobGlnaHRpbmcgZWFnZXJseS4KKyAgICAgIChzZXRx
IHJlc3VsdCAobmNvbmMgKGZ1bmNhbGwgKGNkciAoYXNzcSAnaGlnaGxpZ2h0IHJlc3VsdCkp
CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjZHIgKGFzc3EgJ2NvbXBs
ZXRpb25zIHJlc3VsdCkpKQorICAgICAgICAgICAgICAgICAgICAgICAgICAoY2RyIChhc3Nx
ICdiYXNlIHJlc3VsdCkpKSkpCiAgICAgKGlmIHJlcXVvdGUKLSAgICAgICAgKGZ1bmNhbGwg
cmVxdW90ZSAoY2FyIHJlc3VsdC1hbmQtc3R5bGUpIG4pCi0gICAgICAoY2FyIHJlc3VsdC1h
bmQtc3R5bGUpKSkpCisgICAgICAgIChmdW5jYWxsIHJlcXVvdGUgcmVzdWx0IG4pCisgICAg
ICByZXN1bHQpKSkKIAogKGRlZnVuIGNvbXBsZXRpb24tdHJ5LWNvbXBsZXRpb24gKHN0cmlu
ZyB0YWJsZSBwcmVkIHBvaW50ICZvcHRpb25hbCBtZXRhZGF0YSkKICAgIlRyeSB0byBjb21w
bGV0ZSBTVFJJTkcgdXNpbmcgY29tcGxldGlvbiB0YWJsZSBUQUJMRS4KQEAgLTEyMjUsNyAr
MTI2Nyw4IEBAIGNvbXBsZXRpb24tdHJ5LWNvbXBsZXRpb24KIFRoZSByZXR1cm4gdmFsdWUg
Y2FuIGJlIGVpdGhlciBuaWwgdG8gaW5kaWNhdGUgdGhhdCB0aGVyZSBpcyBubyBjb21wbGV0
aW9uLAogdCB0byBpbmRpY2F0ZSB0aGF0IFNUUklORyBpcyB0aGUgb25seSBwb3NzaWJsZSBj
b21wbGV0aW9uLAogb3IgYSBwYWlyIChORVdTVFJJTkcgLiBORVdQT0lOVCkgb2YgdGhlIGNv
bXBsZXRlZCByZXN1bHQgc3RyaW5nIHRvZ2V0aGVyIHdpdGgKLWEgbmV3IHBvc2l0aW9uIGZv
ciBwb2ludC4iCithIG5ldyBwb3NpdGlvbiBmb3IgcG9pbnQuCitUaGUgTUVUQURBVEEgbWF5
IGJlIG1vZGlmaWVkIGJ5IHRoZSBjb21wbGV0aW9uIHN0eWxlLiIKICAgKGNvbXBsZXRpb24t
LW50aC1jb21wbGV0aW9uIDEgc3RyaW5nIHRhYmxlIHByZWQgcG9pbnQgbWV0YWRhdGEpKQog
CiAoZGVmdW4gY29tcGxldGlvbi1hbGwtY29tcGxldGlvbnMgKHN0cmluZyB0YWJsZSBwcmVk
IHBvaW50ICZvcHRpb25hbCBtZXRhZGF0YSkKQEAgLTEyMzMsMTAgKzEyNzYsNDcgQEAgY29t
cGxldGlvbi1hbGwtY29tcGxldGlvbnMKIE9ubHkgdGhlIGVsZW1lbnRzIG9mIHRhYmxlIHRo
YXQgc2F0aXNmeSBwcmVkaWNhdGUgUFJFRCBhcmUgY29uc2lkZXJlZC4KIFBPSU5UIGlzIHRo
ZSBwb3NpdGlvbiBvZiBwb2ludCB3aXRoaW4gU1RSSU5HLgogVGhlIHJldHVybiB2YWx1ZSBp
cyBhIGxpc3Qgb2YgY29tcGxldGlvbnMgYW5kIG1heSBjb250YWluIHRoZSBiYXNlLXNpemUK
LWluIHRoZSBsYXN0IGBjZHInLiIKLSAgOzsgRklYTUU6IFdlIG5lZWQgdG8gYWRkaXRpb25h
bGx5IHJldHVybiB0aGUgaW5mbyBuZWVkZWQgZm9yIHRoZQotICA7OyBzZWNvbmQgcGFydCBv
ZiBjb21wbGV0aW9uLWJhc2UtcG9zaXRpb24uCi0gIChjb21wbGV0aW9uLS1udGgtY29tcGxl
dGlvbiAyIHN0cmluZyB0YWJsZSBwcmVkIHBvaW50IG1ldGFkYXRhKSkKK2luIHRoZSBsYXN0
IGBjZHInLgorVGhlIE1FVEFEQVRBIG1heSBiZSBtb2RpZmllZCBieSB0aGUgY29tcGxldGlv
biBzdHlsZS4KKworVGhpcyBmdW5jdGlvbiBoYXMgYmVlbiBzdXBlcnNlZGVkIGJ5IGBjb21w
bGV0aW9uLWZpbHRlci1jb21wbGV0aW9ucycsCit3aGljaCByZXR1cm5zIHJpY2hlciBpbmZv
cm1hdGlvbiBhbmQgc3VwcG9ydHMgZGVmZXJyZWQgY2FuZGlkYXRlCitoaWdobGlnaHRpbmcu
IgorICAobGV0ICgoY29tcGxldGlvbi0tcmV0dXJuLWFsaXN0LWZsYWcgbmlsKSkKKyAgICAo
Y29tcGxldGlvbi0tbnRoLWNvbXBsZXRpb24gMiBzdHJpbmcgdGFibGUgcHJlZCBwb2ludCBt
ZXRhZGF0YSkpKQorCisoZGVmdW4gY29tcGxldGlvbi1maWx0ZXItY29tcGxldGlvbnMgKHN0
cmluZyB0YWJsZSBwcmVkIHBvaW50IG1ldGFkYXRhKQorICAiRmlsdGVyIHRoZSBwb3NzaWJs
ZSBjb21wbGV0aW9ucyBvZiBTVFJJTkcgaW4gY29tcGxldGlvbiB0YWJsZSBUQUJMRS4KK09u
bHkgdGhlIGVsZW1lbnRzIG9mIHRhYmxlIHRoYXQgc2F0aXNmeSBwcmVkaWNhdGUgUFJFRCBh
cmUgY29uc2lkZXJlZC4KK1BPSU5UIGlzIHRoZSBwb3NpdGlvbiBvZiBwb2ludCB3aXRoaW4g
U1RSSU5HLgorVGhlIE1FVEFEQVRBIG1heSBiZSBtb2RpZmllZCBieSB0aGUgY29tcGxldGlv
biBzdHlsZS4KK1RoZSByZXR1cm4gdmFsdWUgaXMgYSBhbGlzdCB3aXRoIHRoZSBrZXlzOgor
CistIGJhc2U6IEJhc2UgcG9zaXRpb24gb2YgdGhlIGNvbXBsZXRpb24gKGZyb20gdGhlIHN0
YXJ0IG9mIFNUUklORykKKy0gZW5kOiBFbmQgcG9zaXRpb24gb2YgdGhlIGNvbXBsZXRpb24g
KGZyb20gdGhlIHN0YXJ0IG9mIFNUUklORykKKy0gaGlnaGxpZ2h0OiBIaWdobGlnaHRpbmcg
ZnVuY3Rpb24gdGFraW5nIGEgbGlzdCBvZiBjb21wbGV0aW9ucyBhbmQKKyAgcmV0dXJuaW5n
IGEgbmV3IGxpc3Qgb2YgbmV3IHN0cmluZ3Mgd2l0aCBhcHBsaWVkIGhpZ2hsaWdodGluZy4K
Ky0gY29tcGxldGlvbnM6IFRoZSBsaXN0IG9mIGNvbXBsZXRpb25zLgorCitUaGlzIGZ1bmN0
aW9uIHN1cGVyc2VkZXMgdGhlIGZ1bmN0aW9uIGBjb21wbGV0aW9uLWFsbC1jb21wbGV0aW9u
cycsCit3aGljaCBkb2VzIG5vdCBwcm92aWRlIHRoZSBgZW5kJyBwb3NpdGlvbiBvZiB0aGUg
Y29tcGxldGlvbiBhbmQgZG9lcworbm90IHN1cHBvcnQgZGVmZXJyZWQgaGlnaGxpZ2h0aW5n
LiIKKyAgKGxldCogKChjb21wbGV0aW9uLS1yZXR1cm4tYWxpc3QtZmxhZyB0KQorICAgICAg
ICAgKHJlc3VsdCAoY29tcGxldGlvbi0tbnRoLWNvbXBsZXRpb24gMiBzdHJpbmcgdGFibGUK
KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByZWQgcG9p
bnQgbWV0YWRhdGEpKSkKKyAgICAoaWYgKGFuZCByZXN1bHQgKG5vdCAoY29uc3AgKGNhciBy
ZXN1bHQpKSkpCisgICAgICAgIDs7IERlZmVycmVkIGhpZ2hsaWdodGluZyBoYXMgYmVlbiBy
ZXF1ZXN0ZWQsIGJ1dCB0aGUKKyAgICAgICAgOzsgY29tcGxldGlvbiBzdHlsZSByZXR1cm5l
ZCBhIG5vbi1kZWZlcnJlZCByZXN1bHQuICBDb252ZXJ0CisgICAgICAgIDs7IHRoZSByZXN1
bHQgdG8gdGhlIGFsaXN0IGZvcm1hdCBvZgorICAgICAgICA7OyBgY29tcGxldGlvbi1maWx0
ZXItY29tcGxldGlvbnMnLgorICAgICAgICAobGV0KiAoKGxhc3QgKGxhc3QgcmVzdWx0KSkK
KyAgICAgICAgICAgICAgIChiYXNlIChvciAoY2RyIGxhc3QpIDApKSkKKyAgICAgICAgICAo
c2V0Y2RyIGxhc3QgbmlsKQorICAgICAgICAgIGAoKGJhc2UgLiAsYmFzZSkKKyAgICAgICAg
ICAgIChlbmQgLiAsKGxlbmd0aCBzdHJpbmcpKQorICAgICAgICAgICAgKGhpZ2hsaWdodCAu
IGlkZW50aXR5KQorICAgICAgICAgICAgKGNvbXBsZXRpb25zIC4gLHJlc3VsdCkpKQorICAg
ICAgcmVzdWx0KSkpCiAKIChkZWZ1biBtaW5pYnVmZmVyLS1iaXRzZXQgKG1vZGlmaWVkIGNv
bXBsZXRpb25zIGV4YWN0KQogICAobG9naW9yIChpZiBtb2RpZmllZCAgICA0IDApCkBAIC0x
MjUzLDcgKzEzMzMsOCBAQCBjb21wbGV0aW9uLS1yZXBsYWNlCiAgIChpZiBtaW5pYnVmZmVy
LWFsbG93LXRleHQtcHJvcGVydGllcwogICAgICAgOzsgSWYgd2UncmUgcHJlc2VydmluZyBw
cm9wZXJ0aWVzLCB0aGVuIGp1c3QgcmVtb3ZlIHRoZSBmYWNlcwogICAgICAgOzsgYW5kIG90
aGVyIHByb3BlcnRpZXMgYWRkZWQgYnkgdGhlIGNvbXBsZXRpb24gbWFjaGluZXJ5LgotICAg
ICAgKHJlbW92ZS10ZXh0LXByb3BlcnRpZXMgMCAobGVuZ3RoIG5ld3RleHQpICcoZmFjZSBj
b21wbGV0aW9uLXNjb3JlKQorICAgICAgKHJlbW92ZS10ZXh0LXByb3BlcnRpZXMgMCAobGVu
Z3RoIG5ld3RleHQpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAnKGZhY2Ugbmls
IGNvbXBsZXRpb24tc2NvcmUgbmlsKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
bmV3dGV4dCkKICAgICA7OyBSZW1vdmUgYWxsIHRleHQgcHJvcGVydGllcy4KICAgICAoc2V0
LXRleHQtcHJvcGVydGllcyAwIChsZW5ndGggbmV3dGV4dCkgbmlsIG5ld3RleHQpKQpAQCAt
MTM1Niw2ICsxNDM3LDcgQEAgY29tcGxldGlvbi0tY3ljbGUtdGhyZXNob2xkCiAKIChkZWZ2
YXItbG9jYWwgY29tcGxldGlvbi1hbGwtc29ydGVkLWNvbXBsZXRpb25zIG5pbCkKIChkZWZ2
YXItbG9jYWwgY29tcGxldGlvbi0tYWxsLXNvcnRlZC1jb21wbGV0aW9ucy1sb2NhdGlvbiBu
aWwpCisoZGVmdmFyLWxvY2FsIGNvbXBsZXRpb24tYWxsLXNvcnRlZC1oaWdobGlnaHQgbmls
KQogKGRlZnZhciBjb21wbGV0aW9uLWN5Y2xpbmcgbmlsKSAgICAgIDtGdW5jdGlvbiB0aGF0
IHRha2VzIGRvd24gdGhlIGN5Y2xpbmcgbWFwLgogKGRlZnZhciBjb21wbGV0aW9uLXRhYi13
aWR0aCBuaWwpCiAKQEAgLTE1NjIsMTIgKzE2NDQsMTUgQEAgY29tcGxldGlvbi0taW4tcmVn
aW9uLTEKICAgICAgICAgICA7OyBXaGVuIHRoZSBjb21wbGV0aW9uIGxpc3Qgd2luZG93IHdh
cyBkaXNwbGF5ZWQsIHNlbGVjdCBpdC4KICAgICAgICAgICAoc3dpdGNoLXRvLWNvbXBsZXRp
b25zKSkpKSkpCiAKLShkZWZ1biBjb21wbGV0aW9uLS1jYWNoZS1hbGwtc29ydGVkLWNvbXBs
ZXRpb25zIChiZWcgZW5kIGNvbXBzKQorKGRlZnVuIGNvbXBsZXRpb24tLWNhY2hlLWFsbC1z
b3J0ZWQtY29tcGxldGlvbnMgKGJlZyBlbmQgY29tcHMgJm9wdGlvbmFsIGhpZ2hsaWdodCkK
ICAgKGFkZC1ob29rICdhZnRlci1jaGFuZ2UtZnVuY3Rpb25zCiAgICAgICAgICAgICAjJ2Nv
bXBsZXRpb24tLWZsdXNoLWFsbC1zb3J0ZWQtY29tcGxldGlvbnMgbmlsIHQpCiAgIChzZXRx
IGNvbXBsZXRpb24tLWFsbC1zb3J0ZWQtY29tcGxldGlvbnMtbG9jYXRpb24KICAgICAgICAg
KGNvbnMgKGNvcHktbWFya2VyIGJlZykgKGNvcHktbWFya2VyIGVuZCkpKQotICAoc2V0cSBj
b21wbGV0aW9uLWFsbC1zb3J0ZWQtY29tcGxldGlvbnMgY29tcHMpKQorICAoc2V0cSBjb21w
bGV0aW9uLWFsbC1zb3J0ZWQtY29tcGxldGlvbnMgY29tcHMpCisgICh3aGVuIGhpZ2hsaWdo
dAorICAgIChzZXRxIGNvbXBsZXRpb24tYWxsLXNvcnRlZC1oaWdobGlnaHQgaGlnaGxpZ2h0
KSkKKyAgY29tcHMpCiAKIChkZWZ1biBjb21wbGV0aW9uLS1mbHVzaC1hbGwtc29ydGVkLWNv
bXBsZXRpb25zICgmb3B0aW9uYWwgc3RhcnQgZW5kIF9sZW4pCiAgICh1bmxlc3MgKGFuZCBz
dGFydCBlbmQKQEAgLTE1NzgsNyArMTY2Myw4IEBAIGNvbXBsZXRpb24tLWZsdXNoLWFsbC1z
b3J0ZWQtY29tcGxldGlvbnMKICAgICA7OyBSZW1vdmUgdGhlIHRyYW5zaWVudCBtYXAgaWYg
YXBwbGljYWJsZS4KICAgICAod2hlbiBjb21wbGV0aW9uLWN5Y2xpbmcKICAgICAgIChmdW5j
YWxsIChwcm9nMSBjb21wbGV0aW9uLWN5Y2xpbmcgKHNldHEgY29tcGxldGlvbi1jeWNsaW5n
IG5pbCkpKSkKLSAgICAoc2V0cSBjb21wbGV0aW9uLWFsbC1zb3J0ZWQtY29tcGxldGlvbnMg
bmlsKSkpCisgICAgKHNldHEgY29tcGxldGlvbi1hbGwtc29ydGVkLWNvbXBsZXRpb25zIG5p
bAorICAgICAgICAgIGNvbXBsZXRpb24tYWxsLXNvcnRlZC1oaWdobGlnaHQgbmlsKSkpCiAK
IChkZWZ1biBjb21wbGV0aW9uLS1tZXRhZGF0YSAoc3RyaW5nIGJhc2UgbWQtYXQtcG9pbnQg
dGFibGUgcHJlZCkKICAgOzsgTGlrZSBjb21wbGV0aW9uLW1ldGFkYXRhLCBidXQgZm9yIHRo
ZSBzcGVjaWZpYyBjYXNlIG9mIGdldHRpbmcgdGhlCkBAIC0xNjU2LDE0ICsxNzQyLDE1IEBA
IGNvbXBsZXRpb24tYWxsLXNvcnRlZC1jb21wbGV0aW9ucwogICAgICAgICAgICAgIChlbmQg
KG9yIGVuZCAocG9pbnQtbWF4KSkpCiAgICAgICAgICAgICAgKHN0cmluZyAoYnVmZmVyLXN1
YnN0cmluZyBzdGFydCBlbmQpKQogICAgICAgICAgICAgIChtZCAoY29tcGxldGlvbi0tZmll
bGQtbWV0YWRhdGEgc3RhcnQpKQotICAgICAgICAgICAgIChhbGwgKGNvbXBsZXRpb24tYWxs
LWNvbXBsZXRpb25zCi0gICAgICAgICAgICAgICAgICAgc3RyaW5nCi0gICAgICAgICAgICAg
ICAgICAgbWluaWJ1ZmZlci1jb21wbGV0aW9uLXRhYmxlCi0gICAgICAgICAgICAgICAgICAg
bWluaWJ1ZmZlci1jb21wbGV0aW9uLXByZWRpY2F0ZQotICAgICAgICAgICAgICAgICAgICgt
IChwb2ludCkgc3RhcnQpCi0gICAgICAgICAgICAgICAgICAgbWQpKQotICAgICAgICAgICAg
IChsYXN0IChsYXN0IGFsbCkpCi0gICAgICAgICAgICAgKGJhc2Utc2l6ZSAob3IgKGNkciBs
YXN0KSAwKSkKKyAgICAgICAgICAgICAoYWxpc3QgKGNvbXBsZXRpb24tZmlsdGVyLWNvbXBs
ZXRpb25zCisgICAgICAgICAgICAgICAgICAgICBzdHJpbmcKKyAgICAgICAgICAgICAgICAg
ICAgIG1pbmlidWZmZXItY29tcGxldGlvbi10YWJsZQorICAgICAgICAgICAgICAgICAgICAg
bWluaWJ1ZmZlci1jb21wbGV0aW9uLXByZWRpY2F0ZQorICAgICAgICAgICAgICAgICAgICAg
KC0gKHBvaW50KSBzdGFydCkKKyAgICAgICAgICAgICAgICAgICAgIG1kKSkKKyAgICAgICAg
ICAgICAoYWxsIChhc3NvYy1kZWZhdWx0ICdjb21wbGV0aW9ucyBhbGlzdCkpCisgICAgICAg
ICAgICAgKGJhc2Utc2l6ZSAoYXNzb2MtZGVmYXVsdCAnYmFzZSBhbGlzdCkpCisgICAgICAg
ICAgICAgKGhpZ2hsaWdodCAoYXNzb2MtZGVmYXVsdCAnaGlnaGxpZ2h0IGFsaXN0KSkKICAg
ICAgICAgICAgICAoYWxsLW1kIChjb21wbGV0aW9uLS1tZXRhZGF0YSAoYnVmZmVyLXN1YnN0
cmluZy1uby1wcm9wZXJ0aWVzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHN0YXJ0IChwb2ludCkpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgYmFzZS1zaXplIG1kCkBAIC0xNjcxLDE0ICsxNzU4LDExIEBAIGNv
bXBsZXRpb24tYWxsLXNvcnRlZC1jb21wbGV0aW9ucwogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIG1pbmlidWZmZXItY29tcGxldGlvbi1wcmVkaWNhdGUp
KQogICAgICAgICAgICAgIChzb3J0LWZ1biAoY29tcGxldGlvbi1tZXRhZGF0YS1nZXQgYWxs
LW1kICdjeWNsZS1zb3J0LWZ1bmN0aW9uKSkKICAgICAgICAgICAgICAoZ3JvdXAtZnVuIChj
b21wbGV0aW9uLW1ldGFkYXRhLWdldCBhbGwtbWQgJ2dyb3VwLWZ1bmN0aW9uKSkpCi0gICAg
ICAgICh3aGVuIGxhc3QKLSAgICAgICAgICAoc2V0Y2RyIGxhc3QgbmlsKQotCisgICAgICAg
ICh3aGVuIGFsbAogICAgICAgICAgIDs7IERlbGV0ZSBkdXBsaWNhdGVzOiBkbyBpdCBhZnRl
ciBzZXR0aW5nIGxhc3QncyBjZHIgdG8gbmlsIChzbwogICAgICAgICAgIDs7IGl0J3MgYSBw
cm9wZXIgbGlzdCksIGFuZCBiZSBjYXJlZnVsIHRvIHJlc2V0IGBsYXN0JyBzaW5jZSBpdAog
ICAgICAgICAgIDs7IG1heSBiZSBhIGRpZmZlcmVudCBjb25zLWNlbGwuCiAgICAgICAgICAg
KHNldHEgYWxsIChkZWxldGUtZHVwcyBhbGwpKQotICAgICAgICAgIChzZXRxIGxhc3QgKGxh
c3QgYWxsKSkKIAogICAgICAgICAgIChjb25kCiAgICAgICAgICAgIChzb3J0LWZ1biAoc2V0
cSBhbGwgKGZ1bmNhbGwgc29ydC1mdW4gYWxsKSkpCkBAIC0xNzA0LDcgKzE3ODgsNyBAQCBj
b21wbGV0aW9uLWFsbC1zb3J0ZWQtY29tcGxldGlvbnMKICAgICAgICAgICA7OyByZXBlYXRl
ZCBjYWxscyB0byBtaW5pYnVmZmVyLWZvcmNlLWNvbXBsZXRlIGNhbiBjeWNsZSB0aHJvdWdo
CiAgICAgICAgICAgOzsgYWxsIHBvc3NpYmlsaXRpZXMuCiAgICAgICAgICAgKGNvbXBsZXRp
b24tLWNhY2hlLWFsbC1zb3J0ZWQtY29tcGxldGlvbnMKLSAgICAgICAgICAgc3RhcnQgZW5k
IChuY29uYyBhbGwgYmFzZS1zaXplKSkpKSkpCisgICAgICAgICAgIHN0YXJ0IGVuZCAobmNv
bmMgYWxsIGJhc2Utc2l6ZSkgaGlnaGxpZ2h0KSkpKSkKIAogKGRlZnVuIG1pbmlidWZmZXIt
Zm9yY2UtY29tcGxldGUtYW5kLWV4aXQgKCkKICAgIkNvbXBsZXRlIHRoZSBtaW5pYnVmZmVy
IHdpdGggZmlyc3Qgb2YgdGhlIG1hdGNoZXMgYW5kIGV4aXQuIgpAQCAtMjIzOCwzNCArMjMy
Miw0OSBAQCBjb21wbGV0aW9uLWhpbGl0LWNvbW1vbmFsaXR5CiBJdCByZXR1cm5zIGEgbGlz
dCB3aXRoIGZvbnQtbG9jayBwcm9wZXJ0aWVzIGFwcGxpZWQgdG8gZWFjaCBlbGVtZW50LAog
YW5kIHdpdGggQkFTRS1TSVpFIGFwcGVuZGVkIGFzIHRoZSBsYXN0IGVsZW1lbnQuIgogICAo
d2hlbiBjb21wbGV0aW9ucwotICAgIChsZXQgKChjb20tc3RyLWxlbiAoLSBwcmVmaXgtbGVu
IChvciBiYXNlLXNpemUgMCkpKSkKLSAgICAgIChuY29uYwotICAgICAgIChtYXBjYXIKLSAg
ICAgICAgKGxhbWJkYSAoZWxlbSkKLSAgICAgICAgICAobGV0ICgoc3RyCi0gICAgICAgICAg
ICAgICAgIDs7IERvbid0IG1vZGlmeSB0aGUgc3RyaW5nIGl0c2VsZiwgYnV0IGEgY29weSwg
c2luY2UgdGhlCi0gICAgICAgICAgICAgICAgIDs7IHN0cmluZyBtYXkgYmUgcmVhZC1vbmx5
IG9yIHVzZWQgZm9yIG90aGVyIHB1cnBvc2VzLgotICAgICAgICAgICAgICAgICA7OyBGdXJ0
aGVybW9yZSwgc2luY2UgYGNvbXBsZXRpb25zJyBtYXkgY29tZSBmcm9tCi0gICAgICAgICAg
ICAgICAgIDs7IGRpc3BsYXktY29tcGxldGlvbi1saXN0LCBgZWxlbScgbWF5IGJlIGEgbGlz
dC4KLSAgICAgICAgICAgICAgICAgKGlmIChjb25zcCBlbGVtKQotICAgICAgICAgICAgICAg
ICAgICAgKGNhciAoc2V0cSBlbGVtIChjb25zIChjb3B5LXNlcXVlbmNlIChjYXIgZWxlbSkp
Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGNkciBlbGVt
KSkpKQotICAgICAgICAgICAgICAgICAgIChzZXRxIGVsZW0gKGNvcHktc2VxdWVuY2UgZWxl
bSkpKSkpCi0gICAgICAgICAgICAoZm9udC1sb2NrLXByZXBlbmQtdGV4dC1wcm9wZXJ0eQot
ICAgICAgICAgICAgIDAKLSAgICAgICAgICAgICA7OyBJZiBjb21wbGV0aW9uLWJvdW5kYXJp
ZXMgcmV0dXJucyBpbmNvcnJlY3QKLSAgICAgICAgICAgICA7OyB2YWx1ZXMsIGFsbC1jb21w
bGV0aW9ucyBtYXkgcmV0dXJuIHN0cmluZ3MKLSAgICAgICAgICAgICA7OyB0aGF0IGRvbid0
IGNvbnRhaW4gdGhlIHByZWZpeC4KLSAgICAgICAgICAgICAobWluIGNvbS1zdHItbGVuIChs
ZW5ndGggc3RyKSkKLSAgICAgICAgICAgICAnZmFjZSAnY29tcGxldGlvbnMtY29tbW9uLXBh
cnQgc3RyKQotICAgICAgICAgICAgKGlmICg+IChsZW5ndGggc3RyKSBjb20tc3RyLWxlbikK
LSAgICAgICAgICAgICAgICAoZm9udC1sb2NrLXByZXBlbmQtdGV4dC1wcm9wZXJ0eSBjb20t
c3RyLWxlbiAoMSsgY29tLXN0ci1sZW4pCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgJ2ZhY2UKLSAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAnY29tcGxldGlvbnMtZmlyc3QtZGlmZmVyZW5jZQot
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cikp
KQotICAgICAgICAgIGVsZW0pCi0gICAgICAgIGNvbXBsZXRpb25zKQotICAgICAgIGJhc2Ut
c2l6ZSkpKSkKKyAgICAobmNvbmMKKyAgICAgKGNvbXBsZXRpb24tLWhpbGl0LWNvbW1vbmFs
aXR5ICgtIHByZWZpeC1sZW4gKG9yIGJhc2Utc2l6ZSAwKSkgY29tcGxldGlvbnMpCisgICAg
IGJhc2Utc2l6ZSkpKQorCisoZGVmdW4gY29tcGxldGlvbi0taGlsaXQtY29tbW9uYWxpdHkg
KGNvbS1zaXplIGNvbXBsZXRpb25zKQorICAobWFwY2FyCisgICAobGFtYmRhIChlbGVtKQor
ICAgICAobGV0ICgoc3RyCisgICAgICAgICAgICA7OyBEb24ndCBtb2RpZnkgdGhlIHN0cmlu
ZyBpdHNlbGYsIGJ1dCBhIGNvcHksIHNpbmNlIHRoZQorICAgICAgICAgICAgOzsgc3RyaW5n
IG1heSBiZSByZWFkLW9ubHkgb3IgdXNlZCBmb3Igb3RoZXIgcHVycG9zZXMuCisgICAgICAg
ICAgICA7OyBGdXJ0aGVybW9yZSwgc2luY2UgYGNvbXBsZXRpb25zJyBtYXkgY29tZSBmcm9t
CisgICAgICAgICAgICA7OyBkaXNwbGF5LWNvbXBsZXRpb24tbGlzdCwgYGVsZW0nIG1heSBi
ZSBhIGxpc3QuCisgICAgICAgICAgICAoaWYgKGNvbnNwIGVsZW0pCisgICAgICAgICAgICAg
ICAgKGNhciAoc2V0cSBlbGVtIChjb25zIChjb3B5LXNlcXVlbmNlIChjYXIgZWxlbSkpCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjZHIgZWxlbSkpKSkKKyAg
ICAgICAgICAgICAgKHNldHEgZWxlbSAoY29weS1zZXF1ZW5jZSBlbGVtKSkpKSkKKyAgICAg
ICAoZm9udC1sb2NrLXByZXBlbmQtdGV4dC1wcm9wZXJ0eQorICAgICAgICAwCisgICAgICAg
IDs7IElmIGNvbXBsZXRpb24tYm91bmRhcmllcyByZXR1cm5zIGluY29ycmVjdAorICAgICAg
ICA7OyB2YWx1ZXMsIGFsbC1jb21wbGV0aW9ucyBtYXkgcmV0dXJuIHN0cmluZ3MKKyAgICAg
ICAgOzsgdGhhdCBkb24ndCBjb250YWluIHRoZSBwcmVmaXguCisgICAgICAgIChtaW4gY29t
LXNpemUgKGxlbmd0aCBzdHIpKQorICAgICAgICAnZmFjZSAnY29tcGxldGlvbnMtY29tbW9u
LXBhcnQgc3RyKQorICAgICAgIChpZiAoPiAobGVuZ3RoIHN0cikgY29tLXNpemUpCisgICAg
ICAgICAgIChmb250LWxvY2stcHJlcGVuZC10ZXh0LXByb3BlcnR5IGNvbS1zaXplICgxKyBj
b20tc2l6ZSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
J2ZhY2UKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJ2Nv
bXBsZXRpb25zLWZpcnN0LWRpZmZlcmVuY2UKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgc3RyKSkpCisgICAgIGVsZW0pCisgICBjb21wbGV0aW9ucykp
CisKKyhkZWZ1biBjb21wbGV0aW9uLS1kZWZlcnJlZC1oaWxpdCAoY29tcGxldGlvbnMgcHJl
Zml4LWxlbiBiYXNlIGVuZCkKKyAgIlJldHVybiBjb21wbGV0aW9ucyBhcyBhIGxpc3Qgb3Ig
YXMgYW4gYWxpc3QuCitJZiBgY29tcGxldGlvbi0tcmV0dXJuLWFsaXN0LWZsYWcnIGlzIG5v
bi1uaWwgdXNlIHRoZSBhbGlzdCBmb3JtYXQgb2YKK2Bjb21wbGV0aW9uLWZpbHRlci1jb21w
bGV0aW9ucycuIgorICAoaWYgY29tcGxldGlvbi0tcmV0dXJuLWFsaXN0LWZsYWcKKyAgICAg
ICh3aGVuIGNvbXBsZXRpb25zCisgICAgICAgIGAoKGJhc2UgLiAsYmFzZSkKKyAgICAgICAg
ICAoZW5kIC4gLGVuZCkKKyAgICAgICAgICAoaGlnaGxpZ2h0IC4gLChhcHBseS1wYXJ0aWFs
bHkgIydjb21wbGV0aW9uLS1oaWxpdC1jb21tb25hbGl0eQorICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAoLSBwcmVmaXgtbGVuIGJhc2UpKSkKKyAgICAgICAg
ICAoY29tcGxldGlvbnMgLiAsY29tcGxldGlvbnMpKSkKKyAgICAoY29tcGxldGlvbi1oaWxp
dC1jb21tb25hbGl0eSBjb21wbGV0aW9ucyBwcmVmaXgtbGVuIGJhc2UpKSkKIAogKGRlZnVu
IGRpc3BsYXktY29tcGxldGlvbi1saXN0IChjb21wbGV0aW9ucyAmb3B0aW9uYWwgY29tbW9u
LXN1YnN0cmluZyBncm91cC1mdW4pCiAgICJEaXNwbGF5IHRoZSBsaXN0IG9mIGNvbXBsZXRp
b25zLCBDT01QTEVUSU9OUywgdXNpbmcgYHN0YW5kYXJkLW91dHB1dCcuCkBAIC0yMzczLDE1
ICsyNDcyLDE2IEBAIG1pbmlidWZmZXItY29tcGxldGlvbi1oZWxwCiAgICAgICAgICAoZW5k
IChvciBlbmQgKHBvaW50LW1heCkpKQogICAgICAgICAgKHN0cmluZyAoYnVmZmVyLXN1YnN0
cmluZyBzdGFydCBlbmQpKQogICAgICAgICAgKG1kIChjb21wbGV0aW9uLS1maWVsZC1tZXRh
ZGF0YSBzdGFydCkpCi0gICAgICAgICAoY29tcGxldGlvbnMgKGNvbXBsZXRpb24tYWxsLWNv
bXBsZXRpb25zCi0gICAgICAgICAgICAgICAgICAgICAgIHN0cmluZwotICAgICAgICAgICAg
ICAgICAgICAgICBtaW5pYnVmZmVyLWNvbXBsZXRpb24tdGFibGUKLSAgICAgICAgICAgICAg
ICAgICAgICAgbWluaWJ1ZmZlci1jb21wbGV0aW9uLXByZWRpY2F0ZQotICAgICAgICAgICAg
ICAgICAgICAgICAoLSAocG9pbnQpIHN0YXJ0KQotICAgICAgICAgICAgICAgICAgICAgICBt
ZCkpKQorICAgICAgICAgKGZpbHRlcmVkLWNvbXBsZXRpb25zIChjb21wbGV0aW9uLWZpbHRl
ci1jb21wbGV0aW9ucworICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJpbmcK
KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWluaWJ1ZmZlci1jb21wbGV0aW9u
LXRhYmxlCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1pbmlidWZmZXItY29t
cGxldGlvbi1wcmVkaWNhdGUKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKC0g
KHBvaW50KSBzdGFydCkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWQpKQor
ICAgICAgICAgKGNvbXBsZXRpb25zIChhbGlzdC1nZXQgJ2NvbXBsZXRpb25zIGZpbHRlcmVk
LWNvbXBsZXRpb25zKSkpCiAgICAgKG1lc3NhZ2UgbmlsKQogICAgIChpZiAob3IgKG51bGwg
Y29tcGxldGlvbnMpCi0gICAgICAgICAgICAoYW5kIChub3QgKGNvbnNwIChjZHIgY29tcGxl
dGlvbnMpKSkKKyAgICAgICAgICAgIChhbmQgKG5vdCAoY2RyIGNvbXBsZXRpb25zKSkKICAg
ICAgICAgICAgICAgICAgKGVxdWFsIChjYXIgY29tcGxldGlvbnMpIHN0cmluZykpKQogICAg
ICAgICAocHJvZ24KICAgICAgICAgICA7OyBJZiB0aGVyZSBhcmUgbm8gY29tcGxldGlvbnMs
IG9yIGlmIHRoZSBjdXJyZW50IGlucHV0IGlzIGFscmVhZHkKQEAgLTIzOTMsOCArMjQ5Myw3
IEBAIG1pbmlidWZmZXItY29tcGxldGlvbi1oZWxwCiAJICAgICAgKGRpbmcpCiAJICAgICAg
KGNvbXBsZXRpb24tLW1lc3NhZ2UgIk5vIG1hdGNoIikpKSkKIAotICAgICAgKGxldCogKChs
YXN0IChsYXN0IGNvbXBsZXRpb25zKSkKLSAgICAgICAgICAgICAoYmFzZS1zaXplIChvciAo
Y2RyIGxhc3QpIDApKQorICAgICAgKGxldCogKChiYXNlLXNpemUgKGFsaXN0LWdldCAnYmFz
ZSBmaWx0ZXJlZC1jb21wbGV0aW9ucykpCiAgICAgICAgICAgICAgKHByZWZpeCAodW5sZXNz
ICh6ZXJvcCBiYXNlLXNpemUpIChzdWJzdHJpbmcgc3RyaW5nIDAgYmFzZS1zaXplKSkpCiAg
ICAgICAgICAgICAgKGJhc2UtcHJlZml4IChidWZmZXItc3Vic3RyaW5nIChtaW5pYnVmZmVy
LS1jb21wbGV0aW9uLXByb21wdC1lbmQpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICgrIHN0YXJ0IGJhc2Utc2l6ZSkpKQpAQCAtMjQ0Miw5ICsyNTQx
LDEyIEBAIG1pbmlidWZmZXItY29tcGxldGlvbi1oZWxwCiAgICAgICAgICAgICAoYm9keS1m
dW5jdGlvbgogICAgICAgICAgICAgIC4gLCMnKGxhbWJkYSAoX3dpbmRvdykKICAgICAgICAg
ICAgICAgICAgICAgKHdpdGgtY3VycmVudC1idWZmZXIgbWFpbmJ1ZgotICAgICAgICAgICAg
ICAgICAgICAgIDs7IFJlbW92ZSB0aGUgYmFzZS1zaXplIHRhaWwgYmVjYXVzZSBgc29ydCcg
cmVxdWlyZXMgYSBwcm9wZXJseQotICAgICAgICAgICAgICAgICAgICAgIDs7IG5pbC10ZXJt
aW5hdGVkIGxpc3QuCi0gICAgICAgICAgICAgICAgICAgICAgKHdoZW4gbGFzdCAoc2V0Y2Ry
IGxhc3QgbmlsKSkKKyAgICAgICAgICAgICAgICAgICAgICA7OyBBcHBseSBoaWdobGlnaHRp
bmcgdXNpbmcgdGhlIGRlZmVycmVkCisgICAgICAgICAgICAgICAgICAgICAgOzsgaGlnaGxp
Z2h0aW5nIGZ1bmN0aW9uIHByb3ZpZGVkIGJ5CisgICAgICAgICAgICAgICAgICAgICAgOzsg
YGNvbXBsZXRpb24tZm9ybWF0LWNvbXBsZXRpb25zJy4KKyAgICAgICAgICAgICAgICAgICAg
ICAoc2V0cSBjb21wbGV0aW9ucworICAgICAgICAgICAgICAgICAgICAgICAgICAgIChmdW5j
YWxsIChhbGlzdC1nZXQgJ2hpZ2hsaWdodCBmaWx0ZXJlZC1jb21wbGV0aW9ucykKKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb21wbGV0aW9ucykpCiAKICAgICAg
ICAgICAgICAgICAgICAgICA7OyBTb3J0IGZpcnN0IHVzaW5nIHRoZSBgZGlzcGxheS1zb3J0
LWZ1bmN0aW9uJy4KICAgICAgICAgICAgICAgICAgICAgICA7OyBGSVhNRTogVGhpcyBmdW5j
dGlvbiBpcyBmb3IgdGhlIG91dHB1dCBvZgpAQCAtMjQ4NiwxMyArMjU4OCwxMCBAQCBtaW5p
YnVmZmVyLWNvbXBsZXRpb24taGVscAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBjb21wbGV0aW9ucykpKSkKIAogICAgICAgICAgICAgICAgICAgICAgICh3aXRo
LWN1cnJlbnQtYnVmZmVyIHN0YW5kYXJkLW91dHB1dAotICAgICAgICAgICAgICAgICAgICAg
ICAgKHNldHEtbG9jYWwgY29tcGxldGlvbi1iYXNlLXBvc2l0aW9uCi0gICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIChsaXN0ICgrIHN0YXJ0IGJhc2Utc2l6ZSkKLSAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgOzsgRklYTUU6IFdlIHNob3VsZCBwYXkgYXR0ZW50
aW9uIHRvIGNvbXBsZXRpb24KLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
OzsgYm91bmRhcmllcyBoZXJlLCBidXQgY3VycmVudGx5Ci0gICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIDs7IGNvbXBsZXRpb24tYWxsLWNvbXBsZXRpb25zIGRvZXMgbm90
IGdpdmUgdXMgdGhlCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDs7IG5l
Y2Vzc2FyeSBpbmZvcm1hdGlvbi4KLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgZW5kKSkKKyAgICAgICAgICAgICAgICAgICAgICAgIChzZXRxLWxvY2FsCisgICAgICAg
ICAgICAgICAgICAgICAgICAgY29tcGxldGlvbi1iYXNlLXBvc2l0aW9uCisgICAgICAgICAg
ICAgICAgICAgICAgICAgKGxpc3QgKCsgc3RhcnQgYmFzZS1zaXplKQorICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICgrIHN0YXJ0IChhbGlzdC1nZXQgJ2VuZCBmaWx0ZXJlZC1j
b21wbGV0aW9ucykpKSkKICAgICAgICAgICAgICAgICAgICAgICAgIChzZXRxLWxvY2FsIGNv
bXBsZXRpb24tYmFzZS1hZmZpeGVzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAobGlzdCBiYXNlLXByZWZpeCBiYXNlLXN1ZmZpeCkpCiAgICAgICAgICAgICAgICAg
ICAgICAgICAoc2V0cS1sb2NhbCBjb21wbGV0aW9uLWxpc3QtaW5zZXJ0LWNob2ljZS1mdW5j
dGlvbgpAQCAtMzQ2OCwxMCArMzU2NywxMSBAQCBjb21wbGV0aW9uLWVtYWNzMjEtdHJ5LWNv
bXBsZXRpb24KICAgICAgIGNvbXBsZXRpb24pKSkKIAogKGRlZnVuIGNvbXBsZXRpb24tZW1h
Y3MyMS1hbGwtY29tcGxldGlvbnMgKHN0cmluZyB0YWJsZSBwcmVkIF9wb2ludCkKLSAgKGNv
bXBsZXRpb24taGlsaXQtY29tbW9uYWxpdHkKKyAgKGNvbXBsZXRpb24tLWRlZmVycmVkLWhp
bGl0CiAgICAoYWxsLWNvbXBsZXRpb25zIHN0cmluZyB0YWJsZSBwcmVkKQogICAgKGxlbmd0
aCBzdHJpbmcpCi0gICAoY2FyIChjb21wbGV0aW9uLWJvdW5kYXJpZXMgc3RyaW5nIHRhYmxl
IHByZWQgIiIpKSkpCisgICAoY2FyIChjb21wbGV0aW9uLWJvdW5kYXJpZXMgc3RyaW5nIHRh
YmxlIHByZWQgIiIpKQorICAgKGxlbmd0aCBzdHJpbmcpKSkKIAogKGRlZnVuIGNvbXBsZXRp
b24tZW1hY3MyMi10cnktY29tcGxldGlvbiAoc3RyaW5nIHRhYmxlIHByZWQgcG9pbnQpCiAg
IChsZXQgKChzdWZmaXggKHN1YnN0cmluZyBzdHJpbmcgcG9pbnQpKQpAQCAtMzQ5NCwxMSAr
MzU5NCwxMiBAQCBjb21wbGV0aW9uLWVtYWNzMjItdHJ5LWNvbXBsZXRpb24KICAgICAgIChj
b25zIChjb25jYXQgY29tcGxldGlvbiBzdWZmaXgpIChsZW5ndGggY29tcGxldGlvbikpKSkp
CiAKIChkZWZ1biBjb21wbGV0aW9uLWVtYWNzMjItYWxsLWNvbXBsZXRpb25zIChzdHJpbmcg
dGFibGUgcHJlZCBwb2ludCkKLSAgKGxldCAoKGJlZm9yZXBvaW50IChzdWJzdHJpbmcgc3Ry
aW5nIDAgcG9pbnQpKSkKLSAgICAoY29tcGxldGlvbi1oaWxpdC1jb21tb25hbGl0eQorICAo
bGV0KiAoKGJlZm9yZXBvaW50IChzdWJzdHJpbmcgc3RyaW5nIDAgcG9pbnQpKQorICAgICAg
ICAgKGFmdGVycG9pbnQgKHN1YnN0cmluZyBzdHJpbmcgcG9pbnQpKQorICAgICAgICAgKGJv
dW5kcyAoY29tcGxldGlvbi1ib3VuZGFyaWVzIGJlZm9yZXBvaW50IHRhYmxlIHByZWQgYWZ0
ZXJwb2ludCkpKQorICAgIChjb21wbGV0aW9uLS1kZWZlcnJlZC1oaWxpdAogICAgICAoYWxs
LWNvbXBsZXRpb25zIGJlZm9yZXBvaW50IHRhYmxlIHByZWQpCi0gICAgIHBvaW50Ci0gICAg
IChjYXIgKGNvbXBsZXRpb24tYm91bmRhcmllcyBiZWZvcmVwb2ludCB0YWJsZSBwcmVkICIi
KSkpKSkKKyAgICAgcG9pbnQgKGNhciBib3VuZHMpICgrIHBvaW50IChjZHIgYm91bmRzKSkp
KSkKIAogOzs7IEJhc2ljIGNvbXBsZXRpb24uCiAKQEAgLTM1NTcsNyArMzY1OCw3IEBAIGNv
bXBsZXRpb24tYmFzaWMtYWxsLWNvbXBsZXRpb25zCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJ3BvaW50CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHN1YnN0cmluZyBh
ZnRlcnBvaW50IDAgKGNkciBib3VuZHMpKSkpKQogICAgICAgICAgKGFsbCAoY29tcGxldGlv
bi1wY20tLWFsbC1jb21wbGV0aW9ucyBwcmVmaXggcGF0dGVybiB0YWJsZSBwcmVkKSkpCi0g
ICAgKGNvbXBsZXRpb24taGlsaXQtY29tbW9uYWxpdHkgYWxsIHBvaW50IChjYXIgYm91bmRz
KSkpKQorICAgIChjb21wbGV0aW9uLS1kZWZlcnJlZC1oaWxpdCBhbGwgcG9pbnQgKGNhciBi
b3VuZHMpICgrIHBvaW50IChjZHIgYm91bmRzKSkpKSkKIAogOzs7IFBhcnRpYWwtY29tcGxl
dGlvbi1tb2RlIHN0eWxlIGNvbXBsZXRpb24uCiAKQEAgLTM3NDksMTQgKzM4NTAsMjcgQEAg
ZmxleC1zY29yZS1tYXRjaC10aWdodG5lc3MKIHRoYW4gdGhlIGxhdHRlciAod2hpY2ggaGFz
IHR3byBcImhvbGVzXCIgYW5kIHRocmVlCiBvbmUtbGV0dGVyLWxvbmcgbWF0Y2hlcykuIikK
IAotKGRlZnVuIGNvbXBsZXRpb24tcGNtLS1oaWxpdC1jb21tb25hbGl0eSAocGF0dGVybiBj
b21wbGV0aW9ucykKKyhkZWZ1biBjb21wbGV0aW9uLXBjbS0tZGVmZXJyZWQtaGlsaXQgKHBh
dHRlcm4gY29tcGxldGlvbnMgYmFzZSBlbmQpCisgICJSZXR1cm4gY29tcGxldGlvbnMgYXMg
YSBsaXN0IG9yIGFzIGFuIGFsaXN0LgorSWYgYGNvbXBsZXRpb24tLXJldHVybi1hbGlzdC1m
bGFnJyBpcyBub24tbmlsIHVzZSB0aGUgYWxpc3QgZm9ybWF0IG9mCitgY29tcGxldGlvbi1m
aWx0ZXItY29tcGxldGlvbnMnLiIKKyAgKHdoZW4gY29tcGxldGlvbnMKKyAgICAoaWYgY29t
cGxldGlvbi0tcmV0dXJuLWFsaXN0LWZsYWcKKyAgICAgICAgYCgoYmFzZSAuICxiYXNlKQor
ICAgICAgICAgIChlbmQgLiAsZW5kKQorICAgICAgICAgIChoaWdobGlnaHQgLiAsKGFwcGx5
LXBhcnRpYWxseQorICAgICAgICAgICAgICAgICAgICAgICAgICMnY29tcGxldGlvbi1wY20t
LWhpbGl0LWNvbW1vbmFsaXR5CisgICAgICAgICAgICAgICAgICAgICAgICAgcGF0dGVybikp
CisgICAgICAgICAgKGNvbXBsZXRpb25zIC4gLGNvbXBsZXRpb25zKSkKKyAgICAgIChuY29u
YyAoY29tcGxldGlvbi1wY20tLWhpbGl0LWNvbW1vbmFsaXR5IHBhdHRlcm4gY29tcGxldGlv
bnMgJ3Njb3JlKSBiYXNlKSkpKQorCisoZGVmdW4gY29tcGxldGlvbi1wY20tLWhpbGl0LWNv
bW1vbmFsaXR5IChwYXR0ZXJuIGNvbXBsZXRpb25zICZvcHRpb25hbCBzY29yZSkKICAgIlNo
b3cgd2hlcmUgYW5kIGhvdyB3ZWxsIFBBVFRFUk4gbWF0Y2hlcyBDT01QTEVUSU9OUy4KIFBB
VFRFUk4sIGEgbGlzdCBvZiBzeW1ib2xzIGFuZCBzdHJpbmdzIGFzIHNlZW4KIGBjb21wbGV0
aW9uLXBjbS0tbWVyZ2UtY29tcGxldGlvbnMnLCBpcyBhc3N1bWVkIHRvIG1hdGNoIGV2ZXJ5
CiBzdHJpbmcgaW4gQ09NUExFVElPTlMuICBSZXR1cm4gYSBkZWVwIGNvcHkgb2YgQ09NUExF
VElPTlMgd2hlcmUKLWVhY2ggc3RyaW5nIGlzIHByb3BlcnRpemVkIHdpdGggYGNvbXBsZXRp
b24tc2NvcmUnLCBhIG51bWJlcgotYmV0d2VlbiAwIGFuZCAxLCBhbmQgd2l0aCBmYWNlcyBg
Y29tcGxldGlvbnMtY29tbW9uLXBhcnQnLAorZWFjaCBzdHJpbmcgaXMgcHJvcGVydGl6ZWQg
d2l0aCBmYWNlcyBgY29tcGxldGlvbnMtY29tbW9uLXBhcnQnLAogYGNvbXBsZXRpb25zLWZp
cnN0LWRpZmZlcmVuY2UnIGluIHRoZSByZWxldmFudCBzZWdtZW50cy4iCiAgIChjb25kCiAg
ICAoKGFuZCBjb21wbGV0aW9ucyAoY2wtbG9vcCBmb3IgZSBpbiBwYXR0ZXJuIHRoZXJlaXMg
KHN0cmluZ3AgZSkpKQogICAgIChsZXQqICgocmUgKGNvbXBsZXRpb24tcGNtLS1wYXR0ZXJu
LT5yZWdleCBwYXR0ZXJuICdncm91cCkpCkBAIC0zNzczLDg2ICszODg4LDE0NSBAQCBjb21w
bGV0aW9uLXBjbS0taGlsaXQtY29tbW9uYWxpdHkKICAgICAgICAgICAgICAgICAobWF0Y2gt
ZW5kIChtYXRjaC1lbmQgMCkpCiAgICAgICAgICAgICAgICAgKG1kIChjZGRyIChzZXRxIGxh
c3QtbWQgKG1hdGNoLWRhdGEgdCBsYXN0LW1kKSkpKQogICAgICAgICAgICAgICAgIChmcm9t
IDApCi0gICAgICAgICAgICAgICAgKGVuZCAobGVuZ3RoIHN0cikpCi0gICAgICAgICAgICAg
ICAgOzsgVG8gdW5kZXJzdGFuZCBob3cgdGhpcyB3b3JrcywgY29uc2lkZXIgdGhlc2Ugc2lt
cGxlCi0gICAgICAgICAgICAgICAgOzsgYXNjaWkgZGlhZ3JhbXMgc2hvd2luZyBob3cgdGhl
IHBhdHRlcm4gImZvbyIKLSAgICAgICAgICAgICAgICA7OyBmbGV4LW1hdGNoZXMgImZhYnJv
YmF6byIsICJmYmFyYmF6b28iIGFuZAotICAgICAgICAgICAgICAgIDs7ICJiYXJmb29iYXoi
OgotCi0gICAgICAgICAgICAgICAgOzsgICAgICBmIGFiciBvIGJheiBvCi0gICAgICAgICAg
ICAgICAgOzsgICAgICArIC0tLSArIC0tLSArCi0KLSAgICAgICAgICAgICAgICA7OyAgICAg
IGYgYmFyYmF6IG9vCi0gICAgICAgICAgICAgICAgOzsgICAgICArIC0tLS0tLSArKwotCi0g
ICAgICAgICAgICAgICAgOzsgICAgICBiYXIgZm9vIGJhegotICAgICAgICAgICAgICAgIDs7
ICAgICAgICAgICsrKwotCi0gICAgICAgICAgICAgICAgOzsgIisiIGluZGljYXRlcyBwYXJ0
cyB3aGVyZSB0aGUgcGF0dGVybiBtYXRjaGVkLiAgQQotICAgICAgICAgICAgICAgIDs7ICJo
b2xlIiBpbiB0aGUgbWlkZGxlIG9mIHRoZSBzdHJpbmcgaXMgaW5kaWNhdGVkIGJ5Ci0gICAg
ICAgICAgICAgICAgOzsgIi0iLiAgTm90ZSB0aGF0IHRoZXJlIGFyZSBubyAiaG9sZXMiIG5l
YXIgdGhlIGVkZ2VzCi0gICAgICAgICAgICAgICAgOzsgb2YgdGhlIHN0cmluZy4gIFRoZSBj
b21wbGV0aW9uIHNjb3JlIGlzIGEgbnVtYmVyCi0gICAgICAgICAgICAgICAgOzsgYm91bmQg
YnkgKDAuLjFdIChpLmUuLCBsYXJnZXIgdGhhbiAoYnV0IG5vdCBlcXVhbAotICAgICAgICAg
ICAgICAgIDs7IHRvKSB6ZXJvLCBhbmQgc21hbGxlciBvciBlcXVhbCB0byBvbmUpOiB0aGUg
aGlnaGVyCi0gICAgICAgICAgICAgICAgOzsgdGhlIGJldHRlciBhbmQgb25seSBhIHBlcmZl
Y3QgbWF0Y2ggKHBhdHRlcm4gZXF1YWxzCi0gICAgICAgICAgICAgICAgOzsgc3RyaW5nKSB3
aWxsIGhhdmUgc2NvcmUgMS4gIFRoZSBmb3JtdWxhIHRha2VzIHRoZQotICAgICAgICAgICAg
ICAgIDs7IGZvcm0gb2YgYSBxdW90aWVudC4gIEZvciB0aGUgbnVtZXJhdG9yLCB3ZSB1c2Ug
dGhlCi0gICAgICAgICAgICAgICAgOzsgbnVtYmVyIG9mICssIGkuZS4gdGhlIGxlbmd0aCBv
ZiB0aGUgcGF0dGVybi4gIEZvcgotICAgICAgICAgICAgICAgIDs7IHRoZSBkZW5vbWluYXRv
ciwgaXQgZmlyc3QgY29tcHV0ZXMKLSAgICAgICAgICAgICAgICA7OwotICAgICAgICAgICAg
ICAgIDs7ICAgICBob2xlX2lfY29udHJpYiA9IDEgKyAoTGktMSleKDEvdGlnaHRuZXNzKQot
ICAgICAgICAgICAgICAgIDs7Ci0gICAgICAgICAgICAgICAgOzsgLCBmb3IgZWFjaCBob2xl
ICJpIiBvZiBsZW5ndGggIkxpIiwgd2hlcmUgdGlnaHRuZXNzCi0gICAgICAgICAgICAgICAg
OzsgaXMgZ2l2ZW4gYnkgYGZsZXgtc2NvcmUtbWF0Y2gtdGlnaHRuZXNzJy4gIFRoZQotICAg
ICAgICAgICAgICAgIDs7IGZpbmFsIHZhbHVlIGZvciB0aGUgZGVub21pbmF0b3IgaXMgdGhl
biBnaXZlbiBieToKLSAgICAgICAgICAgICAgICA7OwotICAgICAgICAgICAgICAgIDs7ICAg
IChTVU1fYWNyb3NzX2koaG9sZV9pX2NvbnRyaWIpICsgMSkgKiBsZW4KLSAgICAgICAgICAg
ICAgICA7OwotICAgICAgICAgICAgICAgIDs7ICwgd2hlcmUgImxlbiIgaXMgdGhlIHN0cmlu
ZydzIGxlbmd0aC4KLSAgICAgICAgICAgICAgICAoc2NvcmUtbnVtZXJhdG9yIDApCi0gICAg
ICAgICAgICAgICAgKHNjb3JlLWRlbm9taW5hdG9yIDApCi0gICAgICAgICAgICAgICAgKGxh
c3QtYiAwKQotICAgICAgICAgICAgICAgICh1cGRhdGUtc2NvcmUtYW5kLWZhY2UKLSAgICAg
ICAgICAgICAgICAgKGxhbWJkYSAoYSBiKQotICAgICAgICAgICAgICAgICAgICJVcGRhdGUg
c2NvcmUgYW5kIGZhY2UgZ2l2ZW4gbWF0Y2ggcmFuZ2UgKEEgQikuIgotICAgICAgICAgICAg
ICAgICAgIChhZGQtZmFjZS10ZXh0LXByb3BlcnR5IGEgYgotICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICdjb21wbGV0aW9ucy1jb21tb24tcGFydAotICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5pbCBzdHIpCi0gICAg
ICAgICAgICAgICAgICAgKHNldHEKLSAgICAgICAgICAgICAgICAgICAgc2NvcmUtbnVtZXJh
dG9yICAgKCsgc2NvcmUtbnVtZXJhdG9yICgtIGIgYSkpKQotICAgICAgICAgICAgICAgICAg
ICh1bmxlc3MgKG9yICg9IGEgbGFzdC1iKQotICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICh6ZXJvcCBsYXN0LWIpCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKD0g
YSAobGVuZ3RoIHN0cikpKQotICAgICAgICAgICAgICAgICAgICAgKHNldHEKLSAgICAgICAg
ICAgICAgICAgICAgICBzY29yZS1kZW5vbWluYXRvciAoKyBzY29yZS1kZW5vbWluYXRvcgot
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEKLSAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoZXhwdCAoLSBhIGxhc3QtYiAx
KQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICgv
IDEuMAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGZsZXgtc2NvcmUtbWF0Y2gtdGlnaHRuZXNzKSkpKSkKLSAgICAgICAgICAgICAgICAg
ICAoc2V0cQotICAgICAgICAgICAgICAgICAgICBsYXN0LWIgICAgICAgICAgICAgIGIpKSkp
CisgICAgICAgICAgICAgICAgKGxlbiAobGVuZ3RoIHN0cikpKQorICAgICAgICAgICAod2hl
biAoYW5kIHNjb3JlICgvPSAwIGxlbikpCisgICAgICAgICAgICAgKHB1dC10ZXh0LXByb3Bl
cnR5CisgICAgICAgICAgICAgIDAgMSAnY29tcGxldGlvbi1zY29yZSAoLSAoY29tcGxldGlv
bi0tZmxleC1zY29yZS0xIG1kIG1hdGNoLWVuZCBsZW4pKSBzdHIpKQogICAgICAgICAgICAo
d2hpbGUgbWQKLSAgICAgICAgICAgICAoZnVuY2FsbCB1cGRhdGUtc2NvcmUtYW5kLWZhY2Ug
ZnJvbSAocG9wIG1kKSkKKyAgICAgICAgICAgICAoYWRkLWZhY2UtdGV4dC1wcm9wZXJ0eSBm
cm9tIChwb3AgbWQpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJ2Nv
bXBsZXRpb25zLWNvbW1vbi1wYXJ0CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgbmlsIHN0cikKICAgICAgICAgICAgICAoc2V0cSBmcm9tIChwb3AgbWQpKSkKICAg
ICAgICAgICAgOzsgSWYgYHBhdHRlcm4nIGRvZXNuJ3QgaGF2ZSBhbiBleHBsaWNpdCB0cmFp
bGluZyBhbnksIHRoZQogICAgICAgICAgICA7OyByZWdleCBgcmUnIHdvbid0IHByb2R1Y2Ug
bWF0Y2ggZGF0YSByZXByZXNlbnRpbmcgdGhlCiAgICAgICAgICAgIDs7IHJlZ2lvbiBhZnRl
ciB0aGUgbWF0Y2guICBXZSBuZWVkIHRvIGFjY291bnQgdG8gYWNjb3VudAogICAgICAgICAg
ICA7OyBmb3IgdGhhdCBleHRyYSBiaXQgb2YgbWF0Y2ggKGJ1ZyM0MjE0OSkuCiAgICAgICAg
ICAgICh1bmxlc3MgKD0gZnJvbSBtYXRjaC1lbmQpCi0gICAgICAgICAgICAgKGZ1bmNhbGwg
dXBkYXRlLXNjb3JlLWFuZC1mYWNlIGZyb20gbWF0Y2gtZW5kKSkKLSAgICAgICAgICAgKGlm
ICg+IChsZW5ndGggc3RyKSBwb3MpCisgICAgICAgICAgICAgKGFkZC1mYWNlLXRleHQtcHJv
cGVydHkgZnJvbSBtYXRjaC1lbmQKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAnY29tcGxldGlvbnMtY29tbW9uLXBhcnQKKyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBuaWwgc3RyKSkKKyAgICAgICAgICAgKGlmICg+IGxlbiBwb3MpCiAg
ICAgICAgICAgICAgICAoYWRkLWZhY2UtdGV4dC1wcm9wZXJ0eQogICAgICAgICAgICAgICAg
IHBvcyAoMSsgcG9zKQogICAgICAgICAgICAgICAgICdjb21wbGV0aW9ucy1maXJzdC1kaWZm
ZXJlbmNlCi0gICAgICAgICAgICAgICAgbmlsIHN0cikpCi0gICAgICAgICAgICh1bmxlc3Mg
KHplcm9wIChsZW5ndGggc3RyKSkKLSAgICAgICAgICAgICAocHV0LXRleHQtcHJvcGVydHkK
LSAgICAgICAgICAgICAgMCAxICdjb21wbGV0aW9uLXNjb3JlCi0gICAgICAgICAgICAgICgv
IHNjb3JlLW51bWVyYXRvciAoKiBlbmQgKDErIHNjb3JlLWRlbm9taW5hdG9yKSkgMS4wKSBz
dHIpKSkKKyAgICAgICAgICAgICAgICBuaWwgc3RyKSkpCiAgICAgICAgICBzdHIpCiAgICAg
ICAgY29tcGxldGlvbnMpKSkKICAgICh0IGNvbXBsZXRpb25zKSkpCiAKKyhkZWZ1biBjb21w
bGV0aW9uLS1mbGV4LXNjb3JlLTEgKG1kIG1hdGNoLWVuZCBsZW4pCisgICJDb21wdXRlIG1h
dGNoaW5nIHNjb3JlIG9mIGNvbXBsZXRpb24uCitUaGUgc2NvcmUgbGllcyBpbiB0aGUgcmFu
Z2UgYmV0d2Vlbi0xIGFuZCAwLCB3aGVyZSAtMSBjb3JyZXNwb25kcyB0bwordGhlIGZ1bGwg
bWF0Y2guCitNRCBpcyB0aGUgbWF0Y2ggZGF0YS4KK01BVENILUVORCBpcyB0aGUgZW5kIG9m
IHRoZSBtYXRjaC4KK0xFTiBpcyB0aGUgbGVuZ3RoIG9mIHRoZSBjb21wbGV0aW9uIHN0cmlu
Zy4iCisgIChsZXQqICgoZnJvbSAwKQorICAgICAgICAgOzsgVG8gdW5kZXJzdGFuZCBob3cg
dGhpcyB3b3JrcywgY29uc2lkZXIgdGhlc2Ugc2ltcGxlCisgICAgICAgICA7OyBhc2NpaSBk
aWFncmFtcyBzaG93aW5nIGhvdyB0aGUgcGF0dGVybiAiZm9vIgorICAgICAgICAgOzsgZmxl
eC1tYXRjaGVzICJmYWJyb2Jhem8iLCAiZmJhcmJhem9vIiBhbmQKKyAgICAgICAgIDs7ICJi
YXJmb29iYXoiOgorCisgICAgICAgICA7OyAgICAgIGYgYWJyIG8gYmF6IG8KKyAgICAgICAg
IDs7ICAgICAgKyAtLS0gKyAtLS0gKworCisgICAgICAgICA7OyAgICAgIGYgYmFyYmF6IG9v
CisgICAgICAgICA7OyAgICAgICsgLS0tLS0tICsrCisKKyAgICAgICAgIDs7ICAgICAgYmFy
IGZvbyBiYXoKKyAgICAgICAgIDs7ICAgICAgICAgICsrKworCisgICAgICAgICA7OyAiKyIg
aW5kaWNhdGVzIHBhcnRzIHdoZXJlIHRoZSBwYXR0ZXJuIG1hdGNoZWQuICBBCisgICAgICAg
ICA7OyAiaG9sZSIgaW4gdGhlIG1pZGRsZSBvZiB0aGUgc3RyaW5nIGlzIGluZGljYXRlZCBi
eQorICAgICAgICAgOzsgIi0iLiAgTm90ZSB0aGF0IHRoZXJlIGFyZSBubyAiaG9sZXMiIG5l
YXIgdGhlIGVkZ2VzCisgICAgICAgICA7OyBvZiB0aGUgc3RyaW5nLiAgVGhlIGNvbXBsZXRp
b24gc2NvcmUgaXMgYSBudW1iZXIKKyAgICAgICAgIDs7IGJvdW5kIGJ5ICgwLi4xXSAoaS5l
LiwgbGFyZ2VyIHRoYW4gKGJ1dCBub3QgZXF1YWwKKyAgICAgICAgIDs7IHRvKSB6ZXJvLCBh
bmQgc21hbGxlciBvciBlcXVhbCB0byBvbmUpOiB0aGUgaGlnaGVyCisgICAgICAgICA7OyB0
aGUgYmV0dGVyIGFuZCBvbmx5IGEgcGVyZmVjdCBtYXRjaCAocGF0dGVybiBlcXVhbHMKKyAg
ICAgICAgIDs7IHN0cmluZykgd2lsbCBoYXZlIHNjb3JlIDEuICBUaGUgZm9ybXVsYSB0YWtl
cyB0aGUKKyAgICAgICAgIDs7IGZvcm0gb2YgYSBxdW90aWVudC4gIEZvciB0aGUgbnVtZXJh
dG9yLCB3ZSB1c2UgdGhlCisgICAgICAgICA7OyBudW1iZXIgb2YgKywgaS5lLiB0aGUgbGVu
Z3RoIG9mIHRoZSBwYXR0ZXJuLiAgRm9yCisgICAgICAgICA7OyB0aGUgZGVub21pbmF0b3Is
IGl0IGZpcnN0IGNvbXB1dGVzCisgICAgICAgICA7OworICAgICAgICAgOzsgICAgIGhvbGVf
aV9jb250cmliID0gMSArIChMaS0xKV4oMS90aWdodG5lc3MpCisgICAgICAgICA7OworICAg
ICAgICAgOzsgLCBmb3IgZWFjaCBob2xlICJpIiBvZiBsZW5ndGggIkxpIiwgd2hlcmUgdGln
aHRuZXNzCisgICAgICAgICA7OyBpcyBnaXZlbiBieSBgZmxleC1zY29yZS1tYXRjaC10aWdo
dG5lc3MnLiAgVGhlCisgICAgICAgICA7OyBmaW5hbCB2YWx1ZSBmb3IgdGhlIGRlbm9taW5h
dG9yIGlzIHRoZW4gZ2l2ZW4gYnk6CisgICAgICAgICA7OworICAgICAgICAgOzsgICAgKFNV
TV9hY3Jvc3NfaShob2xlX2lfY29udHJpYikgKyAxKSAqIGxlbgorICAgICAgICAgOzsKKyAg
ICAgICAgIDs7ICwgd2hlcmUgImxlbiIgaXMgdGhlIHN0cmluZydzIGxlbmd0aC4KKyAgICAg
ICAgIChzY29yZS1udW1lcmF0b3IgMCkKKyAgICAgICAgIChzY29yZS1kZW5vbWluYXRvciAw
KQorICAgICAgICAgKGxhc3QtYiAwKSkKKyAgICAod2hpbGUgbWQKKyAgICAgIChsZXQgKChh
IGZyb20pCisgICAgICAgICAgICAoYiAocG9wIG1kKSkpCisgICAgICAgIChzZXRxCisgICAg
ICAgICBzY29yZS1udW1lcmF0b3IgICAoKyBzY29yZS1udW1lcmF0b3IgKC0gYiBhKSkpCisg
ICAgICAgICh1bmxlc3MgKG9yICg9IGEgbGFzdC1iKQorICAgICAgICAgICAgICAgICAgICAo
emVyb3AgbGFzdC1iKQorICAgICAgICAgICAgICAgICAgICAoPSBhIGxlbikpCisgICAgICAg
ICAgKHNldHEKKyAgICAgICAgICAgc2NvcmUtZGVub21pbmF0b3IgKCsgc2NvcmUtZGVub21p
bmF0b3IKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMQorICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAoZXhwdCAoLSBhIGxhc3QtYiAxKQorICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAoLyAxLjAKKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgZmxleC1zY29yZS1tYXRjaC10aWdodG5lc3MpKSkpKQor
ICAgICAgICAoc2V0cQorICAgICAgICAgbGFzdC1iICAgICAgICAgICAgICBiKSkKKyAgICAg
IChzZXRxIGZyb20gKHBvcCBtZCkpKQorICAgIDs7IElmIGBwYXR0ZXJuJyBkb2Vzbid0IGhh
dmUgYW4gZXhwbGljaXQgdHJhaWxpbmcgYW55LCB0aGUKKyAgICA7OyByZWdleCBgcmUnIHdv
bid0IHByb2R1Y2UgbWF0Y2ggZGF0YSByZXByZXNlbnRpbmcgdGhlCisgICAgOzsgcmVnaW9u
IGFmdGVyIHRoZSBtYXRjaC4gIFdlIG5lZWQgdG8gYWNjb3VudCB0byBhY2NvdW50CisgICAg
OzsgZm9yIHRoYXQgZXh0cmEgYml0IG9mIG1hdGNoIChidWcjNDIxNDkpLgorICAgICh1bmxl
c3MgKD0gZnJvbSBtYXRjaC1lbmQpCisgICAgICAobGV0ICgoYSBmcm9tKQorICAgICAgICAg
ICAgKGIgbWF0Y2gtZW5kKSkKKyAgICAgICAgKHNldHEKKyAgICAgICAgIHNjb3JlLW51bWVy
YXRvciAgICgrIHNjb3JlLW51bWVyYXRvciAoLSBiIGEpKSkKKyAgICAgICAgKHVubGVzcyAo
b3IgKD0gYSBsYXN0LWIpCisgICAgICAgICAgICAgICAgICAgICh6ZXJvcCBsYXN0LWIpCisg
ICAgICAgICAgICAgICAgICAgICg9IGEgbGVuKSkKKyAgICAgICAgICAoc2V0cQorICAgICAg
ICAgICBzY29yZS1kZW5vbWluYXRvciAoKyBzY29yZS1kZW5vbWluYXRvcgorICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAxCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIChleHB0ICgtIGEgbGFzdC1iIDEpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICgvIDEuMAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBmbGV4LXNjb3JlLW1hdGNoLXRpZ2h0bmVzcykpKSkpCisgICAgICAgIChzZXRxCisg
ICAgICAgICBsYXN0LWIgICAgICAgICAgICAgIGIpKSkKKyAgICAoLSAoLyBzY29yZS1udW1l
cmF0b3IgKCogbGVuICgxKyBzY29yZS1kZW5vbWluYXRvcikpIDEuMCkpKSkKKworKGRlZnVu
IGNvbXBsZXRpb24tLWZsZXgtc2NvcmUgKHBhdHRlcm4gY29tcGxldGlvbnMpCisgICJDb21w
dXRlIGhvdyB3ZWxsIFBBVFRFUk4gbWF0Y2hlcyBDT01QTEVUSU9OUy4KK1BBVFRFUk4sIGEg
cGNtIHBhdHRlcm4gaXMgYXNzdW1lZCB0byBtYXRjaCBldmVyeSBzdHJpbmcgaW4gdGhlCitD
T01QTEVUSU9OUyBsaXN0LiAgUmV0dXJuIGEgY29weSBvZiBDT01QTEVUSU9OUyB3aGVyZSBl
YWNoIGVsZW1lbnQgaXMKK2EgcGFpciBvZiBhIHNjb3JlIGFuZCB0aGUgc3RyaW5nLiAgVGhl
IHNjb3JlIGxpZXMgaW4gdGhlIHJhbmdlIGJldHdlZW4KKy0xIGFuZCAwLCB3aGVyZSAtMSBj
b3JyZXNwb25kcyB0byB0aGUgZnVsbCBtYXRjaC4iCisgICh3aGVuIGNvbXBsZXRpb25zCisg
ICAgKGxldCogKChyZSAoY29tcGxldGlvbi1wY20tLXBhdHRlcm4tPnJlZ2V4IHBhdHRlcm4g
J2dyb3VwKSkKKyAgICAgICAgICAgKGNhc2UtZm9sZC1zZWFyY2ggY29tcGxldGlvbi1pZ25v
cmUtY2FzZSkKKyAgICAgICAgICAgbGFzdC1tZCkKKyAgICAgIChtYXBjYXIKKyAgICAgICAo
bGFtYmRhIChzdHIpCisgICAgICAgICA7OyBUaGUgZmxleCBjb21wbGV0aW9uIHN0eWxlIHJl
cXVpcmVzIHRoZSBjb21wbGV0aW9uIHRvIG1hdGNoCisgICAgICAgICA7OyB0aGUgcGF0dGVy
biB0byBjb21wdXRlIHRoZSBzY29yaW5nLiAgRm9yIHF1b3RlZCBjb21wbGV0aW9uCisgICAg
ICAgICA7OyB0YWJsZXMgdGhlIGNvbXBsZXRpb25zIGFyZSBtYXRjaGVkIGFnYWluc3QgdGhl
ICp1bnF1b3RlZAorICAgICAgICAgOzsgaW5wdXQgc3RyaW5nKi4gIEhvd2V2ZXIgYGNvbXBs
ZXRpb24tYWxsLWNvbXBsZXRpb25zJyBhbmQKKyAgICAgICAgIDs7IGBjb21wbGV0aW9uLWZp
bHRlci1jb21wbGV0aW9ucycgcmV0dXJuIGEgbGlzdCBvZiAqcXVvdGVkCisgICAgICAgICA7
OyBjb21wbGV0aW9ucyosIHdoaWNoIGlzIHN1YnNlcXVlbnRseSBzb3J0ZWQuICBUaGVyZWZv
cmUgd2UKKyAgICAgICAgIDs7IG9idGFpbiB0aGUgdW5xdW90ZWQgY29tcGxldGlvbiBzdHJp
bmcgd2hpY2ggaXMgc3RvcmVkIGluCisgICAgICAgICA7OyB0aGUgdGV4dCBwcm9wZXJ0eSBg
Y29tcGxldGlvbi0tdW5xdW90ZWQnLgorICAgICAgICAgKGxldCAoKHVucXVvdGVkIChvciAo
Z2V0LXRleHQtcHJvcGVydHkgMCAnY29tcGxldGlvbi0tdW5xdW90ZWQgc3RyKSBzdHIpKSkK
KyAgICAgICAgICAgKHVubGVzcyAoc3RyaW5nLW1hdGNoIHJlIHVucXVvdGVkKQorICAgICAg
ICAgICAgIChlcnJvciAiSW50ZXJuYWwgZXJyb3I6ICVzIGRvZXMgbm90IG1hdGNoICVzIiBy
ZSB1bnF1b3RlZCkpCisgICAgICAgICAgIChjb25zIChjb21wbGV0aW9uLS1mbGV4LXNjb3Jl
LTEgKGNkZHIgKHNldHEgbGFzdC1tZCAobWF0Y2gtZGF0YSB0IGxhc3QtbWQpKSkKKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAobWF0Y2gtZW5kIDApIChs
ZW5ndGggdW5xdW90ZWQpKQorICAgICAgICAgICAgICAgICBzdHIpKSkKKyAgICAgICBjb21w
bGV0aW9ucykpKSkKKwogKGRlZnVuIGNvbXBsZXRpb24tcGNtLS1maW5kLWFsbC1jb21wbGV0
aW9ucyAoc3RyaW5nIHRhYmxlIHByZWQgcG9pbnQKICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmb3B0aW9uYWwgZmlsdGVyKQogICAiRmlu
ZCBhbGwgY29tcGxldGlvbnMgZm9yIFNUUklORyBhdCBQT0lOVCBpbiBUQUJMRSwgc2F0aXNm
eWluZyBQUkVELgpAQCAtMzk0OCwxMSArNDEyMiwxMSBAQCBjb21wbGV0aW9uLXBjbS0tZmlu
ZC1hbGwtY29tcGxldGlvbnMKICAgICAgICAgKGxpc3QgcGF0dGVybiBhbGwgcHJlZml4IHN1
ZmZpeCkpKSkpCiAKIChkZWZ1biBjb21wbGV0aW9uLXBjbS1hbGwtY29tcGxldGlvbnMgKHN0
cmluZyB0YWJsZSBwcmVkIHBvaW50KQotICAocGNhc2UtbGV0ICgoYCgscGF0dGVybiAsYWxs
ICxwcmVmaXggLF9zdWZmaXgpCisgIChwY2FzZS1sZXQgKChgKCxwYXR0ZXJuICxhbGwgLHBy
ZWZpeCAsc3VmZml4KQogICAgICAgICAgICAgICAgKGNvbXBsZXRpb24tcGNtLS1maW5kLWFs
bC1jb21wbGV0aW9ucyBzdHJpbmcgdGFibGUgcHJlZCBwb2ludCkpKQotICAgICh3aGVuIGFs
bAotICAgICAgKG5jb25jIChjb21wbGV0aW9uLXBjbS0taGlsaXQtY29tbW9uYWxpdHkgcGF0
dGVybiBhbGwpCi0gICAgICAgICAgICAgKGxlbmd0aCBwcmVmaXgpKSkpKQorICAgIChjb21w
bGV0aW9uLXBjbS0tZGVmZXJyZWQtaGlsaXQgcGF0dGVybiBhbGwKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIChsZW5ndGggcHJlZml4KQorICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgKC0gKGxlbmd0aCBzdHJpbmcpIChsZW5ndGggc3VmZml4
KSkpKSkKIAogKGRlZnVuIGNvbXBsZXRpb24tLWNvbW1vbi1zdWZmaXggKHN0cnMpCiAgICJS
ZXR1cm4gdGhlIGNvbW1vbiBzdWZmaXggb2YgdGhlIHN0cmluZ3MgU1RSUy4iCkBAIC00MTM2
LDggKzQzMTAsOCBAQCBjb21wbGV0aW9uLXBjbS10cnktY29tcGxldGlvbgogOzs7IFN1YnN0
cmluZyBjb21wbGV0aW9uCiA7OyBNb3N0bHkgZGVyaXZlZCBmcm9tIHRoZSBjb2RlIG9mIGBi
YXNpYycgY29tcGxldGlvbi4KIAotKGRlZnVuIGNvbXBsZXRpb24tc3Vic3RyaW5nLS1hbGwt
Y29tcGxldGlvbnMKLSAgICAoc3RyaW5nIHRhYmxlIHByZWQgcG9pbnQgJm9wdGlvbmFsIHRy
YW5zZm9ybS1wYXR0ZXJuLWZuKQorKGRlZnVuIGNvbXBsZXRpb24tLXBhdHRlcm4tY29tcGls
ZXIKKyAgICAoc3RyaW5nIHRhYmxlIHByZWQgcG9pbnQgdHJhbnNmb3JtLXBhdHRlcm4tZm4p
CiAgICJNYXRjaCB0aGUgcHJlc3VtZWQgc3Vic3RyaW5nIFNUUklORyB0byB0aGUgZW50cmll
cyBpbiBUQUJMRS4KIFJlc3BlY3QgUFJFRCBhbmQgUE9JTlQuICBUaGUgcGF0dGVybiB1c2Vk
IGlzIGEgUENNLXN0eWxlCiBzdWJzdHJpbmcgcGF0dGVybiwgYnV0IGl0IGJlIG1hc3NhZ2Vk
IGJ5IFRSQU5TRk9STS1QQVRURVJOLUZOLCBpZgpAQCAtNDE1NSwxMiArNDMyOSwyMyBAQCBj
b21wbGV0aW9uLXN1YnN0cmluZy0tYWxsLWNvbXBsZXRpb25zCiAgICAgICAgICAocGF0dGVy
biAoY29tcGxldGlvbi1wY20tLW9wdGltaXplLXBhdHRlcm4KICAgICAgICAgICAgICAgICAg
ICAoaWYgdHJhbnNmb3JtLXBhdHRlcm4tZm4KICAgICAgICAgICAgICAgICAgICAgICAgKGZ1
bmNhbGwgdHJhbnNmb3JtLXBhdHRlcm4tZm4gcGF0dGVybikKLSAgICAgICAgICAgICAgICAg
ICAgIHBhdHRlcm4pKSkKLSAgICAgICAgIChhbGwgKGNvbXBsZXRpb24tcGNtLS1hbGwtY29t
cGxldGlvbnMgcHJlZml4IHBhdHRlcm4gdGFibGUgcHJlZCkpKQotICAgIChsaXN0IGFsbCBw
YXR0ZXJuIHByZWZpeCBzdWZmaXggKGNhciBib3VuZHMpKSkpCisgICAgICAgICAgICAgICAg
ICAgICBwYXR0ZXJuKSkpKQorICAgIChsaXN0IHBhdHRlcm4gcHJlZml4IHN1ZmZpeCkpKQor
CisoZGVmdW4gY29tcGxldGlvbi1zdWJzdHJpbmctLWFsbC1jb21wbGV0aW9ucworICAgIChz
dHJpbmcgdGFibGUgcHJlZCBwb2ludCAmb3B0aW9uYWwgdHJhbnNmb3JtLXBhdHRlcm4tZm4p
CisgICJNYXRjaCB0aGUgcHJlc3VtZWQgc3Vic3RyaW5nIFNUUklORyB0byB0aGUgZW50cmll
cyBpbiBUQUJMRS4KK1Jlc3BlY3QgUFJFRCBhbmQgUE9JTlQuICBUaGUgcGF0dGVybiB1c2Vk
IGlzIGEgUENNLXN0eWxlCitzdWJzdHJpbmcgcGF0dGVybiwgYnV0IGl0IGJlIG1hc3NhZ2Vk
IGJ5IFRSQU5TRk9STS1QQVRURVJOLUZOLCBpZgordGhhdCBpcyBub24tbmlsLiIKKyAgKHBj
YXNlLWxldCAoKChhbmQgcmVzdWx0IGAoLHBhdHRlcm4gLHByZWZpeCAsX3N1ZmZpeCkpCisg
ICAgICAgICAgICAgICAoY29tcGxldGlvbi0tcGF0dGVybi1jb21waWxlciBzdHJpbmcgdGFi
bGUgcHJlZCBwb2ludAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgdHJhbnNmb3JtLXBhdHRlcm4tZm4pKSkKKyAgICAoY29ucyAoY29tcGxldGlvbi1w
Y20tLWFsbC1jb21wbGV0aW9ucyBwcmVmaXggcGF0dGVybiB0YWJsZSBwcmVkKQorICAgICAg
ICAgIHJlc3VsdCkpKQogCiAoZGVmdW4gY29tcGxldGlvbi1zdWJzdHJpbmctdHJ5LWNvbXBs
ZXRpb24gKHN0cmluZyB0YWJsZSBwcmVkIHBvaW50KQotICAocGNhc2UtbGV0ICgoYCgsYWxs
ICxwYXR0ZXJuICxwcmVmaXggLHN1ZmZpeCAsX2NhcmJvdW5kcykKKyAgKHBjYXNlLWxldCAo
KGAoLGFsbCAscGF0dGVybiAscHJlZml4ICxzdWZmaXgpCiAgICAgICAgICAgICAgICAoY29t
cGxldGlvbi1zdWJzdHJpbmctLWFsbC1jb21wbGV0aW9ucwogICAgICAgICAgICAgICAgIHN0
cmluZyB0YWJsZSBwcmVkIHBvaW50KSkpCiAgICAgKGlmIG1pbmlidWZmZXItY29tcGxldGlu
Zy1maWxlLW5hbWUKQEAgLTQxNjgsMTIgKzQzNTMsMTIgQEAgY29tcGxldGlvbi1zdWJzdHJp
bmctdHJ5LWNvbXBsZXRpb24KICAgICAoY29tcGxldGlvbi1wY20tLW1lcmdlLXRyeSBwYXR0
ZXJuIGFsbCBwcmVmaXggc3VmZml4KSkpCiAKIChkZWZ1biBjb21wbGV0aW9uLXN1YnN0cmlu
Zy1hbGwtY29tcGxldGlvbnMgKHN0cmluZyB0YWJsZSBwcmVkIHBvaW50KQotICAocGNhc2Ut
bGV0ICgoYCgsYWxsICxwYXR0ZXJuICxwcmVmaXggLF9zdWZmaXggLF9jYXJib3VuZHMpCisg
IChwY2FzZS1sZXQgKChgKCxhbGwgLHBhdHRlcm4gLHByZWZpeCAsc3VmZml4KQogICAgICAg
ICAgICAgICAgKGNvbXBsZXRpb24tc3Vic3RyaW5nLS1hbGwtY29tcGxldGlvbnMKICAgICAg
ICAgICAgICAgICBzdHJpbmcgdGFibGUgcHJlZCBwb2ludCkpKQotICAgICh3aGVuIGFsbAot
ICAgICAgKG5jb25jIChjb21wbGV0aW9uLXBjbS0taGlsaXQtY29tbW9uYWxpdHkgcGF0dGVy
biBhbGwpCi0gICAgICAgICAgICAgKGxlbmd0aCBwcmVmaXgpKSkpKQorICAgIChjb21wbGV0
aW9uLXBjbS0tZGVmZXJyZWQtaGlsaXQgcGF0dGVybiBhbGwKKyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIChsZW5ndGggcHJlZml4KQorICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgKC0gKGxlbmd0aCBzdHJpbmcpIChsZW5ndGggc3VmZml4KSkp
KSkKIAogOzs7ICJmbGV4IiBjb21wbGV0aW9uLCBhbHNvIGtub3duIGFzIGZseC9mdXp6eS9z
Y2F0dGVyIGNvbXBsZXRpb24KIDs7IENvbXBsZXRlcyAiZm9vIiB0byAiZnJvZG8iIGFuZCAi
ZmFyZnJvbXNvYmVyIgpAQCAtNDE4MywxOSArNDM2OCwxMSBAQCBjb21wbGV0aW9uLWZsZXgt
bm9zcGFjZQogICA6dmVyc2lvbiAiMjcuMSIKICAgOnR5cGUgJ2Jvb2xlYW4pCiAKLShwdXQg
J2ZsZXggJ2NvbXBsZXRpb24tLWFkanVzdC1tZXRhZGF0YSAnY29tcGxldGlvbi0tZmxleC1h
ZGp1c3QtbWV0YWRhdGEpCisocHV0ICdmbGV4ICdjb21wbGV0aW9uLS1zdHlsZS1tZXRhZGF0
YSAnY29tcGxldGlvbi0tZmxleC1zdHlsZS1tZXRhZGF0YSkKIAotKGRlZnVuIGNvbXBsZXRp
b24tLWZsZXgtYWRqdXN0LW1ldGFkYXRhIChtZXRhZGF0YSkKKyhkZWZ1biBjb21wbGV0aW9u
LS1mbGV4LXN0eWxlLW1ldGFkYXRhIChzdHJpbmcgdGFibGUgcHJlZCBwb2ludCBtZXRhZGF0
YSkKICAgIklmIGBmbGV4JyBpcyBhY3R1YWxseSBkb2luZyBmaWx0ZXJpbmcsIGFkanVzdCBz
b3J0aW5nLiIKLSAgKGxldCAoKGZsZXgtaXMtZmlsdGVyaW5nLXAKLSAgICAgICAgIDs7IEpU
QDIwMTktMTItMjM6IEZJWE1FOiB0aGlzIGlzIGtpbmRhIHdyb25nLiAgV2hhdCB3ZSBuZWVk
Ci0gICAgICAgICA7OyB0byB0ZXN0IGhlcmUgaXMgInNvbWUgaW5wdXQgdGhhdCBhY3R1YWxs
eSBsZWFkcy9sZWQgdG8KLSAgICAgICAgIDs7IGZsZXggZmlsdGVyaW5nIiwgbm90ICJzb21l
dGhpbmcgYWZ0ZXIgdGhlIG1pbmlidWZmZXIKLSAgICAgICAgIDs7IHByb21wdCIuICBFLmcu
IFRoZSBsYXR0ZXIgaXMgYWx3YXlzIHRydWUgZm9yIGZpbGUKLSAgICAgICAgIDs7IHNlYXJj
aGVzLCBtZWFuaW5nIHdlJ2xsIGJlIGRvaW5nIGV4dHJhIHdvcmsgd2hlbiB3ZQotICAgICAg
ICAgOzsgbmVlZG4ndC4KLSAgICAgICAgIChvciAobm90ICh3aW5kb3ctbWluaWJ1ZmZlci1w
KSkKLSAgICAgICAgICAgICAoPiAocG9pbnQtbWF4KSAobWluaWJ1ZmZlci1wcm9tcHQtZW5k
KSkpKQorICAobGV0ICgoZmxleC1pcy1maWx0ZXJpbmctcCAobm90IChlcXVhbCBzdHJpbmcg
IiIpKSkKICAgICAgICAgKGV4aXN0aW5nLWRzZgogICAgICAgICAgKGNvbXBsZXRpb24tbWV0
YWRhdGEtZ2V0IG1ldGFkYXRhICdkaXNwbGF5LXNvcnQtZnVuY3Rpb24pKQogICAgICAgICAo
ZXhpc3RpbmctY3NmCkBAIC00MjA0LDEyICs0MzgxLDMyIEBAIGNvbXBsZXRpb24tLWZsZXgt
YWRqdXN0LW1ldGFkYXRhCiAgICAgICAgICgoY29tcG9zZS1mbGV4LXNvcnQtZm4KICAgICAg
ICAgICAoZXhpc3Rpbmctc29ydC1mbikgOyB3aXNoIGBjbC1mbGV0JyBoYWQgcHJvcGVyIGlu
ZGVudGF0aW9uLi4uCiAgICAgICAgICAgKGxhbWJkYSAoY29tcGxldGlvbnMpCi0gICAgICAg
ICAgICAoc29ydAotICAgICAgICAgICAgIChmdW5jYWxsIGV4aXN0aW5nLXNvcnQtZm4gY29t
cGxldGlvbnMpCi0gICAgICAgICAgICAgKGxhbWJkYSAoYzEgYzIpCi0gICAgICAgICAgICAg
ICAobGV0ICgoczEgKGdldC10ZXh0LXByb3BlcnR5IDAgJ2NvbXBsZXRpb24tc2NvcmUgYzEp
KQotICAgICAgICAgICAgICAgICAgICAgKHMyIChnZXQtdGV4dC1wcm9wZXJ0eSAwICdjb21w
bGV0aW9uLXNjb3JlIGMyKSkpCi0gICAgICAgICAgICAgICAgICg+IChvciBzMSAwKSAob3Ig
czIgMCkpKSkpKSkpCisgICAgICAgICAgICAobGV0ICgocHJlLXNvcnRlZCAoZnVuY2FsbCBl
eGlzdGluZy1zb3J0LWZuIGNvbXBsZXRpb25zKSkKKyAgICAgICAgICAgICAgICAgIChwYXR0
ZXJuIChjYXIgKGNvbXBsZXRpb24tLXBhdHRlcm4tY29tcGlsZXIKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHN0cmluZyB0YWJsZSBwcmVkIHBvaW50CisgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAjJ2NvbXBsZXRpb24tZmxleC0tbWFrZS1mbGV4LXBh
dHRlcm4pKSkpCisgICAgICAgICAgICAgIDs7IElmIGBjb21wbGV0aW9uLXNjb3JlcycgYXJl
IGFscmVhZHkgcHJlc2VudCB1c2UKKyAgICAgICAgICAgICAgOzsgdGhvc2UgaW5zdGVhZCBv
ZiByZWNvbXB1dGluZyB0aGUgc2NvcmVzIHdpdGgKKyAgICAgICAgICAgICAgOzsgYGNvbXBs
ZXRpb24tLWZsZXgtc2NvcmUnLiAgVGhlIHNjb3JlcyBhcmUgYWxyZWFkeQorICAgICAgICAg
ICAgICA7OyBwcmVzZW50LCB3aGVuIHRoZSBjYW5kaWRhdGVzIGhhdmUgYmVlbiBjb21wdXRl
ZCBieQorICAgICAgICAgICAgICA7OyBgY29tcGxldGlvbi1hbGwtY29tcGxldGlvbnMnLiAg
SW4gY29udHJhc3QsIHRoZQorICAgICAgICAgICAgICA7OyBzY29yZSBpcyBub3QgeWV0IHBy
ZXNlbnQsIHdoZW4gdGhlIGNhbmRpZGF0ZXMgaGF2ZQorICAgICAgICAgICAgICA7OyBiZWVu
IGNvbXB1dGVkIGJ5IGBjb21wbGV0aW9uLWZpbHRlci1jb21wbGV0aW9ucycuCisgICAgICAg
ICAgICAgIChpZiAoYW5kIChjYXIgcHJlLXNvcnRlZCkKKyAgICAgICAgICAgICAgICAgICAg
ICAgKGdldC10ZXh0LXByb3BlcnR5IDAgJ2NvbXBsZXRpb24tc2NvcmUgKGNhciBwcmUtc29y
dGVkKSkpCisgICAgICAgICAgICAgICAgICAoc29ydAorICAgICAgICAgICAgICAgICAgIHBy
ZS1zb3J0ZWQKKyAgICAgICAgICAgICAgICAgICAobGFtYmRhIChjMSBjMikKKyAgICAgICAg
ICAgICAgICAgICAgICg+IChvciAoZ2V0LXRleHQtcHJvcGVydHkgMCAnY29tcGxldGlvbi1z
Y29yZSBjMSkgMCkKKyAgICAgICAgICAgICAgICAgICAgICAgIChvciAoZ2V0LXRleHQtcHJv
cGVydHkgMCAnY29tcGxldGlvbi1zY29yZSBjMikgMCkpKSkKKyAgICAgICAgICAgICAgICAo
bGV0KiAoKHNvcnRlZCAoc29ydCAoY29tcGxldGlvbi0tZmxleC1zY29yZSBwYXR0ZXJuIHBy
ZS1zb3J0ZWQpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIydjYXIt
bGVzcy10aGFuLWNhcikpCisgICAgICAgICAgICAgICAgICAgICAgIChjZWxsIHNvcnRlZCkp
CisgICAgICAgICAgICAgICAgICA7OyBSZW1vdmUgc2NvcmUgZGVjb3JhdGlvbnMsIHJldXNl
IHRoZSBsaXN0IHRvIGF2b2lkIGFsbG9jYXRpb25zLgorICAgICAgICAgICAgICAgICAgKHdo
aWxlIGNlbGwKKyAgICAgICAgICAgICAgICAgICAgKHNldGNhciBjZWxsIChjZGFyIGNlbGwp
KQorICAgICAgICAgICAgICAgICAgICAocG9wIGNlbGwpKQorICAgICAgICAgICAgICAgICAg
c29ydGVkKSkpKSkpCiAgICAgICBgKG1ldGFkYXRhCiAgICAgICAgICxAKGFuZCBmbGV4LWlz
LWZpbHRlcmluZy1wCiAgICAgICAgICAgICAgICBgKChkaXNwbGF5LXNvcnQtZnVuY3Rpb24K
QEAgLTQyMzksNyArNDQzNiw3IEBAIGNvbXBsZXRpb24tZmxleC0tbWFrZS1mbGV4LXBhdHRl
cm4KIChkZWZ1biBjb21wbGV0aW9uLWZsZXgtdHJ5LWNvbXBsZXRpb24gKHN0cmluZyB0YWJs
ZSBwcmVkIHBvaW50KQogICAiVHJ5IHRvIGZsZXgtY29tcGxldGUgU1RSSU5HIGluIFRBQkxF
IGdpdmVuIFBSRUQgYW5kIFBPSU5ULiIKICAgKHVubGVzcyAoYW5kIGNvbXBsZXRpb24tZmxl
eC1ub3NwYWNlIChzdHJpbmctc2VhcmNoICIgIiBzdHJpbmcpKQotICAgIChwY2FzZS1sZXQg
KChgKCxhbGwgLHBhdHRlcm4gLHByZWZpeCAsc3VmZml4ICxfY2FyYm91bmRzKQorICAgIChw
Y2FzZS1sZXQgKChgKCxhbGwgLHBhdHRlcm4gLHByZWZpeCAsc3VmZml4KQogICAgICAgICAg
ICAgICAgICAoY29tcGxldGlvbi1zdWJzdHJpbmctLWFsbC1jb21wbGV0aW9ucwogICAgICAg
ICAgICAgICAgICAgc3RyaW5nIHRhYmxlIHByZWQgcG9pbnQKICAgICAgICAgICAgICAgICAg
ICMnY29tcGxldGlvbi1mbGV4LS1tYWtlLWZsZXgtcGF0dGVybikpKQpAQCAtNDI1NiwxMyAr
NDQ1MywxMyBAQCBjb21wbGV0aW9uLWZsZXgtdHJ5LWNvbXBsZXRpb24KIChkZWZ1biBjb21w
bGV0aW9uLWZsZXgtYWxsLWNvbXBsZXRpb25zIChzdHJpbmcgdGFibGUgcHJlZCBwb2ludCkK
ICAgIkdldCBmbGV4LWNvbXBsZXRpb25zIG9mIFNUUklORyBpbiBUQUJMRSwgZ2l2ZW4gUFJF
RCBhbmQgUE9JTlQuIgogICAodW5sZXNzIChhbmQgY29tcGxldGlvbi1mbGV4LW5vc3BhY2Ug
KHN0cmluZy1zZWFyY2ggIiAiIHN0cmluZykpCi0gICAgKHBjYXNlLWxldCAoKGAoLGFsbCAs
cGF0dGVybiAscHJlZml4ICxfc3VmZml4ICxfY2FyYm91bmRzKQorICAgIChwY2FzZS1sZXQg
KChgKCxhbGwgLHBhdHRlcm4gLHByZWZpeCAsc3VmZml4KQogICAgICAgICAgICAgICAgICAo
Y29tcGxldGlvbi1zdWJzdHJpbmctLWFsbC1jb21wbGV0aW9ucwogICAgICAgICAgICAgICAg
ICAgc3RyaW5nIHRhYmxlIHByZWQgcG9pbnQKICAgICAgICAgICAgICAgICAgICMnY29tcGxl
dGlvbi1mbGV4LS1tYWtlLWZsZXgtcGF0dGVybikpKQotICAgICAgKHdoZW4gYWxsCi0gICAg
ICAgIChuY29uYyAoY29tcGxldGlvbi1wY20tLWhpbGl0LWNvbW1vbmFsaXR5IHBhdHRlcm4g
YWxsKQotICAgICAgICAgICAgICAgKGxlbmd0aCBwcmVmaXgpKSkpKSkKKyAgICAgIChjb21w
bGV0aW9uLXBjbS0tZGVmZXJyZWQtaGlsaXQgcGF0dGVybiBhbGwKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIChsZW5ndGggcHJlZml4KQorICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgKC0gKGxlbmd0aCBzdHJpbmcpIChsZW5ndGggc3VmZml4
KSkpKSkpCiAKIDs7IEluaXRpYWxzIGNvbXBsZXRpb24KIDs7IENvbXBsZXRlIC91bXMgdG8g
L3Vzci9tb25uaWVyL3NyYyBvciBsY2ggdG8gbGlzdC1jb21tYW5kLWhpc3RvcnkuCkBAIC00
Mjk5LDcgKzQ0OTYsMTEgQEAgY29tcGxldGlvbi1pbml0aWFscy1leHBhbmQKIChkZWZ1biBj
b21wbGV0aW9uLWluaXRpYWxzLWFsbC1jb21wbGV0aW9ucyAoc3RyaW5nIHRhYmxlIHByZWQg
X3BvaW50KQogICAobGV0ICgobmV3c3RyIChjb21wbGV0aW9uLWluaXRpYWxzLWV4cGFuZCBz
dHJpbmcgdGFibGUgcHJlZCkpKQogICAgICh3aGVuIG5ld3N0cgotICAgICAgKGNvbXBsZXRp
b24tcGNtLWFsbC1jb21wbGV0aW9ucyBuZXdzdHIgdGFibGUgcHJlZCAobGVuZ3RoIG5ld3N0
cikpKSkpCisgICAgICAocGNhc2UtbGV0ICgoYCgscGF0dGVybiAsYWxsICxwcmVmaXggLF9z
dWZmaXgpCisgICAgICAgICAgICAgICAgICAgKGNvbXBsZXRpb24tcGNtLS1maW5kLWFsbC1j
b21wbGV0aW9ucyBuZXdzdHIgdGFibGUKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByZWQgKGxlbmd0aCBuZXdzdHIpKSkpCisg
ICAgICAgIChjb21wbGV0aW9uLXBjbS0tZGVmZXJyZWQtaGlsaXQgcGF0dGVybiBhbGwKKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAobGVuZ3RoIHByZWZpeCkg
KGxlbmd0aCBzdHJpbmcpKSkpKSkKIAogKGRlZnVuIGNvbXBsZXRpb24taW5pdGlhbHMtdHJ5
LWNvbXBsZXRpb24gKHN0cmluZyB0YWJsZSBwcmVkIF9wb2ludCkKICAgKGxldCAoKG5ld3N0
ciAoY29tcGxldGlvbi1pbml0aWFscy1leHBhbmQgc3RyaW5nIHRhYmxlIHByZWQpKSkKZGlm
ZiAtLWdpdCBhL3Rlc3QvbGlzcC9taW5pYnVmZmVyLXRlc3RzLmVsIGIvdGVzdC9saXNwL21p
bmlidWZmZXItdGVzdHMuZWwKaW5kZXggNGY5MmQ3Zjg0MWMuLjFhYjgwY2QxMzY0IDEwMDY0
NAotLS0gYS90ZXN0L2xpc3AvbWluaWJ1ZmZlci10ZXN0cy5lbAorKysgYi90ZXN0L2xpc3Av
bWluaWJ1ZmZlci10ZXN0cy5lbApAQCAtMjgsOCArMjgsNyBAQAogCiAocmVxdWlyZSAnZXJ0
KQogKHJlcXVpcmUgJ2VydC14KQotCi0oZXZhbC13aGVuLWNvbXBpbGUgKHJlcXVpcmUgJ2Ns
LWxpYikpCisocmVxdWlyZSAnY2wtbGliKQogCiAoZXJ0LWRlZnRlc3QgY29tcGxldGlvbi10
ZXN0MSAoKQogICAod2l0aC10ZW1wLWJ1ZmZlcgpAQCAtMzQ0LDYgKzM0MywyMjEgQEAgY29t
cGxldGlvbi1mbGV4LXRlc3QtMwogICAgICAgICAgICAgICAgICAgImN1c3Rncm91cCIgJygi
Y3VzdG9taXplLWdyb3VwLW90aGVyLXdpbmRvdyIpIG5pbCA5KSkpCiAgICAgICAgICAgIDE1
KSkpCiAKKyhlcnQtZGVmdGVzdCBjb21wbGV0aW9uLWZsZXgtc2NvcmUtdGVzdC0xICgpCisg
IDs7IEZ1bGwgbWF0Y2ghCisgIChzaG91bGQgKGVxdWFsCisgICAgICAgICAgIChjb21wbGV0
aW9uLS1mbGV4LXNjb3JlICcocHJlZml4ICJSIikgJygiUiIpKQorICAgICAgICAgICAobGlz
dCAoY29ucyAtMS4wICJSIikpKSkpCisKKyhlcnQtZGVmdGVzdCBjb21wbGV0aW9uLWZsZXgt
c2NvcmUtdGVzdC0yICgpCisgIDs7IE9uZSB0aGlyZCBhbmQgaGFsZiBvZiBhIG1hdGNoIQor
ICAoc2hvdWxkIChlcXVhbAorICAgICAgICAgICAoY29tcGxldGlvbi0tZmxleC1zY29yZSAn
KHByZWZpeCAiZm9vIikKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJygi
YmFyZm9vYmFyIiAiZm9vYm9vIikpCisgICAgICAgICAgIChsaXN0IChjb25zICgvIC0xLjAg
My4wKSAiYmFyZm9vYmFyIikKKyAgICAgICAgICAgICAgICAgKGNvbnMgKC8gLTEuMCAyLjAp
ICJmb29ib28iKSkpKSkKKworKGVydC1kZWZ0ZXN0IGNvbXBsZXRpb24tZmxleC1zY29yZS10
ZXN0LTMgKCkKKyAgOzsgT25lIGZvdXJ0aCBvZiBhIG1hdGNoCisgIChzaG91bGQgKGVxbAor
ICAgICAgICAgICAoY2FhciAoY29tcGxldGlvbi0tZmxleC1zY29yZSAnKHByZWZpeCAiUiIg
cG9pbnQgIk8iKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAn
KCJSYU9iIikpKQorICAgICAgICAgICAoLyAtMS4wIDQuMCkpKSkKKworKGVydC1kZWZ0ZXN0
IGNvbXBsZXRpb24tZmxleC1zY29yZS10ZXN0LTQgKCkKKyAgOzsgRm9yIHF1b3RlZCBjb21w
bGV0aW9uIHRhYmxlcywgc2NvcmUgdGhlIHVucXVvdGVkIGNvbXBsZXRpb24gc3RyaW5nLgor
ICAoc2hvdWxkIChlcXVhbAorICAgICAgICAgICAoY29tcGxldGlvbi0tZmxleC1zY29yZQor
ICAgICAgICAgICAgJyhwcmVmaXggIlIiKQorICAgICAgICAgICAgKGxpc3QgKHByb3BlcnRp
emUgIlgiICdjb21wbGV0aW9uLS11bnF1b3RlZCAiUiIpKSkKKyAgICAgICAgICAgKGxpc3Qg
KGNvbnMgLTEuMCAiWCIpKSkpKQorCisoZGVmdW4gY29tcGxldGlvbi0tdGVzdC1zdHlsZSAo
c3R5bGUgc3RyaW5nIHBvaW50IHRhYmxlIGZpbHRlcmVkKQorICAobGV0KiAoKGNvbXBsZXRp
b24tc3R5bGVzIChsaXN0IHN0eWxlKSkKKyAgICAgICAgIChwcmVkIChsYW1iZGEgKHgpIChu
b3QgKHN0cmluZy1zZWFyY2ggIiEiIHgpKSkpCisgICAgICAgICAocmVzdWx0IChjb21wbGV0
aW9uLWZpbHRlci1jb21wbGV0aW9ucworICAgICAgICAgICAgICAgICAgc3RyaW5nIHRhYmxl
IHByZWQgcG9pbnQgbmlsKSkpCisgICAgKHNob3VsZCAoZXF1YWwgKGFsaXN0LWdldCAnYmFz
ZSByZXN1bHQpIDApKQorICAgIChzaG91bGQgKGVxdWFsIChhbGlzdC1nZXQgJ2VuZCByZXN1
bHQpIChsZW5ndGggc3RyaW5nKSkpCisgICAgKHNob3VsZCAoZXF1YWwgKGFsaXN0LWdldCAn
Y29tcGxldGlvbnMgcmVzdWx0KSBmaWx0ZXJlZCkpCisgICAgOzsgVGhlIGhpZ2hsaWdodGlu
ZyBmdW5jdGlvbiBzaG91bGQgYmUgcHJlc2VudC4KKyAgICAoc2hvdWxkIChub3QgKG1lbXEg
KGFsaXN0LWdldCAnaGlnaGxpZ2h0IHJlc3VsdCkgJyhuaWwgaWRlbnRpdHkpKSkpCisgICAg
OzsgRXF1YWwgcmVzdWx0cyBhcyBgY29tcGxldGlvbi1hbGwtY29tcGxldGlvbnMnLgorICAg
IChzaG91bGQgKGVxdWFsIChjb21wbGV0aW9uLWFsbC1jb21wbGV0aW9ucyBzdHJpbmcgdGFi
bGUgcHJlZCBwb2ludCkKKyAgICAgICAgICAgICAgICAgICAoYXBwZW5kIGZpbHRlcmVkIDAp
KSkKKyAgICA7OyBUaGUgcmV0dXJuZWQgc3RyaW5ncyBzaG91bGQgYmUgaWRlbnRpY2FsIHRv
IHRoZSBvcmlnaW5hbCBzdHJpbmdzLgorICAgIDs7IFRoZSBgY29tcGxldGlvbi1maWx0ZXIt
Y29tcGxldGlvbnMnIGZ1bmN0aW9uIGF2b2lkcyBhbGxvY2F0aW9ucyEKKyAgICAoc2hvdWxk
IChjbC1pbnRlcnNlY3Rpb24gKGFsaXN0LWdldCAnY29tcGxldGlvbnMgcmVzdWx0KQorICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB0YWJsZSA6dGVzdCAjJ2VxKSkpKQorCisoZXJ0
LWRlZnRlc3QgY29tcGxldGlvbi1iYXNpYy1zdHlsZS10ZXN0LTEgKCkKKyAgOzsgcG9pbnQg
YXQgdGhlIGJlZ2lubmluZyB8Zm9vCisgIChjb21wbGV0aW9uLS10ZXN0LXN0eWxlICdiYXNp
YyAiZm9vIiAwCisgICAgICAgICAgICAgICAgICAgICAgICAgICcoImZvb2JhciIgImZvbyEi
ICJiYXJmb28iICJ4Zm9veSIgImJvb2JhciIpCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICcoImZvb2JhciIgImJhcmZvbyIgInhmb295IikpKQorCisoZXJ0LWRlZnRlc3QgY29tcGxl
dGlvbi1iYXNpYy1zdHlsZS10ZXN0LTIgKCkKKyAgOzsgcG9pbnQgZm9vCisgIChjb21wbGV0
aW9uLS10ZXN0LXN0eWxlICdiYXNpYyAiZm9vIiAyCisgICAgICAgICAgICAgICAgICAgICAg
ICAgICcoImZvb2JhciIgImZvbyEiICJmb2JhciIgImJhcmZvbyIgInhmb295IiAiYm9vYmFy
IikKKyAgICAgICAgICAgICAgICAgICAgICAgICAgJygiZm9vYmFyIikpKQorCisoZXJ0LWRl
ZnRlc3QgY29tcGxldGlvbi1zdWJzdHJpbmctc3R5bGUtdGVzdCAoKQorICAoY29tcGxldGlv
bi0tdGVzdC1zdHlsZSAnc3Vic3RyaW5nICJmb28iIDEKKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgJygiZm9vYmFyIiAiZm9vISIgImJhcmZvbyIgInhmb295IiAiYm9vYmFyIikKKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgJygiZm9vYmFyIiAiYmFyZm9vIiAieGZvb3kiKSkp
CisKKyhlcnQtZGVmdGVzdCBjb21wbGV0aW9uLWVtYWNzMjEtc3R5bGUtdGVzdCAoKQorICAo
Y29tcGxldGlvbi0tdGVzdC1zdHlsZSAnZW1hY3MyMSAiZm9vIiAxCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICcoImZvb2JhciIgImZvbyEiICJmb2JhciIgImJhcmZvbyIgInhmb295
IiAiYm9vYmFyIikKKyAgICAgICAgICAgICAgICAgICAgICAgICAgJygiZm9vYmFyIikpKQor
CisoZXJ0LWRlZnRlc3QgY29tcGxldGlvbi1lbWFjczIyLXN0eWxlLXRlc3QgKCkKKyAgKGNv
bXBsZXRpb24tLXRlc3Qtc3R5bGUgJ2VtYWNzMjIgImZvMCIgMQorICAgICAgICAgICAgICAg
ICAgICAgICAgICAnKCJmb29iYXIiICJmb28hIiAiZm9iYXIiICJiYXJmb28iICJ4Zm9veSIg
ImJvb2JhciIpCisgICAgICAgICAgICAgICAgICAgICAgICAgICcoImZvb2JhciIgImZvYmFy
IikpKSA7OyBzdWZmaXggaWdub3JlZCBjb21wbGV0ZWx5CisKKyhlcnQtZGVmdGVzdCBjb21w
bGV0aW9uLWZsZXgtc3R5bGUtdGVzdCAoKQorICAoY29tcGxldGlvbi0tdGVzdC1zdHlsZSAn
ZmxleCAiYWJjIiAxCisgICAgICAgICAgICAgICAgICAgICAgICAgICcoImFiYyIgImFiYyEi
ICJ4YXliemMiICJ4YXlieiIpCisgICAgICAgICAgICAgICAgICAgICAgICAgICcoImFiYyIg
InhheWJ6YyIpKSkKKworKGVydC1kZWZ0ZXN0IGNvbXBsZXRpb24taW5pdGlhbHMtc3R5bGUt
dGVzdCAoKQorICAoY29tcGxldGlvbi0tdGVzdC1zdHlsZSAnaW5pdGlhbHMgImFiYyIgMQor
ICAgICAgICAgICAgICAgICAgICAgICAgICAnKCJhLWItYyIgImEtYi1jISIgImF4LWJ5LWN6
IiAieGF4LWJ5LWN6IikKKyAgICAgICAgICAgICAgICAgICAgICAgICAgJygiYS1iLWMiICJh
eC1ieS1jeiIpKSkKKworKGVydC1kZWZ0ZXN0IGNvbXBsZXRpb24tcGNtLXN0eWxlLXRlc3Qg
KCkKKyAgKGNvbXBsZXRpb24tLXRlc3Qtc3R5bGUgJ3BhcnRpYWwtY29tcGxldGlvbiAiYXgt
Yi1jIiAxCisgICAgICAgICAgICAgICAgICAgICAgICAgICcoImF4LWItYyIgImF4LWItYyEi
ICJheC1ieS1jeiIgInhheC1ieS1jeiIpCisgICAgICAgICAgICAgICAgICAgICAgICAgICco
ImF4LWItYyIgImF4LWJ5LWN6IikpKQorCisoZXJ0LWRlZnRlc3QgY29tcGxldGlvbi1maWx0
ZXItY29tcGxldGlvbnMtaGlnaGxpZ2h0LXRlc3QgKCkKKyAgOzsgcG9pbnQgYXQgdGhlIGJl
Z2lubmluZyB8Zm9vCisgIChsZXQqICgoY29tcGxldGlvbi1zdHlsZXMgJyhiYXNpYykpCisg
ICAgICAgICAocmVzdWx0IChjb21wbGV0aW9uLWZpbHRlci1jb21wbGV0aW9ucworICAgICAg
ICAgICAgICAgICAgImZvbyIgJygiZm9vYmFyIiAiZmJhcmZvbyIgImZ4Zm9veSIgImJhciIp
CisgICAgICAgICAgICAgICAgICBuaWwgMSBuaWwpKSkKKyAgICAoc2hvdWxkIChlcXVhbAor
ICAgICAgICAgICAgIChmb3JtYXQgIiVTIiAoYWxpc3QtZ2V0ICdjb21wbGV0aW9ucyByZXN1
bHQpKQorICAgICAgICAgICAgIChmb3JtYXQgIiVTIiAnKCJmb29iYXIiICJmYmFyZm9vIiAi
Znhmb295IikpKSkKKyAgICAoc2hvdWxkIChlcXVhbAorICAgICAgICAgICAgIChmb3JtYXQg
IiVTIiAoZnVuY2FsbCAoYWxpc3QtZ2V0ICdoaWdobGlnaHQgcmVzdWx0KQorICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAoYWxpc3QtZ2V0ICdjb21wbGV0aW9ucyByZXN1
bHQpKSkKKyAgICAgICAgICAgICAoZm9ybWF0ICIlUyIKKyAgICAgICAgICAgICAgICAgICAg
ICcoIygiZm9vYmFyIiAwIDEgKGZhY2UgKGNvbXBsZXRpb25zLWNvbW1vbi1wYXJ0KSkKKyAg
ICAgICAgICAgICAgICAgICAgICAgICAxIDIgKGZhY2UgKGNvbXBsZXRpb25zLWZpcnN0LWRp
ZmZlcmVuY2UpKSkKKyAgICAgICAgICAgICAgICAgICAgICAgIygiZmJhcmZvbyIgMCAxIChm
YWNlIChjb21wbGV0aW9ucy1jb21tb24tcGFydCkpCisgICAgICAgICAgICAgICAgICAgICAg
ICAgMSAyIChmYWNlIChjb21wbGV0aW9ucy1maXJzdC1kaWZmZXJlbmNlKSkpCisgICAgICAg
ICAgICAgICAgICAgICAgICMoImZ4Zm9veSIgMCAxIChmYWNlIChjb21wbGV0aW9ucy1jb21t
b24tcGFydCkpCisgICAgICAgICAgICAgICAgICAgICAgICAgMSAyIChmYWNlIChjb21wbGV0
aW9ucy1maXJzdC1kaWZmZXJlbmNlKSkpKSkpKSkpCisKKyhkZWZ1biBjb21wbGV0aW9uLS10
ZXN0LWJvdW5kYXJpZXMgKHN0eWxlIHN0cmluZyB0YWJsZSByZXN1bHQpCisgIChsZXQgKCh0
YWJsZQorICAgICAgICAgKGxhbWJkYSAoc3RyIHByZWQgYWN0aW9uKQorICAgICAgICAgICAo
cGNhc2UgYWN0aW9uCisgICAgICAgICAgICAgKGAoYm91bmRhcmllcyAuICxzdWZmaXgpIGAo
Ym91bmRhcmllcworICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICwo
MSsgKHN0cmluZy1tYXRjaC1wICI8XFx8LyIgc3RyKSkKKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAuICwob3IgKHN0cmluZy1zZWFyY2ggIj4iIHN1ZmZpeCkg
KGxlbmd0aCBzdWZmaXgpKSkpCisgICAgICAgICAgICAgKF8gKGNvbXBsZXRlLXdpdGgtYWN0
aW9uIGFjdGlvbiB0YWJsZQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAocmVwbGFjZS1yZWdleHAtaW4tc3RyaW5nICIuKls8L10iICIiIHN0cikKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcHJlZCkpKSkpCisgICAgICAgIChwb2lu
dCAoc3RyaW5nLXNlYXJjaCAifCIgc3RyaW5nKSkKKyAgICAgICAgKHN0cmluZyAoc3RyaW5n
LXJlcGxhY2UgInwiICIiIHN0cmluZykpCisgICAgICAgIChjb21wbGV0aW9uLXN0eWxlcyAo
bGlzdCBzdHlsZSkpKQorICAgIChzaG91bGQgKGVxdWFsCisgICAgICAgICAgICAgKGFzc3Et
ZGVsZXRlLWFsbAorICAgICAgICAgICAgICAoaWYgKGFzc3EgJ2hpZ2hsaWdodCByZXN1bHQp
ICctZG9lcy1ub3QtZXhpc3QgJ2hpZ2hsaWdodCkKKyAgICAgICAgICAgICAgKGNvbXBsZXRp
b24tZmlsdGVyLWNvbXBsZXRpb25zCisgICAgICAgICAgICAgICBzdHJpbmcgdGFibGUgbmls
IHBvaW50IG5pbCkpCisgICAgICAgICAgICAgcmVzdWx0KSkKKyAgICAoc2hvdWxkIChlcXVh
bAorICAgICAgICAgICAgIChjb21wbGV0aW9uLWFsbC1jb21wbGV0aW9ucworICAgICAgICAg
ICAgICBzdHJpbmcgdGFibGUgbmlsIHBvaW50KQorICAgICAgICAgICAgIChhcHBlbmQgKGFs
aXN0LWdldCAnY29tcGxldGlvbnMgcmVzdWx0KQorICAgICAgICAgICAgICAgICAgICAgKGFs
aXN0LWdldCAnYmFzZSByZXN1bHQpKSkpKSkKKworKGVydC1kZWZ0ZXN0IGNvbXBsZXRpb24t
ZW1hY3MyMS1ib3VuZGFyaWVzLXRlc3QgKCkKKyAgKGNvbXBsZXRpb24tLXRlc3QtYm91bmRh
cmllcyAnZW1hY3MyMSAiYmVmb3JlPGlufHB1dD5hZnRlciIKKyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAnKCJvdGhlciIpIG5pbCkKKyAgKGNvbXBsZXRpb24tLXRlc3QtYm91
bmRhcmllcyAnZW1hY3MyMSAiYmVmb3JlPGlufHB1dD5hZnRlciIKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAnKCJhaW5wdXQ+YWZ0ZXIiICJpbnB1dD5hZnRlciIgImlucHV4
PmFmdGVyIgorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgImlueHB1dHk+YWZ0
ZXIiICJpbnB1dD5hZnRlcjIiKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICco
KGJhc2UgLiA3KQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGVuZCAuIDE4
KQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGNvbXBsZXRpb25zICJpbnB1
dD5hZnRlciIgImlucHV0PmFmdGVyMiIpKSkpCisKKyhlcnQtZGVmdGVzdCBjb21wbGV0aW9u
LWVtYWNzMjItYm91bmRhcmllcy10ZXN0ICgpCisgIChjb21wbGV0aW9uLS10ZXN0LWJvdW5k
YXJpZXMgJ2VtYWNzMjIgImJlZm9yZTxpbnxwdXQ+YWZ0ZXIiCisgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgJygib3RoZXIiKSBuaWwpCisgIChjb21wbGV0aW9uLS10ZXN0LWJv
dW5kYXJpZXMgJ2VtYWNzMjIgImJlZm9yZTxpbnxwdXQ+YWZ0ZXIiCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgJygiYWlueHh4IiAiaW55eSIgImluenp6IikKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAnKChiYXNlIC4gNykKKyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIChlbmQgLiAxMikKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIChjb21wbGV0aW9ucyAiaW55eSIgImluenp6IikpKSkKKworKGVydC1kZWZ0ZXN0
IGNvbXBsZXRpb24tYmFzaWMtYm91bmRhcmllcy10ZXN0ICgpCisgIChjb21wbGV0aW9uLS10
ZXN0LWJvdW5kYXJpZXMgJ2Jhc2ljICJiZWZvcmU8aW58cHV0PmFmdGVyIgorICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICcoIm90aGVyIikgbmlsKQorICAoY29tcGxldGlvbi0t
dGVzdC1ib3VuZGFyaWVzICdiYXNpYyAiYmVmb3JlPGlufHB1dD5hZnRlciIKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAnKCJhaW5wdXQiICJpbnB1dCIgImlucHV4IiAiaW54
cHV0eSIpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJygoYmFzZSAuIDcpCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoZW5kIC4gMTIpCisgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAoY29tcGxldGlvbnMgImlucHV0IiAiaW54cHV0eSIp
KSkpCisKKyhlcnQtZGVmdGVzdCBjb21wbGV0aW9uLXN1YnN0cmluZy1ib3VuZGFyaWVzLXRl
c3QgKCkKKyAgKGNvbXBsZXRpb24tLXRlc3QtYm91bmRhcmllcyAnc3Vic3RyaW5nICJiZWZv
cmU8aW58cHV0cz5hZnRlciIKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAnKCJv
dGhlciIpIG5pbCkKKyAgKGNvbXBsZXRpb24tLXRlc3QtYm91bmRhcmllcyAnc3Vic3RyaW5n
ICJiZWZvcmU8aW58cHV0cz5hZnRlciIKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAnKCJhaW5wdXRzIiAiaW5wdXRzIiAiaW5wdXgiICJpbnhwdXRzeSIpCisgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgJygoYmFzZSAuIDcpCisgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAoZW5kIC4gMTMpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAoY29tcGxldGlvbnMgImFpbnB1dHMiICJpbnB1dHMiICJpbnhwdXRzeSIpKSkpCisK
KyhlcnQtZGVmdGVzdCBjb21wbGV0aW9uLXBjbS1ib3VuZGFyaWVzLXRlc3QgKCkKKyAgKGNv
bXBsZXRpb24tLXRlc3QtYm91bmRhcmllcyAncGFydGlhbC1jb21wbGV0aW9uICJiZWZvcmU8
aW4tcHx0PmFmdGVyIgorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICcoIm90aGVy
IikgbmlsKQorICAoY29tcGxldGlvbi0tdGVzdC1ib3VuZGFyaWVzICdwYXJ0aWFsLWNvbXBs
ZXRpb24gImJlZm9yZTxpbi1wfHQ+YWZ0ZXIiCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgJygiYWluLXB1LXRzIiAiaW4tcHRzIiAiaW4tcHUtdHMiICJpbi1weCIgImlueC1w
dHN5IikKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAnKChiYXNlIC4gNykKKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChlbmQgLiAxMikKKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIChjb21wbGV0aW9ucyAiaW4tcHRzIiAiaW4tcHUtdHMi
ICJpbngtcHRzeSIpKSkpCisKKyhlcnQtZGVmdGVzdCBjb21wbGV0aW9uLWluaXRpYWxzLWJv
dW5kYXJpZXMtdGVzdCAoKQorICAoY29tcGxldGlvbi0tdGVzdC1ib3VuZGFyaWVzICdpbml0
aWFscyAiL2lwfHQiCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJygib3RoZXIi
KSBuaWwpCisgIChjb21wbGV0aW9uLS10ZXN0LWJvdW5kYXJpZXMgJ2luaXRpYWxzICIvaXB8
dCIKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAnKCJhaW4vcHUvdHMiICJpbi9w
dHMiICJpbi9wdS90cyIgImEvaW4vcHUvdHMiCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAiaW4vcHUvdHMvZm9vIiAiaW4vcHgiICJpbngvcHRzeSIpCisgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgJygoYmFzZSAuIDEpCisgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAoZW5kIC4gNCkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIChjb21wbGV0aW9ucyAiaW4vcHUvdHMiICJpbi9wdS90cy9mb28iKSkpKQorCisoZGVm
dW4gY29tcGxldGlvbi1lbWFjczIyb3JpZy1hbGwtY29tcGxldGlvbnMgKHN0cmluZyB0YWJs
ZSBwcmVkIHBvaW50KQorICAobGV0ICgoYmVmb3JlcG9pbnQgKHN1YnN0cmluZyBzdHJpbmcg
MCBwb2ludCkpKQorICAgIChjb21wbGV0aW9uLWhpbGl0LWNvbW1vbmFsaXR5CisgICAgICAo
YWxsLWNvbXBsZXRpb25zIGJlZm9yZXBvaW50IHRhYmxlIHByZWQpCisgICAgIHBvaW50Cisg
ICAgIChjYXIgKGNvbXBsZXRpb24tYm91bmRhcmllcyBiZWZvcmVwb2ludCB0YWJsZSBwcmVk
ICIiKSkpKSkKKworKGVydC1kZWZ0ZXN0IGNvbXBsZXRpb24tdXBncmFkZS1yZXR1cm4tdHlw
ZS10ZXN0ICgpCisgIDs7IFRlc3QgdHJhbnNwYXJlbnQgdXBncmFkZSBvZiBsaXN0IGNvbXBs
ZXRpb24gc3R5bGUgcmV0dXJuIHZhbHVlCisgIDs7IHRvIHRoZSBhbGlzdCByZXR1cm4gdmFs
dWUgZm9ybWF0IG9mIGBjb21wbGV0aW9uLWZvcm1hdC1jb21wbGV0aW9ucycuCisgIChsZXQg
KChjb21wbGV0aW9uLXN0eWxlcy1hbGlzdAorICAgICAgICAgJygoZW1hY3MyMm9yaWcgY29t
cGxldGlvbi1lbWFjczIyLXRyeS1jb21wbGV0aW9uCisgICAgICAgICAgICAgICAgICAgICAg
ICBjb21wbGV0aW9uLWVtYWNzMjJvcmlnLWFsbC1jb21wbGV0aW9ucyBuaWwpKSkpCisgIChj
b21wbGV0aW9uLS10ZXN0LWJvdW5kYXJpZXMgJ2VtYWNzMjJvcmlnICJiZWZvcmU8aW58cHV0
PmFmdGVyIgorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICcoImFpbnh4eCIgImlu
eXkiICJpbnp6eiIpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJygoYmFzZSAu
IDcpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA7OyAxOCBpcyBpbmNvcnJl
Y3QsIHNob3VsZCBiZSAxMiEKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDs7
IEJ1dCB0aGUgaW5mb3JtYXRpb24gaXMgbm90IGF2YWlsYWJsZQorICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgOzsgZHVlIHRvIHRoZSBjb21wbGV0aW9uLXN0eWxlIHVwZ3Jh
ZGUuCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoZW5kIC4gMTgpCisgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA7OyBJZGVudGl0eSBoaWdobGlnaHRpbmcg
ZnVuY3Rpb24uCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoaGlnaGxpZ2h0
IC4gaWRlbnRpdHkpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoY29tcGxl
dGlvbnMgImlueXkiICJpbnp6eiIpKSkpKQorCisKIAwKIChkZWZtYWNybyBjb21wbGV0aW5n
LXJlYWQtd2l0aC1taW5pYnVmZmVyLXNldHVwIChjb2xsZWN0aW9uICZyZXN0IGJvZHkpCiAg
IChkZWNsYXJlIChpbmRlbnQgMSkgKGRlYnVnIChjb2xsZWN0aW9uIGJvZHkpKSkK
--------------AUdgZRFE6FQlG2vfM1Gpkmdf
Content-Type: text/x-patch; charset=UTF-8; name="completion-lazy-hilit.patch"
Content-Disposition: attachment; filename="completion-lazy-hilit.patch"
Content-Transfer-Encoding: base64
ZGlmZiAtLWdpdCBhL2xpc3AvaWNvbXBsZXRlLmVsIGIvbGlzcC9pY29tcGxldGUuZWwKaW5k
ZXggZTZmZGQxZjE4MzYuLmE5YWMwYjNmMDQwIDEwMDY0NAotLS0gYS9saXNwL2ljb21wbGV0
ZS5lbAorKysgYi9saXNwL2ljb21wbGV0ZS5lbApAQCAtNTQ1LDYgKzU0NSw3IEBAIGljb21w
bGV0ZS1taW5pYnVmZmVyLXNldHVwCiAgICAgKHNldHEtbG9jYWwgaWNvbXBsZXRlLS1pbml0
aWFsLWlucHV0IChpY29tcGxldGUtLWZpZWxkLXN0cmluZykpCiAgICAgKHNldHEtbG9jYWwg
Y29tcGxldGlvbi1zaG93LWlubGluZS1oZWxwIG5pbCkKICAgICAoc2V0cSBpY29tcGxldGUt
LXNjcm9sbGVkLWNvbXBsZXRpb25zIG5pbCkKKyAgICAoc2V0cSBjb21wbGV0aW9uLWxhenkt
aGlsaXQgKGNsLWdlbnN5bSkpCiAgICAgKHVzZS1sb2NhbC1tYXAgKG1ha2UtY29tcG9zZWQt
a2V5bWFwIGljb21wbGV0ZS1taW5pYnVmZmVyLW1hcAogICAgIAkJCQkJIChjdXJyZW50LWxv
Y2FsLW1hcCkpKQogICAgIChhZGQtaG9vayAncG9zdC1jb21tYW5kLWhvb2sgIydpY29tcGxl
dGUtcG9zdC1jb21tYW5kLWhvb2sgbmlsIHQpCkBAIC03NTQsMTIgKzc1NSwxMyBAQCBpY29t
cGxldGUtZXhoaWJpdAogICAgICAgICAgICAgICAgICAgICAgICAgICAgKG92ZXJsYXktZW5k
IHJmbi1lc2hhZG93LW92ZXJsYXkpKSkKICAgICAgICAgICAobGV0KiAoKGZpZWxkLXN0cmlu
ZyAoaWNvbXBsZXRlLS1maWVsZC1zdHJpbmcpKQogICAgICAgICAgICAgICAgICAodGV4dCAo
d2hpbGUtbm8taW5wdXQKKyAgICAgICAgICAgICAgICAgICAgICAgICAoYmVuY2htYXJrLXBy
b2duCiAgICAgICAgICAgICAgICAgICAgICAgICAgKGljb21wbGV0ZS1jb21wbGV0aW9ucwog
ICAgICAgICAgICAgICAgICAgICAgICAgICBmaWVsZC1zdHJpbmcKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgKGljb21wbGV0ZS0tY29tcGxldGlvbi10YWJsZSkKICAgICAgICAgICAg
ICAgICAgICAgICAgICAgKGljb21wbGV0ZS0tY29tcGxldGlvbi1wcmVkaWNhdGUpCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgIChpZiAod2luZG93LW1pbmlidWZmZXItcCkKLSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIChlcSBtaW5pYnVmZmVyLS1yZXF1aXJlLW1hdGNo
IHQpKSkpKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGVxIG1pbmlidWZmZXIt
LXJlcXVpcmUtbWF0Y2ggdCkpKSkpKQogICAgICAgICAgICAgICAgICAoYnVmZmVyLXVuZG8t
bGlzdCB0KQogICAgICAgICAgICAgICAgICBkZWFjdGl2YXRlLW1hcmspCiAgICAgICAgICAg
ICA7OyBEbyBub3RoaW5nIGlmIHdoaWxlLW5vLWlucHV0IHdhcyBhYm9ydGVkLgpAQCAtOTAx
LDcgKzkwMyw3IEBAIGljb21wbGV0ZS0tcmVuZGVyLXZlcnRpY2FsCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICdpY29tcGxldGUtc2VsZWN0ZWQtbWF0Y2ggJ2FwcGVuZCBj
b21wKQogICAgICBjb2xsZWN0IChjb25jYXQgcHJlZml4CiAgICAgICAgICAgICAgICAgICAg
ICAobWFrZS1zdHJpbmcgKC0gbWF4LXByZWZpeC1sZW4gKGxlbmd0aCBwcmVmaXgpKSA/ICkK
LSAgICAgICAgICAgICAgICAgICAgIGNvbXAKKyAgICAgICAgICAgICAgICAgICAgIChjb21w
bGV0aW9uLWxhenktaGlsaXQgY29tcCkKICAgICAgICAgICAgICAgICAgICAgIChtYWtlLXN0
cmluZyAoLSBtYXgtY29tcC1sZW4gKGxlbmd0aCBjb21wKSkgPyApCiAgICAgICAgICAgICAg
ICAgICAgICBzdWZmaXgpCiAgICAgIGludG8gbGluZXMtYXV4CkBAIC0xMDY3LDcgKzEwNjks
OCBAQCBpY29tcGxldGUtY29tcGxldGlvbnMKICAgICAgICAgICAgICAgICAgIChpZiAoPCBw
cm9zcGVjdHMtbGVuIHByb3NwZWN0cy1tYXgpCiAgICAgICAgICAgICAgICAgICAgICAgKHB1
c2ggY29tcCBwcm9zcGVjdHMpCiAgICAgICAgICAgICAgICAgICAgIChzZXRxIGxpbWl0IHQp
KSkKLSAgICAgICAgICAgICAgICAoc2V0cSBwcm9zcGVjdHMgKG5yZXZlcnNlIHByb3NwZWN0
cykpCisgICAgICAgICAgICAgICAgKHNldHEgcHJvc3BlY3RzCisgICAgICAgICAgICAgICAg
ICAgICAgKG5yZXZlcnNlIChtYXBjYXIgIydjb21wbGV0aW9uLWxhenktaGlsaXQgcHJvc3Bl
Y3RzKSkpCiAgICAgICAgICAgICAgICAgOzsgRGVjb3JhdGUgZmlyc3Qgb2YgdGhlIHByb3Nw
ZWN0cy4KICAgICAgICAgICAgICAgICAod2hlbiBwcm9zcGVjdHMKICAgICAgICAgICAgICAg
ICAgIChsZXQgKChmaXJzdCAoY29weS1zZXF1ZW5jZSAocG9wIHByb3NwZWN0cykpKSkKZGlm
ZiAtLWdpdCBhL2xpc3AvbWluaWJ1ZmZlci5lbCBiL2xpc3AvbWluaWJ1ZmZlci5lbAppbmRl
eCAyMTIwZTMxNzc1ZS4uYzU2ZWY2NDQ5NGEgMTAwNjQ0Ci0tLSBhL2xpc3AvbWluaWJ1ZmZl
ci5lbAorKysgYi9saXNwL21pbmlidWZmZXIuZWwKQEAgLTM3NDksNiArMzc0OSw1NCBAQCBm
bGV4LXNjb3JlLW1hdGNoLXRpZ2h0bmVzcwogdGhhbiB0aGUgbGF0dGVyICh3aGljaCBoYXMg
dHdvIFwiaG9sZXNcIiBhbmQgdGhyZWUKIG9uZS1sZXR0ZXItbG9uZyBtYXRjaGVzKS4iKQog
CisoZGVmdmFyLWxvY2FsIGNvbXBsZXRpb24tbGF6eS1oaWxpdCBuaWwKKyAgIklmIG5vbi1u
aWwsIHJlcXVlc3QgY29tcGxldGlvbiBsYXp5IGhpbGlnaHRpbmcuCisKK0NvbXBsZXRpb24t
cHJlc2VudGluZyBmcm9udGVuZHMgbWF5IG9wdCB0byBiaW5kIHRoaXMgdmFyaWFibGUgdG8K
K2EgdW5pcXVlIG5vbi1uaWwgdmFsdWUgaW4gdGhlIGNvbnRleHQgb2YgY29tcGxldGlvbi1w
cm9kdWNpbmcKK2NhbGxzIChzdWNoIGFzIGBjb21wbGV0aW9uLWFsbC1zb3J0ZWQtY29tcGxl
dGlvbnMnKS4gIFRoaXMgaGludHMKK3RoZSBpbnRlcnZlbmluZyBjb21wbGV0aW9uIHN0eWxl
cyB0aGF0IHRoZXkgZG8gbm90IG5lZWQgdG8KK3Byb3BlcnRpemUgY29tcGxldGlvbiBzdHJp
bmdzIHdpdGggdGhlIGBmYWNlJyBwcm9wZXJ0eS4KKworV2hlbiBkb2luZyBzbywgaXQgaXMg
dGhlIGZyb250ZW5kIC0tIG5vdCB0aGUgc3R5bGUgLS0gd2hvIGJlY29tZXMKK3Jlc3BvbnNp
YmxlIGZvciBgZmFjZSctcHJvcGVydGl6aW5nIG9ubHkgdGhlIGNvbXBsZXRpb24gc3RyaW5n
cwordGhhdCBhcmUgbWVhbnQgdG8gYmUgZGlzcGxheWVkIHRvIHRoZSB1c2VyLiAgVGhpcyBj
YW4gYmUgZG9uZSBieQorY2FsbGluZyB0aGUgZnVuY3Rpb24gYGNvbXBsZXRpb24tbGF6eS1o
aWxpdCcgd2hpY2ggcmV0dXJucyBhCitgZmFjZSctcHJvcGVydGl6ZWQgc3RyaW5nLgorCitU
aGUgdmFsdWUgc3RvcmVkIGluIHRoaXMgdmFyaWFibGUgYnkgdGhlIGNvbXBsZXRpb24gZnJv
bnRlbmQKK3Nob3VsZCBiZSB1bmlxdWUgdG8gZWFjaCBjb21wbGV0aW9uIGF0dGVtcHQgb3Ig
c2Vzc2lvbiB0aGF0Cit1dGlsaXplcyB0aGUgc2FtZSBjb21wbGV0aW9uIHN0eWxlIGluIGBj
b21wbGV0aW9uLXN0eWxlcy1hbGlzdCcuCitGb3IgZnJvbnRlbmRzIHVzaW5nIHRoZSBtaW5p
YnVmZmVyIGFzIHRoZSBsb2N1cyBvZiBjb21wbGV0aW9uCitjYWxscyBhbmQgZGlzcGxheSwg
c2V0dGluZyBpdCB0byBhIGJ1ZmZlci1sb2NhbCB2YWx1ZSBnaXZlbiBieQorYGdlbnN5bScg
aXMgYXBwcm9wcmlhdGUuICBGb3IgZnJvbnRlbmRzIG9wZXJhdGluZyBlbnRpcmVseSBpbiBh
CitzaW5nbGUgY29tbWFuZCwgbGV0LWJpbmRpbmcgaXQgdG8gYGdlbnN5bScgaXMgYXBwcm9w
cmlhdGUuCisKK05vdGUgdGhhdCB0aGUgb3B0aW1pemF0aW9uIGVuYWJsZWQgYnkgdmFyaWFi
bGUgaXMgb25seSBhY3R1YWxseQorcGVyZm9ybWVkIHNvbWUgY29tcGxldGlvbnMgc3R5bGVz
LiAgVG8gb3RoZXJzLCBpdCBpcyBhIGhhcm1sZXNzCithbmQgdXNlbGVzcyBoaW50LiAgVG8g
YXV0aG9yIGEgY29tcGxldGlvbiBzdHlsZSB0aGF0IHRha2VzCithZHZhbnRhZ2Ugb2YgdGhp
cywgbG9vayBpbiB0aGUgc291cmNlIG9mCitgY29tcGxldGlvbi1wY20tLWhpbGl0LWNvbW1v
bmFsaXR5Jy4iKQorCisoZGVmdW4gY29tcGxldGlvbi1sYXp5LWhpbGl0IChzdHIpCisgICJS
ZXR1cm4gYSBjb3B5IG9mIGNvbXBsZXRpb24gU1RSIHRoYXQgaXMgYGZhY2UnLXByb3BlcnRp
emVkLgorU2VlIGRvY3VtZW50YXRpb24gZm9yIHZhcmlhYmxlIGBjb21wbGV0aW9uLWxhenkt
aGlsaXQnIGZvciBtb3JlCitkZXRhaWxzLiIKKyAgKGxldCogKChzdHIgKGNvcHktc2VxdWVu
Y2Ugc3RyKSkKKyAgICAgICAgIChkYXRhIChnZXQtdGV4dC1wcm9wZXJ0eSAwICdjb21wbGV0
aW9uLWxhenktaGlsaXQtZGF0YSBzdHIpKQorICAgICAgICAgKHJlIChhbmQKKyAgICAgICAg
ICAgICAgY29tcGxldGlvbi1sYXp5LWhpbGl0CisgICAgICAgICAgICAgIChlcSBjb21wbGV0
aW9uLWxhenktaGlsaXQgKGNhciBkYXRhKSkgKGNkciBkYXRhKSkpCisgICAgICAgICAobWQg
KGFuZCByZSAoc3RyaW5nLW1hdGNoIHJlIHN0cikgKGNkZHIgKG1hdGNoLWRhdGEgdCkpKSkK
KyAgICAgICAgIChtZSAoYW5kIG1kIChtYXRjaC1lbmQgMCkpKQorICAgICAgICAgKGZyb20g
MCkpCisgICAgKHdoaWxlIG1kCisgICAgICAoYWRkLWZhY2UtdGV4dC1wcm9wZXJ0eSBmcm9t
IChwb3AgbWQpICdjb21wbGV0aW9ucy1jb21tb24tcGFydCBuaWwgc3RyKQorICAgICAgKHNl
dHEgZnJvbSAocG9wIG1kKSkpCisgICAgKHVubGVzcyAob3IgKG5vdCBtZSkgKD0gZnJvbSBt
ZSkpCisgICAgICAoYWRkLWZhY2UtdGV4dC1wcm9wZXJ0eSBmcm9tIG1lICdjb21wbGV0aW9u
cy1jb21tb24tcGFydCBuaWwgc3RyKSkKKyAgICBzdHIpKQorCiAoZGVmdW4gY29tcGxldGlv
bi1wY20tLWhpbGl0LWNvbW1vbmFsaXR5IChwYXR0ZXJuIGNvbXBsZXRpb25zKQogICAiU2hv
dyB3aGVyZSBhbmQgaG93IHdlbGwgUEFUVEVSTiBtYXRjaGVzIENPTVBMRVRJT05TLgogUEFU
VEVSTiwgYSBsaXN0IG9mIHN5bWJvbHMgYW5kIHN0cmluZ3MgYXMgc2VlbgpAQCAtMzc2NSw4
ICszODEzLDkgQEAgY29tcGxldGlvbi1wY20tLWhpbGl0LWNvbW1vbmFsaXR5CiAgICAgICAg
ICAgIGxhc3QtbWQpCiAgICAgICAobWFwY2FyCiAgICAgICAgKGxhbWJkYSAoc3RyKQotCSA7
OyBEb24ndCBtb2RpZnkgdGhlIHN0cmluZyBpdHNlbGYuCi0gICAgICAgICAoc2V0cSBzdHIg
KGNvcHktc2VxdWVuY2Ugc3RyKSkKKyAgICAgICAgICh1bmxlc3MgY29tcGxldGlvbi1sYXp5
LWhpbGl0CisgICAgICAgICAgIDs7IERvbid0IG1vZGlmeSB0aGUgc3RyaW5nIGl0c2VsZi4K
KyAgICAgICAgICAgKHNldHEgc3RyIChjb3B5LXNlcXVlbmNlIHN0cikpKQogICAgICAgICAg
KHVubGVzcyAoc3RyaW5nLW1hdGNoIHJlIHN0cikKICAgICAgICAgICAgKGVycm9yICJJbnRl
cm5hbCBlcnJvcjogJXMgZG9lcyBub3QgbWF0Y2ggJXMiIHJlIHN0cikpCiAgICAgICAgICAo
bGV0KiAoKHBvcyAoaWYgcG9pbnQtaWR4IChtYXRjaC1iZWdpbm5pbmcgcG9pbnQtaWR4KSAo
bWF0Y2gtZW5kIDApKSkKQEAgLTM4MTUsOSArMzg2NCwxMCBAQCBjb21wbGV0aW9uLXBjbS0t
aGlsaXQtY29tbW9uYWxpdHkKICAgICAgICAgICAgICAgICAodXBkYXRlLXNjb3JlLWFuZC1m
YWNlCiAgICAgICAgICAgICAgICAgIChsYW1iZGEgKGEgYikKICAgICAgICAgICAgICAgICAg
ICAiVXBkYXRlIHNjb3JlIGFuZCBmYWNlIGdpdmVuIG1hdGNoIHJhbmdlIChBIEIpLiIKLSAg
ICAgICAgICAgICAgICAgICAoYWRkLWZhY2UtdGV4dC1wcm9wZXJ0eSBhIGIKLSAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAnY29tcGxldGlvbnMtY29tbW9u
LXBhcnQKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBuaWwg
c3RyKQorICAgICAgICAgICAgICAgICAgICh1bmxlc3MgY29tcGxldGlvbi1sYXp5LWhpbGl0
CisgICAgICAgICAgICAgICAgICAgICAoYWRkLWZhY2UtdGV4dC1wcm9wZXJ0eSBhIGIKKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICdjb21wbGV0aW9u
cy1jb21tb24tcGFydAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgbmlsIHN0cikpCiAgICAgICAgICAgICAgICAgICAgKHNldHEKICAgICAgICAgICAg
ICAgICAgICAgc2NvcmUtbnVtZXJhdG9yICAgKCsgc2NvcmUtbnVtZXJhdG9yICgtIGIgYSkp
KQogICAgICAgICAgICAgICAgICAgICh1bmxlc3MgKG9yICg9IGEgbGFzdC1iKQpAQCAtMzg0
MCw3ICszODkwLDEwIEBAIGNvbXBsZXRpb24tcGNtLS1oaWxpdC1jb21tb25hbGl0eQogICAg
ICAgICAgICA7OyBmb3IgdGhhdCBleHRyYSBiaXQgb2YgbWF0Y2ggKGJ1ZyM0MjE0OSkuCiAg
ICAgICAgICAgICh1bmxlc3MgKD0gZnJvbSBtYXRjaC1lbmQpCiAgICAgICAgICAgICAgKGZ1
bmNhbGwgdXBkYXRlLXNjb3JlLWFuZC1mYWNlIGZyb20gbWF0Y2gtZW5kKSkKLSAgICAgICAg
ICAgKGlmICg+IChsZW5ndGggc3RyKSBwb3MpCisgICAgICAgICAgIChwdXQtdGV4dC1wcm9w
ZXJ0eSAwIDEgJ2NvbXBsZXRpb24tbGF6eS1oaWxpdC1kYXRhCisgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAoY29ucyBjb21wbGV0aW9uLWxhenktaGlsaXQgcmUpIHN0cikKKyAg
ICAgICAgICAgKGlmIChhbmQgKD4gKGxlbmd0aCBzdHIpIHBvcykKKyAgICAgICAgICAgICAg
ICAgICAgKG5vdCBjb21wbGV0aW9uLWxhenktaGlsaXQpKQogICAgICAgICAgICAgICAgKGFk
ZC1mYWNlLXRleHQtcHJvcGVydHkKICAgICAgICAgICAgICAgICBwb3MgKDErIHBvcykKICAg
ICAgICAgICAgICAgICAnY29tcGxldGlvbnMtZmlyc3QtZGlmZmVyZW5jZQo=
--------------AUdgZRFE6FQlG2vfM1Gpkmdf--
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 17 Aug 2021 11:53:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 17 07:53:01 2021 Received: from localhost ([127.0.0.1]:51985 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFxeO-0002QK-DY for submit <at> debbugs.gnu.org; Tue, 17 Aug 2021 07:53:01 -0400 Received: from mail-pj1-f43.google.com ([209.85.216.43]:42695) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1mFxeH-0002Ps-2c; Tue, 17 Aug 2021 07:52:56 -0400 Received: by mail-pj1-f43.google.com with SMTP id mq2-20020a17090b3802b0290178911d298bso5935363pjb.1; Tue, 17 Aug 2021 04:52:52 -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=TEK86VaewgjdMLw/h7r4vTGKS6CguYWjFkZKWAtP/wU=; b=cvxqMtvPfvhOAL5+Gs+nqgraU2Mjxr9g+34iJwyehrv4JVySceLsUPHefX18Mo0qJD 5OdrZ+4zpuYZt07SOrJZTRF6UHpcQIcP+csxB+KLhJ0jnXwwoL4qpMB7hnUhQ6nE9+Kb mZhYytmod1wnep7WaousBq++37MjNAuSd9KMCA9UKVxDYJK3UR13JD67LfOUtW3scWZT A8mWCBFn6UAWDpMO4OmeSj3invgCu+1apMxBwG5qeKcX6EnH4DIQpEelTA46TRwBVo5y wxu+0MIP8FSr5dRX0hNWHmQdAHPA/KGOon4arWahUMYxy4BalOef4XKX003uWPg3JT1I oeoQ== 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=TEK86VaewgjdMLw/h7r4vTGKS6CguYWjFkZKWAtP/wU=; b=aV6L9YJAX9WI5ksenqXMm+6gosT57v1Ds7VPXqLo66uDKMJlsEz5SXYMDTYL9BYIm+ dEhr7fNRuCcT7BG/Mi5JLthwLqYPZM7fLSvBFDLWniy3jQd+Se/TcigvvsFfRKfOkPEF xIzUqKqPvlEzXGAlZmTDYx6TW7vMcUfihAMHgV7OneCFEdvP3v4wAvwJhLom3dQxz+q8 NbPdm2y4S+bRGA6i+Mj0wbQw/P2KVgK65Dy7s/KSxN7kTXCoCQCXxZJG+Ihn/2Np/U4X 4WF3i4R+M9CHZiZ++zRQlXMKAmYY6lS9YCNEJlSyX9cwhW6y9zlBy1NFHnPnWCDqfVx2 ixoA== X-Gm-Message-State: AOAM532wOnVUITeloOweJ3VOuOOfbTSm2w7Rzmo8I6qSXnWCtx1W7sWv FK3g79E4A+1/WNzhqOTpF/t2mk2PZCk+cNePfes= X-Google-Smtp-Source: ABdhPJylyc9Lo/7eud0V3p+zEOslveEBTHfAxiDHWf0kOUj0lZmVosUrDtmX/oZLqYeUT1fbHxfB3dF8CFjyRjQxIo8= X-Received: by 2002:a17:90a:a091:: with SMTP id r17mr3301716pjp.56.1629201167171; Tue, 17 Aug 2021 04:52:47 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN> <CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN> <eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN> <87a6lihv7b.fsf@HIDDEN> <63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN> <CALDnm50W_=Y_zP7KLznqcqSx8KJp2-0u2NwpuEGzzAUzCNHvKQ@HIDDEN> <c95dea17-ca29-4dee-d53d-b5d46f7f2cf8@HIDDEN> <83k0kl8sxm.fsf@HIDDEN> <f53a5330-fe7c-269c-ce34-9f2870e24e61@HIDDEN> <83bl5x8r02.fsf@HIDDEN> <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@HIDDEN> <8735r9ii8b.fsf@HIDDEN> <e9de5ee9-154b-0e52-f784-f10152ff9347@HIDDEN> <87tujpgscj.fsf@HIDDEN> <5118e88c-5b90-60f0-b5eb-ab4ce8bdc0dc@HIDDEN> <87zgtgxx8y.fsf@HIDDEN> <838s1070m0.fsf@HIDDEN> In-Reply-To: <838s1070m0.fsf@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Tue, 17 Aug 2021 12:52:35 +0100 Message-ID: <CALDnm50c1hyZVHDHb_xhpfTz=FggbB=GGUM+e6tKwkDjGtFEkg@HIDDEN> Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Eli Zaretskii <eliz@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Tue, Aug 17, 2021 at 12:49 PM Eli Zaretskii <eliz@HIDDEN> wrote: > > > From: Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> > > Date: Tue, 17 Aug 2021 09:59:25 +0100 > > Cc: Daniel Mendler <mail@HIDDEN>, larsi@HIDDEN, > > monnier@HIDDEN, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org > > > > I'm sorry, but I'm not drinking from your herbarium. > > Once again, I'm asking everyone to please remove the emotional and > sarcastic parts from the exchange. It is not helping to have > constructive discussions. I thought it was rather appropriate for the "my cup of tea" line :-) But I get the message, and I apologize. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 17 Aug 2021 11:49:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 17 07:49:15 2021 Received: from localhost ([127.0.0.1]:51976 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFxah-0002KN-8O for submit <at> debbugs.gnu.org; Tue, 17 Aug 2021 07:49:15 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53000) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1mFxac-0002Jn-3o; Tue, 17 Aug 2021 07:49:10 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53542) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mFxaW-0006Vj-51; Tue, 17 Aug 2021 07:49:00 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2906 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mFxaV-0007lh-Nz; Tue, 17 Aug 2021 07:49:00 -0400 Date: Tue, 17 Aug 2021 14:48:55 +0300 Message-Id: <838s1070m0.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> In-Reply-To: <87zgtgxx8y.fsf@HIDDEN> (message from =?utf-8?B?Sm/Do28g?= =?utf-8?B?VMOhdm9yYQ==?= on Tue, 17 Aug 2021 09:59:25 +0100) Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN> <CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN> <eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN> <87a6lihv7b.fsf@HIDDEN> <63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN> <CALDnm50W_=Y_zP7KLznqcqSx8KJp2-0u2NwpuEGzzAUzCNHvKQ@HIDDEN> <c95dea17-ca29-4dee-d53d-b5d46f7f2cf8@HIDDEN> <83k0kl8sxm.fsf@HIDDEN> <f53a5330-fe7c-269c-ce34-9f2870e24e61@HIDDEN> <83bl5x8r02.fsf@HIDDEN> <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@HIDDEN> <8735r9ii8b.fsf@HIDDEN> <e9de5ee9-154b-0e52-f784-f10152ff9347@HIDDEN> <87tujpgscj.fsf@HIDDEN> <5118e88c-5b90-60f0-b5eb-ab4ce8bdc0dc@HIDDEN> <87zgtgxx8y.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: mail@HIDDEN, monnier@HIDDEN, 48841 <at> debbugs.gnu.org, dgutov@HIDDEN, larsi@HIDDEN, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: João Távora <joaotavora@HIDDEN> > Date: Tue, 17 Aug 2021 09:59:25 +0100 > Cc: Daniel Mendler <mail@HIDDEN>, larsi@HIDDEN, > monnier@HIDDEN, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org > > I'm sorry, but I'm not drinking from your herbarium. Once again, I'm asking everyone to please remove the emotional and sarcastic parts from the exchange. It is not helping to have constructive discussions.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 17 Aug 2021 08:59:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 17 04:59:37 2021 Received: from localhost ([127.0.0.1]:51656 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFuwb-0001rv-8Z for submit <at> debbugs.gnu.org; Tue, 17 Aug 2021 04:59:37 -0400 Received: from mail-wm1-f48.google.com ([209.85.128.48]:54956) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1mFuwZ-0001rc-Ak; Tue, 17 Aug 2021 04:59:36 -0400 Received: by mail-wm1-f48.google.com with SMTP id g138so13204806wmg.4; Tue, 17 Aug 2021 01:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=/dHRq1CLiHWhD7Jq2ZxdiJWP1UyGng3ccHVR6VjpgyM=; b=uRDRDoT/DLWGL+UByQK9yEGAK9aBW2hYBmdngJuA9OPx9uJZ+BeOXDRSm+VPC0KRgd la0DKIME4lGkwUhJcVm1dye40ZOHVv/Q5OkI1D3UNdZ5AK852x7Whr6HJyhP8QnB5o43 N7LFKV4URwZm70qHY1+kitqhil17pjpdmjTjzk+QQFcczyUfsqak8mzqIj/sDskvV6Sl cw/RxSXWRJQDpFTmV1PfkN85dTSjTPMi+OeHHtlygKRLb2wI1PaDK4KKLXtmGBHJV19E lCdat8KvBD+tTlx/eo0hIBjT3KZuswe+gj10JX+5YoBsRR8qaon29A9bJ4nXg2kAovI0 3diQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=/dHRq1CLiHWhD7Jq2ZxdiJWP1UyGng3ccHVR6VjpgyM=; b=CohTlTsyqLQUfTlfLd1teU+aXLps2dPwteDsMrmbks2fpOdpNEwvMZcWmlJn3nyQly ISi1LV8P/oCDzuxbYsaHiMLcQw+zCuJpahjsG6pkKpa0mrH6IEdnJuNxXQEW2Mkmh1NE AY9rLAzaIyduZsC11TUCId8d5qym2AE30uvzcM9MrXJEf76YTQzkKRi/wPmbYfa910G5 LEGl3IMSfV+ixEpLKyvZNhHDxU+tt/GlQnbiS1rexAoRmFAdNkW21YXvG81z0fgWWMzu TJn2TlvOLqlT0kS2OzMR+rGm6dBzZgUju43VTk06IiWHDWtTSDboKhFjoc6m6xVochl8 NCnw== X-Gm-Message-State: AOAM530FmEpHsjyLMmQpDdd8sp/vyJ7qfG07H3GO+E+9V+NKJ9g4dQJc Rw5IXJQ24uGJ9ajgmLjRHhOBcOIsfYc= X-Google-Smtp-Source: ABdhPJwsfqLedihw68Sh6MbVaQGXzHfs8AshozH8sIDGzQTLk6wiYmR8HdnRBL+YIyvvhE6u4fPRAw== X-Received: by 2002:a7b:c5d2:: with SMTP id n18mr2266047wmk.97.1629190768886; Tue, 17 Aug 2021 01:59:28 -0700 (PDT) Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132]) by smtp.gmail.com with ESMTPSA id g21sm1449040wmk.8.2021.08.17.01.59.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Aug 2021 01:59:28 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN> <CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN> <eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN> <87a6lihv7b.fsf@HIDDEN> <63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN> <CALDnm50W_=Y_zP7KLznqcqSx8KJp2-0u2NwpuEGzzAUzCNHvKQ@HIDDEN> <c95dea17-ca29-4dee-d53d-b5d46f7f2cf8@HIDDEN> <83k0kl8sxm.fsf@HIDDEN> <f53a5330-fe7c-269c-ce34-9f2870e24e61@HIDDEN> <83bl5x8r02.fsf@HIDDEN> <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@HIDDEN> <8735r9ii8b.fsf@HIDDEN> <e9de5ee9-154b-0e52-f784-f10152ff9347@HIDDEN> <87tujpgscj.fsf@HIDDEN> <5118e88c-5b90-60f0-b5eb-ab4ce8bdc0dc@HIDDEN> Date: Tue, 17 Aug 2021 09:59:25 +0100 In-Reply-To: <5118e88c-5b90-60f0-b5eb-ab4ce8bdc0dc@HIDDEN> (Dmitry Gutov's message of "Tue, 17 Aug 2021 05:08:15 +0300") Message-ID: <87zgtgxx8y.fsf@HIDDEN> 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: 47711 Cc: Daniel Mendler <mail@HIDDEN>, larsi@HIDDEN, monnier@HIDDEN, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> writes: > On 16.08.2021 21:25, Jo=C3=A3o T=C3=A1vora wrote: >> I've made it faster, now very close to the string-propertizing approach, >> itself very close to the theoretical best (which is no copy, no >> highlight). See the tip of the >> scratch/icomplete-lazy-highlight-no-string-props branch, which I had to >> rewrite (some Git flub-up). All benchmarks after sig. > > Thanks. I've read it now. > > This implementation style (quick exfiltration via a dynamic var with > some special-cased logic) reminds me of the recent changes to eldoc, > really not my cup of tea. I'm sorry, but I'm not drinking from your herbarium. Googling for "exfiltration" brings up "malware" and data security. Why is mine "quick" at that? Is this some kind of metaphor? And what does "some special-cased logic" refer to exactly? I see as much similarity to Eldoc and I do to the Sistine chapel. The only thing I understand, I think, is "dynamic var". If you mean the variable 'completion-lazy-hilit', notice it is not necessarily used as dynamic var (in fact in icomplete.el it's just a buffer-local var). As I explained elsewhere, if the completion machinery had a realiable abstraction for "session" I would use that.=20=20 I don't think it does, does it? Currently, it's the frontend who holds that knowledge. It will either have an object representing it (maybe a fancy CLOS thing); or a stack frame with some kind of command loop; or, in the case of icomplete, a minibuffer session delineated by kill-all-local-variables. So, for icomplete.el, setting that variable buffer-locally is the appropriate thing. For the command-loopy frontend, dynamically binding it will be. The the objecty frontend, the object itself it proabably a good value for complation-lazy.hilit. For completion-capf, if you cared to optimize it with this stuff, it will likely be ... something something. Anyway, the "implementation style" I went for is speed, brevity and a decent docstring. And it'd be a bit shorter if it used string properties... > At the very least, though, you have done the work of proving that the > no-string-propertization approach can be just as fast. Thank you for > that. You're welcome. Not really just as fast, but in the big-O ballpark, of course. I had hoped to show also that the particular choice of global structure for string/symbol/whatever association is irrelevant. I'm still missing the imminent catastrophe (that is so clear to you) of the put-text-property approach. I'd like these slower and more complex techniques to appease more than superstition. > A hash table with :test 'eq is a good choice. I'd be happy to try to > tweak it further, but it also seems that at this point we can > transition to the discussion about what kind of implementation style > we want, since the performance is proven to be more or less on par. > > Though of course that should start with an alternative patch which > adds icomplete support as well (either Daniel does it, or I'll give it > a try). I'm curious to see those, yes. But Eli pointed out on, two different APIs will need to cohabitate since the new API won't kill off the old. To be very clear, I'm interested in the performance of Daniel's patch, not really in insufferable claims of its beauty and virginity. minibuffer.el is a great big mess, I'll leave it to the Great Designers of the Big Redesign, godspeed to them. Currently, I just want changes to not assassinate, in speed or form, icomplete.el or the flex completion style, two fundamental daily drivers to my work, and other's work. So if/when Daniel's patch doesn't do any of that (it seems that it currently does), I'll be all for it. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 17 Aug 2021 02:08:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 22:08:28 2021 Received: from localhost ([127.0.0.1]:51219 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFoWi-0005zZ-H1 for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 22:08:28 -0400 Received: from mail-wm1-f43.google.com ([209.85.128.43]:35548) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1mFoWd-0005ym-SJ; Mon, 16 Aug 2021 22:08:27 -0400 Received: by mail-wm1-f43.google.com with SMTP id q11-20020a7bce8b0000b02902e6880d0accso787481wmj.0; Mon, 16 Aug 2021 19:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=IAvF5+6geKHEsuSSEwhyDFNjtZUuki/x4PcgcWs5sg4=; b=qdRwou/tFgAeUiduNxNZKjaiARWFqmtU+7h2607k1U2n6u7+bgOQW7lkiVxje3r+sh /epnbO5D2MtkVFN8RwPoDYQfXMhD0hXZ9ZpOTXFlwk54NJF0G6Fxv06cGqm9YcuWCgMy ktz3cqASgTjxboOdO2Q3B4Th7oQyxvuRS43vO2Dm2FKfqX1dvA2/Gi94FaVLi5OaEkbN YBfRKeUuRCkZryyk5VbkNENy5clAUV+MxPnRzdm3BmsEuIy1HBBtlai7zVre7ggBU/8X ZgZmXLisKRZH9YOlVr5drZwZxUNKNMjjaOhg8ghK0fE8JqkyoVbrksUrkelI7H0R+vgz DRXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=IAvF5+6geKHEsuSSEwhyDFNjtZUuki/x4PcgcWs5sg4=; b=QdkFc+2IVRvrl2EPn9wCtkV1ARoyLeDiyMt0FaKcmPrciMl/ty3bmJ3zrF9rTJU8G2 lxRIto77yeYTYry6DEWKD/yuy9sWqcTJuT9w+ckQ+5QoLhDdCqpJYSFELkuEVk2JTK14 HbC/owtY+QsSBzQMvSCKy3vdGYNi8hL+S/matFgY0OWpgqX14d4GyReXclixWAYAmV4I Xnn512JJ7/titXeHTkKws2hNeoDmM92LCSahRG7dQ9JcQwNJ7rDcUgpf0YOwglmrpuby 0UdR7QwgymCJVHg+054KpqKxxpgTENo0bDpjsePyEgAuJyyEpiJB31n9Cs1qqWn7YArz ADqA== X-Gm-Message-State: AOAM531y9UvBZx2+09np3Y1uTM2zshz4Pvtg5uD14ekxFj/b2FmWkAcl V5FoFVzgvRjwMk0BS595J33dcIb2PUA= X-Google-Smtp-Source: ABdhPJxKoZa0etc1GMrF2vGIkqKsVfbehrU+3zPd5WmDAn41g2TPJBSXFDKEuQRKOxu+ERz7+nb7VQ== X-Received: by 2002:a1c:cc02:: with SMTP id h2mr814967wmb.39.1629166098047; Mon, 16 Aug 2021 19:08:18 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id y11sm671479wru.0.2021.08.16.19.08.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Aug 2021 19:08:17 -0700 (PDT) Subject: Re: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN> <CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN> <eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN> <87a6lihv7b.fsf@HIDDEN> <63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN> <CALDnm50W_=Y_zP7KLznqcqSx8KJp2-0u2NwpuEGzzAUzCNHvKQ@HIDDEN> <c95dea17-ca29-4dee-d53d-b5d46f7f2cf8@HIDDEN> <83k0kl8sxm.fsf@HIDDEN> <f53a5330-fe7c-269c-ce34-9f2870e24e61@HIDDEN> <83bl5x8r02.fsf@HIDDEN> <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@HIDDEN> <8735r9ii8b.fsf@HIDDEN> <e9de5ee9-154b-0e52-f784-f10152ff9347@HIDDEN> <87tujpgscj.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <5118e88c-5b90-60f0-b5eb-ab4ce8bdc0dc@HIDDEN> Date: Tue, 17 Aug 2021 05:08:15 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <87tujpgscj.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, larsi@HIDDEN, monnier@HIDDEN, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.6 (/) On 16.08.2021 21:25, João Távora wrote: > I've made it faster, now very close to the string-propertizing approach, > itself very close to the theoretical best (which is no copy, no > highlight). See the tip of the > scratch/icomplete-lazy-highlight-no-string-props branch, which I had to > rewrite (some Git flub-up). All benchmarks after sig. Thanks. I've read it now. This implementation style (quick exfiltration via a dynamic var with some special-cased logic) reminds me of the recent changes to eldoc, really not my cup of tea. At the very least, though, you have done the work of proving that the no-string-propertization approach can be just as fast. Thank you for that. A hash table with :test 'eq is a good choice. I'd be happy to try to tweak it further, but it also seems that at this point we can transition to the discussion about what kind of implementation style we want, since the performance is proven to be more or less on par. Though of course that should start with an alternative patch which adds icomplete support as well (either Daniel does it, or I'll give it a try).
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 18:25:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 14:25:14 2021
Received: from localhost ([127.0.0.1]:50952 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1mFhIP-00038o-Oe
for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 14:25:14 -0400
Received: from mail-wm1-f41.google.com ([209.85.128.41]:37427)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>)
id 1mFhIM-00038Q-8B; Mon, 16 Aug 2021 14:25:12 -0400
Received: by mail-wm1-f41.google.com with SMTP id
c8-20020a7bc008000000b002e6e462e95fso68660wmb.2;
Mon, 16 Aug 2021 11:25:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:cc:subject:references:date:in-reply-to:message-id
:user-agent:mime-version:content-transfer-encoding;
bh=0BE4nTI0Dd3MVVLlpx1zJYGASsxUaJ4h6dDPWSlxDks=;
b=IUmVH58Wlk5LXcC7cOXNmJmBG8dmNuqlPDZDNXrb+qTVGauEVYjXkZImXdgiJL4KWE
WHaYKI2Z+vTXqNJxkfUWTtG6nnCvBJC357wpzaGEZ59xSx7BZymfQeA7++XLZWWlpeJg
LbQLYABh53mNKF/tCToo9ge8uy1nySfm4wnBVu7ukyUKohwo4VW9iZC+KAWMUM9xpdEA
vMAkUKO50+v5RKMzQdZ/EXbKyXjuloHyOuwYklBKyOacwG01+bad3Up6/i8Dgpw5aIh0
weD+G00ytsT+si218pf8/pLqhG6to9DpOI5BK3B7fa+1D74zTzgmkdlj2m+xvqjJsuZL
mitA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
:message-id:user-agent:mime-version:content-transfer-encoding;
bh=0BE4nTI0Dd3MVVLlpx1zJYGASsxUaJ4h6dDPWSlxDks=;
b=LvNE67S4Pcz85buMgpdiTpsZBEThwMzWe/yu485N7UKBJzqTSUYpVNRpnSfBePwkWP
pNWTEcgJ6MAh3376FFF2cIhLQ/jqYPCPj1Ks7eYyrH/B6QXZ+gPThiYFtlQ44dyzvJl9
Kn6s4JRpQKtAx9+ZewUv4+i02dSG+y1WedW1T6I5vkfQdt3OVxWmF/rGqC79ZrEcGR8m
kJzx2kdqMIFDZ7kG8nheAgoV2kyoShp9HxMpelgXc2qZXhqvPA16mv7GYrTUF2D7qSal
c1+HO3I8kjEaL35drnEg8sQCNVBspd44I3uK3gIp5Vua/gdK/pd+Uqo1SOtDbnWX2jOu
LU1A==
X-Gm-Message-State: AOAM530pJDiUpoVbdHDxTxieLeY2xHGUJ30cN5FKwG43xZVuGCEXxsp9
6t4X9LcvBdwFbL7YQmXUSYvZIKVJuNw=
X-Google-Smtp-Source: ABdhPJyz1SX1npNmBM2hABJYxBnaAgGjAVWLvcpPufKvVmqnEmz12swhsQMV5sSQsQXecsNZq3YGkw==
X-Received: by 2002:a05:600c:3b91:: with SMTP id
n17mr413535wms.72.1629138303918;
Mon, 16 Aug 2021 11:25:03 -0700 (PDT)
Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132])
by smtp.gmail.com with ESMTPSA id i3sm286343wmb.17.2021.08.16.11.25.02
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 16 Aug 2021 11:25:03 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new
`completion-filter-completions` API and deferred highlighting
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN>
<8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN>
<87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN>
<87wnootec0.fsf@HIDDEN>
<5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN>
<CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN>
<0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN>
<CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN>
<eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN>
<87a6lihv7b.fsf@HIDDEN>
<63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN>
<CALDnm50W_=Y_zP7KLznqcqSx8KJp2-0u2NwpuEGzzAUzCNHvKQ@HIDDEN>
<c95dea17-ca29-4dee-d53d-b5d46f7f2cf8@HIDDEN>
<83k0kl8sxm.fsf@HIDDEN>
<f53a5330-fe7c-269c-ce34-9f2870e24e61@HIDDEN>
<83bl5x8r02.fsf@HIDDEN>
<77e98cdf-427d-ec7a-7a49-04dcd65d6a94@HIDDEN>
<8735r9ii8b.fsf@HIDDEN>
<e9de5ee9-154b-0e52-f784-f10152ff9347@HIDDEN>
Date: Mon, 16 Aug 2021 19:25:00 +0100
In-Reply-To: <e9de5ee9-154b-0e52-f784-f10152ff9347@HIDDEN> (Dmitry Gutov's
message of "Mon, 16 Aug 2021 17:33:20 +0300")
Message-ID: <87tujpgscj.fsf@HIDDEN>
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: 47711
Cc: Daniel Mendler <mail@HIDDEN>, monnier@HIDDEN,
48841 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, larsi@HIDDEN,
47711 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Dmitry Gutov <dgutov@HIDDEN> writes:
>> prepared a version of my patch that is based on weak-keyed hash tables.
>> Slightly slower, but not much. Here are the usual benchmarks:
>
> Cool, I'll take a look, thanks.
I've made it faster, now very close to the string-propertizing approach,
itself very close to the theoretical best (which is no copy, no
highlight). See the tip of the
scratch/icomplete-lazy-highlight-no-string-props branch, which I had to
rewrite (some Git flub-up). All benchmarks after sig.
Jo=C3=A3o
(require 'cl-lib)
;; Introduce 300 000 new symbols to slow things down. Probably more
;; than most non-Spacemancs people will have :-)
;; (setq ido-enable-flex-matching t)
;; (ido-mode)
;; (ignore-errors (ido-ubiquitous-mode))
;; (fido-mode)
;; (fido-vertical-mode)
;; (vertico-mode)
;; (hash-table-keys completion--get-lazy-highlight-cache)
(defmacro heyhey ()
`(progn
,@(cl-loop repeat 300000
collect `(defun ,(intern (symbol-name (gensym "heyhey"))) () 42))))
;; (setq completion-styles '(substring))
(setq completion-styles '(flex))
(heyhey)
(setq icomplete-show-matches-on-no-input t)
(symbol-name 'mouse-kill)
(when nil
;; Press C-u C-x C-e C-m quickly to produce a sample. Always discard
;; the first sample in the session, it tends to have an extra GC and be
;; slower.
(benchmark-run (completing-read "" obarray))
;; don't use string props
(2.848873438 6 0.8307729419999994)
(2.848416202 6 0.8370667889999996)
(2.786944063 6 0.8230433460000004)
(2.7815761840000004 6 0.819654023)
(2.6929080819999998 5 0.7036257240000001)
;; string props
(2.630354852 4 0.7071441910000011)
(2.594761891 4 0.7082679669999994)
(2.589480755 4 0.7112978109999997)
(2.661196709 4 0.7130021060000011)
(2.844372962 4 0.7378870879999999)
;; master
(3.6339847759999997 12 1.601142523)
(3.757091055 12 1.6231055449999996)
(3.785980977 12 1.6333413839999995)
(3.716144927 12 1.6100998260000008)
(3.808275042 11 1.611891043)
;; these next two are not comparable to the above, because in
;; ab23fa4eb22f6557414724769958a63f1c59b49a I added sorting to flex
;; which changes results, and Daniel's patch no longer applies
;; cleanly.
;; daniel's patch
(3.420418068 10 1.451012855)
(3.603226896 10 1.672325507)
(3.501318685 10 1.6150095739999992)
(3.659821971 10 1.6580361760000004)
(3.624743674 10 1.657498823)
;; master just before daniel's patch (254dc6ab4c)
(2.611424665 10 1.5267066549999981)
(2.48811409 10 1.486639387000002)
(2.472587389 10 1.479865191)
(2.543277273 10 1.510667634999999)
(2.546243312 10 1.4986345790000009)
=20=20
)
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 17:00:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 13:00:16 2021 Received: from localhost ([127.0.0.1]:50860 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFfyC-0000qj-1i for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 13:00:16 -0400 Received: from mail-pl1-f176.google.com ([209.85.214.176]:37564) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1mFfy8-0000qI-Vz; Mon, 16 Aug 2021 13:00:14 -0400 Received: by mail-pl1-f176.google.com with SMTP id n12so20738579plf.4; Mon, 16 Aug 2021 10:00:12 -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=qV2+/l5VR/pLQEvxmcp8xycIj/zsXEGyYP9xn5gGVe0=; b=GsAz05UoQg6/DplEU8NcUWhsWadwSKJcptzLN1jytc0gwfdIb0aVAfDpYNjVYY28G4 20aqCryTilZPdvGOg3Ha84LRnxDLzVktHJiYQrGDszWeVXi+lnv3fujLgJoAKX2tVv61 lCU7DAqhiajrTGVxFGSL7mM1ENhWI56bz7v/s3KpNg2+eDQxBeKjQqw/sN+GPwqNfK4z 9zdxhqPVjlOIqJUuh21ali4TfFsQKaJq5D6Gjd6lQDY1FBtWYauCs54+velwgYQz9EPb A65eLjfmiG6BYzzpHAwbRLIeKXVDgUakF9kuZS/TTHcKGw2tM79sIvHdz9t4J5s0WdNm v/+A== 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=qV2+/l5VR/pLQEvxmcp8xycIj/zsXEGyYP9xn5gGVe0=; b=ToPooqAPEKahoF83puli5fIycS+eA8km+WPN/zsWxGkHZSy+N+uhVsL4Q0bYKU1t5X xlHuidjBfpKLjBagf4JT+toFWVkrRL2j1xHUYkglOg2UxsKCYkAQuVJSY4gPWGaJDEJ9 yiBF5i6HidMhZ5d8SVTNqR36JLOALgoFKccPQUKXbC6qaA1Ub4qCACPE1KNCE6q+bTAH 4ulRzKbzsdK4UOYgSyjK/hpJceDG6pGL9hBrEJW6m2HYUainpXCQZfHlNQTR5OouCDnA utLwuFvIs7PGSzLRjNF1iKAlDotN3Ojn+UqCbgTaY4RFI1OPH0xVTc6buYzCGNjLg2G3 hMxA== X-Gm-Message-State: AOAM531LFXivk+lnNs0dETt75+pDQeCbYWuC/4WVFNMCDVWmTUnf/4ca TFFTByHZ/gTgflQaZh85VrXa2fOGYO0cjlJGMik= X-Google-Smtp-Source: ABdhPJzD08NqBBaeHKEjccg31U6XfOuxFKWgSurqoPsC5pMN1VIXBQ7BjByiY3xxe4timXWUTI9x0+Y7eF0NduqRrro= X-Received: by 2002:a17:90b:14b:: with SMTP id em11mr74388pjb.125.1629133206931; Mon, 16 Aug 2021 10:00:06 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN> <CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN> <eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN> <87a6lihv7b.fsf@HIDDEN> <63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN> <CALDnm50W_=Y_zP7KLznqcqSx8KJp2-0u2NwpuEGzzAUzCNHvKQ@HIDDEN> <c95dea17-ca29-4dee-d53d-b5d46f7f2cf8@HIDDEN> <83k0kl8sxm.fsf@HIDDEN> <f53a5330-fe7c-269c-ce34-9f2870e24e61@HIDDEN> <83bl5x8r02.fsf@HIDDEN> <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@HIDDEN> <8735r9ii8b.fsf@HIDDEN> <e9de5ee9-154b-0e52-f784-f10152ff9347@HIDDEN> <CALDnm53iE_=GYyv+cFWCcJZz6rruJe=LabtUx=-UtoXnC0FKEg@HIDDEN> <11bb7457-5b2d-e9bf-3f7d-b145a2df2d5b@HIDDEN> In-Reply-To: <11bb7457-5b2d-e9bf-3f7d-b145a2df2d5b@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Mon, 16 Aug 2021 17:59:55 +0100 Message-ID: <CALDnm51p+Odmw246j96Xvt0xc=3VNtSgVQ90VXxjezY-tWfTfQ@HIDDEN> Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Dmitry Gutov <dgutov@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Mon, Aug 16, 2021 at 3:47 PM Dmitry Gutov <dgutov@HIDDEN> wrote: > > On 16.08.2021 17:36, Jo=C3=A3o T=C3=A1vora wrote: > > On Mon, Aug 16, 2021 at 3:33 PM Dmitry Gutov<dgutov@HIDDEN> wrote: > > > >> I was talking about the values of the properties, not the size in memo= ry. > > Then what's the problem if the value of a property that is an implement= ation > > detail changes? What do you (meaning the user of Emacs) care, ultimatel= y? > > You said "we already have global symbol properties". I pointed out the > differences. Eli said that, I think. Anyway, it doesn't present any kind of problem whether their values of change or not, as long as the space they occupy doesn't. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 14:48:09 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 10:48:09 2021 Received: from localhost ([127.0.0.1]:50733 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFduK-0005oG-Nu for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 10:48:08 -0400 Received: from mail-wm1-f44.google.com ([209.85.128.44]:38573) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1mFduG-0005nc-6p; Mon, 16 Aug 2021 10:48:07 -0400 Received: by mail-wm1-f44.google.com with SMTP id i10-20020a05600c354ab029025a0f317abfso15241518wmq.3; Mon, 16 Aug 2021 07:48:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=NhrkOvKUJICVjl5xDDw9F5RjRHGoP+9qoG17RMwuO/A=; b=RPFZcPJnmriAa8B/h8FyJhr3VSWCPPfeMWdULSQQ5PniNJq/6GPyhsqi4CZKKa+IJb EAB03TbgxV0guqGIUQvpKlC8kwvEj60TceBNSxUT+XPXOD8XDzSNmsgvFHk3cTl2UiSZ OGqM3IQcf0bD5CwPJuq4nTy9oxHm2LJUUgL8w+fibEnyA2G+OaH5D0+u6rxDQlQnpTRI /VGqrVPfzidCVOgv0dCJKCXb0VZLBZLfN4D8sRTkYFE5BDCAv7iw4towZBn7kFy7AGWw FJniXCw2M2APT4ty9cuFWRTenQIT17QdiRFiOkkSx4PnRnt+AEz/FXLFHDz4YpyJIiVo g4hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=NhrkOvKUJICVjl5xDDw9F5RjRHGoP+9qoG17RMwuO/A=; b=Y4D+f9FCoWbQr673CHE37/eGFiVK0CoKEpzUJJp6eN2Kzdijesipsn/Q3AFAodIldl Hw5C0mhSLHsW6gioR2zBmf6iy4cIMJ0oRJWaFm9bA3S4kT0A4lz60sWp5a4jdF6oh7kX 8mUAitaYjyuZhcRITVXL2DpwbsVuhXlZ40r7kOpo/hAP1BSpuHNTmxwurLaIJTpV5aEU YszzKN1lHEDf2nVnqIrUDrNQx5nPZUgWoifzsFFbtiQU5OaKdTtspW5go05nUDXsHqRC ROiXGvyxndmbeNIJsN7AZr38GO+H6v0zizw7KOjt454jPVU937W8ozgufNg6cI4Nswyc FlSg== X-Gm-Message-State: AOAM531ZBCQacZUoUBWrZZ9P1GNKix8wYpkh7ud9K91pxYCwa3hjTDJw Bug85kcxr6LSJIl0H75ufETlW4SpLyI= X-Google-Smtp-Source: ABdhPJzA91feCktNb61n64WxgFD5Tv1PeB8zTHHL/1RfJMUKcrJ7h+BZiDLCy0YyCq9as/M+1ofC9w== X-Received: by 2002:a1c:f60c:: with SMTP id w12mr15582385wmc.3.1629125278336; Mon, 16 Aug 2021 07:47:58 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id b12sm14214564wrx.72.2021.08.16.07.47.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Aug 2021 07:47:57 -0700 (PDT) Subject: Re: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN> <CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN> <eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN> <87a6lihv7b.fsf@HIDDEN> <63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN> <CALDnm50W_=Y_zP7KLznqcqSx8KJp2-0u2NwpuEGzzAUzCNHvKQ@HIDDEN> <c95dea17-ca29-4dee-d53d-b5d46f7f2cf8@HIDDEN> <83k0kl8sxm.fsf@HIDDEN> <f53a5330-fe7c-269c-ce34-9f2870e24e61@HIDDEN> <83bl5x8r02.fsf@HIDDEN> <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@HIDDEN> <8735r9ii8b.fsf@HIDDEN> <e9de5ee9-154b-0e52-f784-f10152ff9347@HIDDEN> <CALDnm53iE_=GYyv+cFWCcJZz6rruJe=LabtUx=-UtoXnC0FKEg@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <11bb7457-5b2d-e9bf-3f7d-b145a2df2d5b@HIDDEN> Date: Mon, 16 Aug 2021 17:47:56 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <CALDnm53iE_=GYyv+cFWCcJZz6rruJe=LabtUx=-UtoXnC0FKEg@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.6 (/) On 16.08.2021 17:36, João Távora wrote: > On Mon, Aug 16, 2021 at 3:33 PM Dmitry Gutov<dgutov@HIDDEN> wrote: > >> I was talking about the values of the properties, not the size in memory. > Then what's the problem if the value of a property that is an implementation > detail changes? What do you (meaning the user of Emacs) care, ultimately? You said "we already have global symbol properties". I pointed out the differences.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 14:37:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 10:37:14 2021 Received: from localhost ([127.0.0.1]:50728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFdjj-0005Xi-2R for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 10:37:14 -0400 Received: from mail-pj1-f46.google.com ([209.85.216.46]:37715) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1mFdjZ-0005Wz-Qu; Mon, 16 Aug 2021 10:37:05 -0400 Received: by mail-pj1-f46.google.com with SMTP id cp15-20020a17090afb8fb029017891959dcbso32760865pjb.2; Mon, 16 Aug 2021 07:37:01 -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=5PAeg9RsNGdHlZZkjv/EqP3UgGZjKj40G9my239+9iI=; b=I1M5PacNzqw2YsE+1EelLTLzWsDpFHSKMKBXh5YJoCOTS85fJrr8Hzmdzb6FUI+G1P b9il8CMoZuh8vE/Zv8BS2w9Q2QxxGsaXoixlB7+AXASnw93mq7+57aCHJpM3MDI/h1P5 XmNDOZE0xjYoexXKw54ahVihGbUSeXiRj6fVUFFBfAEhiiwChJTcunvS++2YKpqN642z mEUI+MUZFC3Qa2YREg1x3RkNQhJ5grGjqdW304SdO9TOPhmaDkBfkAb5Q/x2fNQzXVsZ bS/BJL6Dj7Kxo8VzhDUiSx+OTPMKCzqCpiuK/lVT1+xhtW0ctX1bhfuqiW9vVamRCfBo FNSA== 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=5PAeg9RsNGdHlZZkjv/EqP3UgGZjKj40G9my239+9iI=; b=Zb5v73tfxcPJPkAQplhRNi0jGlLvlJYDOrKhMliKVRg9b2nVSWTT9Kg78SZeLtnssc UaLT6FawEWFoNwdaTpc2FN6taGX87nq2dYh5ytUXcmKyITJBvNJF30hl5ImPIah6wcn5 WfPb9FVpmhx+8QS1Rmkr63brJLv1J5xtd6zVM3t9bhT/GefZYxj2EVef2T3HLx1m3dg5 5IKjxPGdZUS/U9bee3v4qNkfduI6+4ILzHsinis6cgM0k/SXsiwHjA1taEQQjFz6pThZ 9gZvZSEWxGCqZe18CmoghLU9xaIEEQkDA+kSrFg4/jrFwgQVZWeeLcOLKSd2jTs6C0Lu QkFA== X-Gm-Message-State: AOAM532yTF7agIy/Vw6xRJ09xlN1nKjFh0wZYaS3lpL63vzKeZbIPJHV m0HM+JFCP4FQ04SHMWnquyfScoJSXunCsfgLbyI= X-Google-Smtp-Source: ABdhPJybZKjkYF+cqnVxXra5q7YDqJ96+OX2Fgc2nCaRioja0ZeZ33DA5MU7nZlNU4R3ohdOwIrACLOsy5423NnafQw= X-Received: by 2002:a05:6a00:164d:b0:3e1:ab35:f3e4 with SMTP id m13-20020a056a00164d00b003e1ab35f3e4mr7708732pfc.42.1629124615984; Mon, 16 Aug 2021 07:36:55 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN> <CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN> <eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN> <87a6lihv7b.fsf@HIDDEN> <63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN> <CALDnm50W_=Y_zP7KLznqcqSx8KJp2-0u2NwpuEGzzAUzCNHvKQ@HIDDEN> <c95dea17-ca29-4dee-d53d-b5d46f7f2cf8@HIDDEN> <83k0kl8sxm.fsf@HIDDEN> <f53a5330-fe7c-269c-ce34-9f2870e24e61@HIDDEN> <83bl5x8r02.fsf@HIDDEN> <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@HIDDEN> <8735r9ii8b.fsf@HIDDEN> <e9de5ee9-154b-0e52-f784-f10152ff9347@HIDDEN> In-Reply-To: <e9de5ee9-154b-0e52-f784-f10152ff9347@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Mon, 16 Aug 2021 15:36:42 +0100 Message-ID: <CALDnm53iE_=GYyv+cFWCcJZz6rruJe=LabtUx=-UtoXnC0FKEg@HIDDEN> Subject: Re: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Dmitry Gutov <dgutov@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Mon, Aug 16, 2021 at 3:33 PM Dmitry Gutov <dgutov@HIDDEN> wrote: > I was talking about the values of the properties, not the size in memory. Then what's the problem if the value of a property that is an implementatio= n detail changes? What do you (meaning the user of Emacs) care, ultimately? Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 14:33:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 10:33:31 2021 Received: from localhost ([127.0.0.1]:50719 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFdgB-0005S1-BS for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 10:33:31 -0400 Received: from mail-wr1-f46.google.com ([209.85.221.46]:44708) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1mFdg9-0005Rl-6Q; Mon, 16 Aug 2021 10:33:29 -0400 Received: by mail-wr1-f46.google.com with SMTP id x12so23930221wrr.11; Mon, 16 Aug 2021 07:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=7yhkRd6f073YFMR5goDbFsS2fzyvIVrl94x/SsJzrBg=; b=DY50Iid1Sbj2GK1mneKSFMOsR+9XsulzGyPciOTRvzyaHaUnuYgT5vGlUWgZZmI1dy 4swb/1o5E76ywfkXBcHk2Nkqv3xUJIZioPA323JMbV6uox8gW32xN7aP5VNXC+1ED2wZ SIPrO14fbQ2xB7XHHOTBO8/3yLADLP+MfXtGGj2fOSu3O5/V4gaI1hM3PIZme1+LRSE+ Lpun3UAf8nLGSjofB0sy/+NayRhvlTxnxk+NCq0YftQ0Eydd8cfsh83xSgBnUEqwLTvO 3+0HJ31QLtknj/2c+FQUKnoXUrkxy4wYGh3TWrBKojD4vf/IA0msCsZoJGQuoeiobN/6 73qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=7yhkRd6f073YFMR5goDbFsS2fzyvIVrl94x/SsJzrBg=; b=bY54YElHTygTqe2u5xqJiMHv+r7MmlLLBnr/Jf2vXMh89A3XUMMW0JEtR5lbFMv0uV tsUPADEjOzIxQXfHsmJQqdV4TqfoKVTUJcq8Ep3Io+HCNF25i+6StAmr25SH0WlLgT7q SD6LnoPtHResdG5NzJbNcQlLY8bpSPeIu4J77Fj009VkfNnkDM7Wlq/m+PqWAFJR4by+ 6/6xnsylrhKW2uTArEgzceUq6sw85LiwlbRD/09dL91RE97x6wJ1w6/jWDqiCYhaqHtd pjEB+hRvqj9amkoiD4UKgeQfVXz8ewBdvQetPI47e7TEEYC6OfKOaUi0ryC6ibgfQLsy aSig== X-Gm-Message-State: AOAM533gFxpZ8XbhKk22ZelOUIBJLla54+MXCrilu7a6i9StmhTitPGI cn4KcJlCLb+mD06aEWPEQNS1ul54d24= X-Google-Smtp-Source: ABdhPJye/8ZNsPClneQzyydQRGpxAx4fmWBC0WlxNewFmwuGeLmb5UpSaleWrGePWNb8/hgkaGFOqw== X-Received: by 2002:a5d:6642:: with SMTP id f2mr11836658wrw.278.1629124403311; Mon, 16 Aug 2021 07:33:23 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id n16sm11867571wru.79.2021.08.16.07.33.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Aug 2021 07:33:22 -0700 (PDT) Subject: Re: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN> <CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN> <eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN> <87a6lihv7b.fsf@HIDDEN> <63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN> <CALDnm50W_=Y_zP7KLznqcqSx8KJp2-0u2NwpuEGzzAUzCNHvKQ@HIDDEN> <c95dea17-ca29-4dee-d53d-b5d46f7f2cf8@HIDDEN> <83k0kl8sxm.fsf@HIDDEN> <f53a5330-fe7c-269c-ce34-9f2870e24e61@HIDDEN> <83bl5x8r02.fsf@HIDDEN> <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@HIDDEN> <8735r9ii8b.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <e9de5ee9-154b-0e52-f784-f10152ff9347@HIDDEN> Date: Mon, 16 Aug 2021 17:33:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <8735r9ii8b.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, monnier@HIDDEN, 48841 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, larsi@HIDDEN, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.6 (/) On 16.08.2021 17:20, João Távora wrote: >>>>> FWIW, I also don't understand how adding properties could cause a >>>>> memory leak. When a string is GCed, its properties get GCed as well, >>>>> all of them. Am I missing something? >>>> >>>> If you add string properties to all symbol names this memory will stay >>>> alive for much longer than necessary. >>> That's a very extreme example, something that I wouldn't expect a >>> Lisp >>> program to do, without removing the properties shortly thereafter. >> >> And that *will* happen with Joao's approach, as soon as some package >> implements a Lisp completion backend in a certain (legal) fashion. > > There is no leak, not in the strong or weak sense. Eli already said that, in a sentence that I also quoted. And still: "I wouldn't expect a Lisp program to do <so>". > There is a constant > usage memory footprint proportional to the size of obarray, yes, but the > factor isn't huge. From the top of my head, I think it's about two > conses and a fp number for each sym. does anyone know how much that is > or can teach me how to measure? Thanks. If we say that your approach is legal, those are only "two conses and a number" coming from minibuffer.el. But since other packages will also be allowed to do that, the factor will only be limited by the amount of installed packages. > Anyway the current situation is constant copies of strings that put > pressure on the GC, as the benchmarks show. > > Anyhoo, in the interest of placating this string property bogeyman, I've > prepared a version of my patch that is based on weak-keyed hash tables. > Slightly slower, but not much. Here are the usual benchmarks: Cool, I'll take a look, thanks. >>> And even that isn't a leak. >>> Note that we already put all kind of properties (although not text >>> properties) on symbols. >> >> Those do not, generally, change over time. > > Neither does this one! At least in size, which is the thing that > matters. So in terms of "negative" consequences it's exactly > equivalent. Read the patch it will be obvious, I think. I was talking about the values of the properties, not the size in memory.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 14:30:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 10:30:19 2021 Received: from localhost ([127.0.0.1]:50711 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFdd5-0005NB-G9 for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 10:30:19 -0400 Received: from mail-pj1-f41.google.com ([209.85.216.41]:44010) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1mFdd3-0005Ms-E0; Mon, 16 Aug 2021 10:30:18 -0400 Received: by mail-pj1-f41.google.com with SMTP id qe12-20020a17090b4f8c00b00179321cbae7so280594pjb.2; Mon, 16 Aug 2021 07:30:17 -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=6gCp2MWkyrOJTenj/gaPXra0uN7FZ0nNTmOza/+qVsI=; b=lzBx9LyacYo6GTONb6OG/EiRBXB6jmpUxfDbe+MQcEWX3oqdOZM3y1Mu+cS6IhxKHb LkKwYcRsKPEmFeKFFHvBwf/hSliFZmBvaHueNn6EEzgqwPa7QcHKPS0huJ8uTjUFUAYC 0UUpIi7GcQQBVzRCJiYBawRxXU9YdIEV/nIFDNTzsColOtyIY7PBowWfXgQG/dD1xPPT gL7jwrysclqNAl/ZkbVE4EZ/VzoaWkYSGYpwIR8fSMSXxhA1W8kxdi3VQJiAD/CPmw19 extC4cg10qBiwT0BeJEIkRXPTyfMx0kdISDEbKyqgIEvHNuWHyWf7YoXBp/TCXztw+HP 1Lsg== 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=6gCp2MWkyrOJTenj/gaPXra0uN7FZ0nNTmOza/+qVsI=; b=amFpRnBtz5fE97BWdGdcOpgjlAIAFNz9kavWl1uludqVKbHgLxDVHgWKeRyI13rJdr D90o3/aMuXR95fH54AfuRA99Wh1tqsSxBnCN8zszKvMK3h2RfuaBM9zk8lxPf+KYjpVu sCKVzlJslqEVX0XjYwy38/tx3LbZ0+rzb7WSlFo0x8esPQpZe1nZxfuoe2jPkGS/9QHk MszPgbl6wGjoMD1AZF28XfwUsoKtVQpRNAi7hmXf6iX9TP7l+itAe8u5f1SA2TchWyQM ZnStLL4DhR8Jj13E8mPtn4EXzoaOivt8JYIeVs65TME6m9X59oVaUn1+CKknEnXliOjK pC0g== X-Gm-Message-State: AOAM530OQqcNmLmKsePJv5NQ7Oq+NZH4z94K7DrRzZGDj25GvhLJiiQW dnmL9s74OCejTeVnCjB8cOfAlq2DprtJvM9SXe0= X-Google-Smtp-Source: ABdhPJwTdogs3r4e6mUHhd+5hHpBbqySsUMfev3EkDgq8pw5pqXZJECoHZXwISGxqEAy8hsfKh7nh2pyqNFtX6k4ohA= X-Received: by 2002:a17:902:d487:b0:12d:89d3:a6b with SMTP id c7-20020a170902d48700b0012d89d30a6bmr13674772plg.52.1629124211514; Mon, 16 Aug 2021 07:30:11 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN> <CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN> <eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN> <87a6lihv7b.fsf@HIDDEN> <63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN> <CALDnm50W_=Y_zP7KLznqcqSx8KJp2-0u2NwpuEGzzAUzCNHvKQ@HIDDEN> <c95dea17-ca29-4dee-d53d-b5d46f7f2cf8@HIDDEN> <CALDnm53TD=FCf0davQC6q9esVxz687oBGN2LF=Egz3-kz6681Q@HIDDEN> <724345d2-a87b-064b-7ccf-b4ac2b66cc8d@HIDDEN> In-Reply-To: <724345d2-a87b-064b-7ccf-b4ac2b66cc8d@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Mon, 16 Aug 2021 15:29:57 +0100 Message-ID: <CALDnm50xAa_rconLd1jtFr1hNgrJ04Xo9qUfp=ugyjgEMUPtww@HIDDEN> Subject: Re: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Dmitry Gutov <dgutov@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Mon, Aug 16, 2021 at 3:26 PM Dmitry Gutov <dgutov@HIDDEN> wrote: > > On 16.08.2021 14:37, Jo=C3=A3o T=C3=A1vora wrote: > > I am not a native English speaker, and maybe you don't understand > > my language. Another way to explain what I am talking is to talk abou= t > > "bug reproduction". You say there's a bug in my patch, I am asking you > > for a "bug reproduction recipe" as defined by most, if not all, the re= sults > > you get by searching "bug reproduction recipe" in the Google search eng= ine. > > I hope you, or at least other here, can someday see and understand that > asking to prove standard engineering practices from the first > principles, time and time again in various discussions, is not a way to > encourage good atmosphere or promote project participation. > > Are you really not imagine a buggy scenario coming from a combination of > downstream uses of 'completion-score' property, different completion > styles (some setting it, and some not), and a completion table that > either uses global string values outright, or caches them for the > duration of the current command? I don't. Please prime my imagination with some illustration based on your fertile imagination of these things and the patches I have provided. Oh and spare me the lectures. Thanks. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 14:26:55 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 10:26:55 2021 Received: from localhost ([127.0.0.1]:50705 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFdZm-0005Fj-VJ for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 10:26:55 -0400 Received: from mail-wm1-f49.google.com ([209.85.128.49]:55046) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1mFdZl-0005FG-6d; Mon, 16 Aug 2021 10:26:53 -0400 Received: by mail-wm1-f49.google.com with SMTP id g138so11696540wmg.4; Mon, 16 Aug 2021 07:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sMEkiRq9ciWt+FPYy3cM0scH+z6bE93cpI/bIhDmE0g=; b=FQZoaZ1sThmU01FKL8HRaeGtyI5SfqcEUjPk8DJyLvT5TKy4hjXMhvY54tKaYqqC/w /Xwmqnrm7LBgLE4AXiarBQwQ5N17DoU8nFuTqQcMhMRi+hsr1lTcumaD79L4U2NEXsdG wxIRw7zqDKs5DwKnN7olruQJpTCkmMXYnVd+Tz8GptJLCbqx3pGBfoJdvmLoyn/M2exa Nyzb5OttWzu3xuvIqT8lr2Xwf5LUoktsFWMfKswhHIa14rdN4ulysdhTcww8DldHuMmz RLJW7aEDuSI/TGICXOSOVTAtfViH6vCAZe+lpv3ml+FAP4eRc8sCWDTe8ytqbOjBbS2c fhnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=sMEkiRq9ciWt+FPYy3cM0scH+z6bE93cpI/bIhDmE0g=; b=JSp9XAmv9U182r3CCZ4JC6cAV5W1dQU9xGvL1rbKkVe7sran+bYbF+HkI3JfZ/Qt9U T0ywKkzstKNpNg2SidzuBn4KfEncscheNrVFa0NxLHajQS7VFNWDNjR13SJ3MPO9Ts/2 dcyt2aHLLsRGW1NeK36sDBpAzCOGdlF3sHHKc57DYCOtVi5nrrJ6Vk4xTDV4FLjkDTko I9GFh+A3KoMS2AjOErRz6B+fUorN+iD6qCk9YkIkUZ24gliya63/KE3xzo78SA2Mx6S3 G+9hPld5zgsn6A88JKwocDtYf3/O/zFulufGmqTyxhTJV6dZRy4ivwq97tJ2W7bwQz5X qh/g== X-Gm-Message-State: AOAM532hq7BncJFnR1Ghsv/1yU5pNxmoTB5Q9tulU5RF5t8w1BMN8lls hwk69QbzY9jL5zkOMkI/GqU= X-Google-Smtp-Source: ABdhPJw9HkNWrkTbtNMBDcH9FexTi5qO7xptULAMSRWYn4jvYzfyLXBU63JMwurKUL/n3EORgTmP6Q== X-Received: by 2002:a7b:c2fa:: with SMTP id e26mr15753217wmk.102.1629124007391; Mon, 16 Aug 2021 07:26:47 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id f2sm11880151wru.31.2021.08.16.07.26.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Aug 2021 07:26:46 -0700 (PDT) Subject: Re: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, Daniel Mendler <mail@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN> <CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN> <eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN> <87a6lihv7b.fsf@HIDDEN> <63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN> <CALDnm50W_=Y_zP7KLznqcqSx8KJp2-0u2NwpuEGzzAUzCNHvKQ@HIDDEN> <c95dea17-ca29-4dee-d53d-b5d46f7f2cf8@HIDDEN> <CALDnm53TD=FCf0davQC6q9esVxz687oBGN2LF=Egz3-kz6681Q@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <724345d2-a87b-064b-7ccf-b4ac2b66cc8d@HIDDEN> Date: Mon, 16 Aug 2021 17:26:44 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <CALDnm53TD=FCf0davQC6q9esVxz687oBGN2LF=Egz3-kz6681Q@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 47711 Cc: Lars Ingebrigtsen <larsi@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.6 (/) On 16.08.2021 14:37, João Távora wrote: > I am not a native English speaker, and maybe you don't understand > my language. Another way to explain what I am talking is to talk about > "bug reproduction". You say there's a bug in my patch, I am asking you > for a "bug reproduction recipe" as defined by most, if not all, the results > you get by searching "bug reproduction recipe" in the Google search engine. I hope you, or at least other here, can someday see and understand that asking to prove standard engineering practices from the first principles, time and time again in various discussions, is not a way to encourage good atmosphere or promote project participation. Are you really not imagine a buggy scenario coming from a combination of downstream uses of 'completion-score' property, different completion styles (some setting it, and some not), and a completion table that either uses global string values outright, or caches them for the duration of the current command?
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 14:20:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 10:20:55 2021
Received: from localhost ([127.0.0.1]:50696 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1mFdTv-00056W-My
for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 10:20:55 -0400
Received: from mail-wm1-f43.google.com ([209.85.128.43]:33449)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>)
id 1mFdTr-00056D-4m; Mon, 16 Aug 2021 10:20:51 -0400
Received: by mail-wm1-f43.google.com with SMTP id
a201-20020a1c7fd2000000b002e6d33447f9so86640wmd.0;
Mon, 16 Aug 2021 07:20:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:cc:subject:references:date:in-reply-to:message-id
:user-agent:mime-version:content-transfer-encoding;
bh=Q3zK+7/1DJLNkrgytux3CwuqtrXlG4P/nZ9MLv0C3rI=;
b=q4ZJFDL5eGfX2CRUdiokAWiTFfpZX6sdfZG1Bmol2X32LXvsGO4PgHunFx9OOCHMHS
hhubbq4S3qwKaRRg/VyUZt9Ne+B2SHSoye5ikVnpum0MYQ0tQ0Rh5/GKPyVnuupSOb6e
N1o/xtqh48zuYcZ7mNcaSDJnIR1wXIKl73LW5XqUkITVc83o1qg9g8Pn+F1roNEriOjn
NAaeQZGuTTRn/TkZWDUHWh2HWH+FFsIITfBezL9tR2HdvmDasEKjYPBZTUOtsE8cT2FQ
inb/y1q0XRpIY++lQiMbWL/yfnKVLvzTX/jQzP4RTRU9lI59T7XJy2pnLa3G6EFFSzfK
Cpfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
:message-id:user-agent:mime-version:content-transfer-encoding;
bh=Q3zK+7/1DJLNkrgytux3CwuqtrXlG4P/nZ9MLv0C3rI=;
b=orBlOMDWSYSokVJeNicx1REH0HCxNGdkDIKwnjgCsAO80QkVLWDg+jzGQIGJduIhcP
Wy2PXzj6DX3usChzpEIOfhic4SrAa5m0yD36s2RaPQFXnv1PQE43r5blMd0eTmthw3Z3
XTEQtcIeMoJ8aG9xoGY0a9iMY4kZiI5+CYBa0XnkL1cNOfABRLrfXgK0BfeeaHqdR8W/
W8FwJoXE9QZSVk7OmagF5BfetRBGA3hJvdHkHN3GSl8WYw0VHyTeI7aYwy61WH93MwA3
jCl8gSDKXP1rJDb4OGOjKKLhBvm3wSjA87cXlwhRx+XVmlheySzbZM1G3X7QYAtEh74F
gGnw==
X-Gm-Message-State: AOAM5326udjmBnS/FhmgIqVlf2bBHnFksidk0ipJAv/WMWJBkEqSyloS
lJ0MJuGRwlQ5c6v0QgiZkLRpVrJ0VgA=
X-Google-Smtp-Source: ABdhPJw5NZ8vcICaa27Insw1jRBGjjyzCTgnp2FYPaKhpFVm7go25OInr9NoQswLu0r8eb97wJ6smQ==
X-Received: by 2002:a7b:c005:: with SMTP id c5mr15424096wmb.59.1629123640952;
Mon, 16 Aug 2021 07:20:40 -0700 (PDT)
Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132])
by smtp.gmail.com with ESMTPSA id n3sm11414236wmi.0.2021.08.16.07.20.39
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 16 Aug 2021 07:20:40 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new
`completion-filter-completions` API and deferred highlighting
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN>
<9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN>
<CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN>
<8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN>
<87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN>
<87wnootec0.fsf@HIDDEN>
<5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN>
<CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN>
<0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN>
<CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN>
<eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN>
<87a6lihv7b.fsf@HIDDEN>
<63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN>
<CALDnm50W_=Y_zP7KLznqcqSx8KJp2-0u2NwpuEGzzAUzCNHvKQ@HIDDEN>
<c95dea17-ca29-4dee-d53d-b5d46f7f2cf8@HIDDEN>
<83k0kl8sxm.fsf@HIDDEN>
<f53a5330-fe7c-269c-ce34-9f2870e24e61@HIDDEN>
<83bl5x8r02.fsf@HIDDEN>
<77e98cdf-427d-ec7a-7a49-04dcd65d6a94@HIDDEN>
Date: Mon, 16 Aug 2021 15:20:36 +0100
In-Reply-To: <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@HIDDEN> (Dmitry Gutov's
message of "Mon, 16 Aug 2021 17:00:09 +0300")
Message-ID: <8735r9ii8b.fsf@HIDDEN>
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: 47711
Cc: Daniel Mendler <mail@HIDDEN>, monnier@HIDDEN,
48841 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, larsi@HIDDEN,
47711 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Dmitry Gutov <dgutov@HIDDEN> writes:
> On 16.08.2021 16:21, Eli Zaretskii wrote:
>
>>>> FWIW, I also don't understand how adding properties could cause a
>>>> memory leak. When a string is GCed, its properties get GCed as well,
>>>> all of them. Am I missing something?
>>>
>>> If you add string properties to all symbol names this memory will stay
>>> alive for much longer than necessary.
>> That's a very extreme example, something that I wouldn't expect a
>> Lisp
>> program to do, without removing the properties shortly thereafter.
>
> And that *will* happen with Joao's approach, as soon as some package
> implements a Lisp completion backend in a certain (legal) fashion.
There is no leak, not in the strong or weak sense. There is a constant
usage memory footprint proportional to the size of obarray, yes, but the
factor isn't huge. From the top of my head, I think it's about two
conses and a fp number for each sym. does anyone know how much that is
or can teach me how to measure? Thanks.
Anyway the current situation is constant copies of strings that put
pressure on the GC, as the benchmarks show.
Anyhoo, in the interest of placating this string property bogeyman, I've
prepared a version of my patch that is based on weak-keyed hash tables.
Slightly slower, but not much. Here are the usual benchmarks:
(defmacro heyhey ()
`(progn
,@(cl-loop repeat 300000
collect `(defun ,(intern (symbol-name (gensym "heyhey")))=
() 42))))
(setq completion-styles '(flex))
(heyhey)
(when nil
;; Press C-u C-x C-e C-m quickly to produce a sample
(benchmark-run (completing-read "" obarray))
=20=20=20=20
;; my patch with private string properties
(3.596972924 4 1.125298095999998)
(3.584963294 4 1.1266740010000014)
(3.4622216089999998 4 1.0924070069999985)
(3.565632813 4 1.1066678320000012)
(3.456130054 4 1.099950519)
(3.49538751 4 1.1085273779999998)
(3.4882531059999997 4 1.0928655200000001)
(3.526581152 4 1.0909935229999999)
(3.710919876 4 1.13883417)
(3.576690379 4 1.09514685)
=20=20=20=20
;; my patch with an no string properties (global weak hts)
;; Probably the extra gc sweeps are paranoid cleaning up of the
;; hash tables.
(3.981110008 7 1.6466288340000013)
(3.819598429 7 1.5200578379999996)
(3.823931386 7 1.5175787589999992)
(3.9161236720000003 7 1.6184865899999998)
(3.835148066 7 1.5686207249999988)
(3.791906221 7 1.5481051090000015)
(3.798378812 7 1.5164137029999996)
(4.049880173 7 1.7670989089999996)
(3.716469474 6 1.3442434509999996)
(3.422806969 6 1.3272816180000002)
=20=20=20=20
;; current master
(5.405534502 12 2.8778620629999994)
(5.038353216999999 12 2.553688440000002)
(4.94358915 12 2.4917956500000003)
(4.950710861 12 2.4638737510000013)
(5.0242796929999995 12 2.5226992029999984)
(5.020964648 12 2.495171900999999)
(4.914088866 12 2.4218276250000024)
(5.003779622 12 2.502260272000001)
(4.969347707 12 2.4814790469999988)
(5.376038238 11 2.565757513000001)
=20=20=20=20
;; didn't bother with daniel's patch as I've already shown it to be
;; about 10% slower than current master.
=20=20=20=20=20
)
The patch lives in the branch
scratch/icomplete-lazy-highlight-no-string-props. It's a bit more
complicated to follow, but not much if you understand hash tables. The
interface to icomplete.el is completely unchanged.
All in all, still a very good improvement over the current situation,
and I think I can make it faster.
(Though really do consider Eli's arguments the fastest approach)
>> And even that isn't a leak.
>> Note that we already put all kind of properties (although not text
>> properties) on symbols.
>
> Those do not, generally, change over time.
Neither does this one! At least in size, which is the thing that
matters. So in terms of "negative" consequences it's exactly
equivalent. Read the patch it will be obvious, I think.
Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 14:14:26 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 10:14:26 2021 Received: from localhost ([127.0.0.1]:50684 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFdNi-0004wh-Gd for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 10:14:26 -0400 Received: from mail-wr1-f41.google.com ([209.85.221.41]:44864) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1mFdNe-0004wO-PC; Mon, 16 Aug 2021 10:14:24 -0400 Received: by mail-wr1-f41.google.com with SMTP id x12so23837150wrr.11; Mon, 16 Aug 2021 07:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=QTEyYe7K0+Gh4xuATzEdO6A0e9+ClkEvPjO10gMLepE=; b=pkzpEeHI25hLjuuJLJ4Mk/ryWGYpIuM2XUWDH6CFOhexjCteO8vY/h7AWhmXUX9vyE st4KDl/j/BjNXMWJiFcJTxbGgoJmLkoP3+6icajMCWaXvJEmHf/L9tul7kd5dr/fn8hK 7sB+PgTre/qmDxAHOr5QGe4IbMg1EmZVOcI/VsDAUvzHHPvcsNEC/2aUVHkhGLShXXhO VAHoGJw7UOVQXvkibw8ZmNjI/maTXMK2rMW4xEMDdudS8vW17lsoF9EzsIIT1v8Zwx43 MB4d5yMf63BI5cb2vc+94w84lXeerZA5axKrZFh96CWkTMYJXTBRmhHBgPYvAFSdmkl4 3HCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=QTEyYe7K0+Gh4xuATzEdO6A0e9+ClkEvPjO10gMLepE=; b=YZGzH/yEG7l1rzdm/BZK5BIsm2WCFBQUk8akBRLAVEIIxGJ7fpcfo8KjNQ/sPH/i4X k/ML2mDdaW0+Tizv1Bc2aM2gz3C6sNkA4aUwWE9MyIhryBmebRZHrpEfpgaRGFhOtLLs B9Pjd4mnjdgin1++2skVxlZkZ1v7Yttyg3pg9JJz10SAqAWxWUNgYzMDJ7tm4kMr7f6E D/5Xh9aqiby16rJaq+IZoBhI4+2Zzdotm53lo2Q+YG8IxXyF59Xz30JD7ek7bU9+kUfj 0kDXHGum/Rhr123R+xnBxrMTyLJbyHU0Jx6vheTVCE1SiFBL49JulueJrZlmgSAmw+U4 tUSw== X-Gm-Message-State: AOAM532tnGB3vcPM0UUaH8sdgqUXiIcfkA43JiudjtjIWD3kYihm6W54 /W2f3Ed9ZLTl2NSQKRfQUyi2OpCKzCk= X-Google-Smtp-Source: ABdhPJyHIWnlJOPAlmmmuBrqk/1fXrEbXIf7CLGv3TGnr56xH3TKBFnAzn5F/LgUuR/cwHCpGjpF4Q== X-Received: by 2002:adf:db83:: with SMTP id u3mr19327638wri.363.1629123256841; Mon, 16 Aug 2021 07:14:16 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id h12sm10786701wmm.29.2021.08.16.07.14.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Aug 2021 07:14:16 -0700 (PDT) Subject: Re: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <31da8f43-02f7-e6dd-ab38-2160af138a4a@HIDDEN> <83tujp8vd9.fsf@HIDDEN> <769c0ee0-6d6f-6177-7929-1ac4ada30951@HIDDEN> <CALDnm539fmNj=TOTA7C25tXC6VOoE91ucWh5UubeUGC+meL6QA@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <a5a547e0-76c6-4404-148b-156176c78846@HIDDEN> Date: Mon, 16 Aug 2021 17:14:14 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <CALDnm539fmNj=TOTA7C25tXC6VOoE91ucWh5UubeUGC+meL6QA@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.6 (/) On 16.08.2021 16:41, João Távora wrote: > It is not documented anywhere > but that hasn't stopped anyone in the past it, indeed.Can you point to > place(s) where it is indeed used other than the flex machinery of > `minibuffer.el`? Thanks. Try either of these: https://github.com/rustify-emacs/fuz.el/blob/master/helm-fuz.el#L228 https://github.com/emacs-helm/helm/blob/master/helm-utils.el And I'm considering using it in company-sort-by-occurrence, to make sure that flex sorting is at least semi-honored there (or create a variation of that transformer). For that to happen, the possible score values and their meanings will need to be documented, though. The main scenario (and source of the completion-score property) I have in mind is not related to fido-mode or flex, but the users can always put flex into completion-styles by default, which affects company-capf.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 14:00:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 10:00:20 2021 Received: from localhost ([127.0.0.1]:50650 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFdA4-0004Zp-FZ for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 10:00:20 -0400 Received: from mail-wr1-f49.google.com ([209.85.221.49]:44878) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1mFdA2-0004ZZ-9o; Mon, 16 Aug 2021 10:00:19 -0400 Received: by mail-wr1-f49.google.com with SMTP id x12so23770232wrr.11; Mon, 16 Aug 2021 07:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=TRh/MX4EmZ66FHgFcppaqwOteymb1PkCFqcfL2chujM=; b=nc8WsBVrgLM7Wg59v/X/yVkCG2OfyyIRx/PpQksHaIid1Vq9sPXVm9PjXGiYRCYg1n xd21Ticr7+zaFBi3Ld7zN1osRzc9PQvAUCtyZtsUQf7ob+5YCwt7scHA9hi0Wu4pa+v1 18avkACqPKi1T1PU9zBgquM2nXDjDSHPhRqd499obNVYgujJVw3v7Ltkyn2iiqXdZJjI l1hsJrlLpN0KsEA9220uwl57J6w090jMy0/Pw4ZyIh27E6fd8090J+3ZbSa7nif0utAD uyAzY1eTH/eeQUri+8D3Kw1+XtyF8eGOsvOiefpt6bXROUFIpYhE2MBvpyX5agjhXGBO qgZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=TRh/MX4EmZ66FHgFcppaqwOteymb1PkCFqcfL2chujM=; b=E0CWZgdro8+W8iExYu5VNRkV+6zhi7TIwWX2o3sKZHvnF8PYYDjxstQ6Ls3FOMWFRP 6sb1RCc5CmZsDnEzNjuBLr3PvZpO+6dQiHwedzZ5cnu7Bad8VvoIVd8SOlTrESeCqF7K hFBqf1pdnjx8qXd4JMmENqlkjIsYTbdI3jrtxWuvvsw1Zp/OGv4xeKZKe5cJZgWuEuRX bzxZ6A9RWwH1LqwMRZJuyqsVy7/PBW/Wt1RU9vNLIeMhtmtDGavkBsWQZ/FNpR7WxQUy 57+/iYv+iiRk01XCux7M2dXwm74dlCp19Nstf3uQFWFzJk8znFS83VfcD0c+7Fi2o5/T yh0Q== X-Gm-Message-State: AOAM532b05QFkVCvIDZ7mul2xvv2j0JjbSqlJaJcMP1fMGgFJdMnxcee ArAQup7hthN2SzlasL7T2SzK78M959g= X-Google-Smtp-Source: ABdhPJwkiy4M0IJtYn95Q8/m/tfWfaY59QCabBgr3N1AqLNUuCiXa+Kfi5NmDtUY+Q6aUSP7Ubx89Q== X-Received: by 2002:adf:e551:: with SMTP id z17mr19265734wrm.40.1629122412318; Mon, 16 Aug 2021 07:00:12 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id a11sm11840585wrw.67.2021.08.16.07.00.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Aug 2021 07:00:10 -0700 (PDT) Subject: Re: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Eli Zaretskii <eliz@HIDDEN>, Daniel Mendler <mail@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN> <CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN> <eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN> <87a6lihv7b.fsf@HIDDEN> <63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN> <CALDnm50W_=Y_zP7KLznqcqSx8KJp2-0u2NwpuEGzzAUzCNHvKQ@HIDDEN> <c95dea17-ca29-4dee-d53d-b5d46f7f2cf8@HIDDEN> <83k0kl8sxm.fsf@HIDDEN> <f53a5330-fe7c-269c-ce34-9f2870e24e61@HIDDEN> <83bl5x8r02.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@HIDDEN> Date: Mon, 16 Aug 2021 17:00:09 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <83bl5x8r02.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 47711 Cc: larsi@HIDDEN, 47711 <at> debbugs.gnu.org, joaotavora@HIDDEN, 48841 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.6 (/) On 16.08.2021 16:21, Eli Zaretskii wrote: >>> FWIW, I also don't understand how adding properties could cause a >>> memory leak. When a string is GCed, its properties get GCed as well, >>> all of them. Am I missing something? >> >> If you add string properties to all symbol names this memory will stay >> alive for much longer than necessary. > > That's a very extreme example, something that I wouldn't expect a Lisp > program to do, without removing the properties shortly thereafter. And that *will* happen with Joao's approach, as soon as some package implements a Lisp completion backend in a certain (legal) fashion. Or using one of a few different fashions, actually. > And even that isn't a leak. > > Note that we already put all kind of properties (although not text > properties) on symbols. Those do not, generally, change over time.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 13:42:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 09:42:06 2021 Received: from localhost ([127.0.0.1]:49027 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFcsP-0001Z2-Qs for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 09:42:06 -0400 Received: from mail-pj1-f45.google.com ([209.85.216.45]:54162) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1mFcsL-0001Xp-Kg; Mon, 16 Aug 2021 09:42:03 -0400 Received: by mail-pj1-f45.google.com with SMTP id j1so26563685pjv.3; Mon, 16 Aug 2021 06:42:01 -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=JB2/qZP1S4rAp75M/+Afkq6jb97NXO4w7kLkGR+djWA=; b=Yu2KcewzKG/qJlN0SihwCY7y+vysP54IOuKDS1OtJoTmyJ5QbHu8KwmmqbcSLaBH0Y vIpZacV4rnocvYuWOwF2pKRd5iCSmpD03ZiqKxTsDHx1p6fU7aN451kt2gDmFPmwRr/Q w07ERlwnkDVHODlxIwGoiwmAjVmM//RwSf/l+zvy6uI00hFAohDdC5VVKSGx2oKyZU+s hW01rux4d+a3yO3x0iLOu7Fozq9QdHkPJYpdI485/2Gt7DbRrHnxaRuTNpIBcfvrXSvL L5mqdU+Jir5x1GIh7VF7RZmwCg/74esiRNUl6IhERyfW7I0wF9Mnne3+7dWmAPwkCDo+ zLqw== 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=JB2/qZP1S4rAp75M/+Afkq6jb97NXO4w7kLkGR+djWA=; b=DiRTqQ3LsdNDDqeCJkEjliIjHe+iliARb7CpltUjTVZ2kN4ZMrknQl6yhq8/WgmjRc ctpRAGEDhTYhxoyTn6mzD9R8l172xopveBjJQUEzleX+8mZZf8+3sT98gIK1ShZdv+0t c1e3kTOn2skcJ/Zxt8MqRRascJvVRo9RnUwD94qrdPI7ufpIp7ywAaE35JAGdKDtsXmY nCxOlEG9Mvqb+CAvPwFVFbT82Py8zgOgCvAM6fPCEamNRuGQ3eaywl86mRohKfsJ3ag+ lqi2bsVH6mnAD3t+rqFtF1a0y/ddLL9paCV+tMn27NQQWA3ac21Jt+L/Mt9/b5lbS3Bp y36w== X-Gm-Message-State: AOAM532XS5BhQp3s9lv+EinSmR3b2KHUuNXoR3o6aaSJ1ldhOQBwAAmF HlzUh3KZFmAT3r0jbZdis/tZBpU8iUHR3jaFu/0= X-Google-Smtp-Source: ABdhPJyePzhalqU929+kNUL5zmDJQwM7w+KfJDSztpA6kDzQ14RSTMdRFTJBW6cacsd8RedD0Smev4B6CV25zspzL34= X-Received: by 2002:a05:6a00:164d:b0:3e1:ab35:f3e4 with SMTP id m13-20020a056a00164d00b003e1ab35f3e4mr7474897pfc.42.1629121315603; Mon, 16 Aug 2021 06:41:55 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <31da8f43-02f7-e6dd-ab38-2160af138a4a@HIDDEN> <83tujp8vd9.fsf@HIDDEN> <769c0ee0-6d6f-6177-7929-1ac4ada30951@HIDDEN> In-Reply-To: <769c0ee0-6d6f-6177-7929-1ac4ada30951@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Mon, 16 Aug 2021 14:41:42 +0100 Message-ID: <CALDnm539fmNj=TOTA7C25tXC6VOoE91ucWh5UubeUGC+meL6QA@HIDDEN> Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Dmitry Gutov <dgutov@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Mon, Aug 16, 2021 at 2:38 PM Dmitry Gutov <dgutov@HIDDEN> wrote: > And speaking of "only private properties", the completion-score property > can be used by downstream code, with all the associated potential for > trouble. That's true. When I created it, I meant for it to be private, I think, but indeed did forget to mark it as such. It is not documented anywhere but that hasn't stopped anyone in the past it, indeed.Can you point to place(s) where it is indeed used other than the flex machinery of `minibuffer.el`? Thanks. Jo=C3=A3o T=C3=A1vora
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 13:38:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 09:38:30 2021 Received: from localhost ([127.0.0.1]:49008 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFcow-0001SP-7K for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 09:38:30 -0400 Received: from mail-wr1-f49.google.com ([209.85.221.49]:33578) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1mFcot-0001S9-SH; Mon, 16 Aug 2021 09:38:29 -0400 Received: by mail-wr1-f49.google.com with SMTP id r7so23782499wrs.0; Mon, 16 Aug 2021 06:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SqI0rHgABZha2WvRm9Y8w2oaSldHqcSN+3/YdatFStM=; b=P3asAjLAFMnMQalTG7bE/JtxvtRSVYQrO1SO8ibPC68FgWWLijkIgEzFGRkLUP2rWa tMbUCkJugsQ4qIarmfIjj1PWoLhlYNgvAYV9wNwTNdW6OVBRiSUycs4kUA0OFWlyPpXT sO0Pba0/zS2F9MfmmCRocbHU7XNfjnjMbkqC4ufJd330VYNR+u88qcW6LPHzjZh+5ENa 2IfCnRxfnk03f4x03x9BMqOEEQZvbt2AZr2Oca2waE45jvhQOFcYLzoCbRagZn673Oqh VDfv/grSzZxbQIh9SrLVtdegvQ868Ok/dwJ01iXR47wNaW+Ft6oLaSqqgaG61KgifutI +Peg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=SqI0rHgABZha2WvRm9Y8w2oaSldHqcSN+3/YdatFStM=; b=QB5A7bSEXh1zrowP8TpCIpUza44usXulBEwjSZxpOeybMnsKTY4i/b9TWfEhbMHpq/ G1bnDU/wTJcUFFNkFmMT3yd2gUORdRC6+u7fk/2rycZlBR9uw05aSrL5cGD4SWm4BqTr UZL7qJWMCzlnXTnmxZoj8siFD/lHfKgBNP1TJnbSCAEYJIhwK2fsl8rYE1ILnCuyibIg z5GIQ8FQyBztPNmJuCQWzyZJY66Ir522fy8gQuMsbxRyNB5U1u/LHVfU87VJHEO3dS6J yTOknHBmqxgK5mzakd7wj6kGYrxdHXIFUgH2QPCwSf1qGovjjKp5jezJs+4bSjOX5lrn 7a8A== X-Gm-Message-State: AOAM5315ZW6diOufYdM5GevSsitT+N4503MMIfsia+3GVa2/FAs0sa8/ YaeyMNmIJQY4+QusfTPoI3UU4DwA5tc= X-Google-Smtp-Source: ABdhPJzZKIM/o/bTUBPGReFn6m2jVcVa2wAgTqynCgT+U8mlc53Mkju/lc+p6FTVvnJZe0381ucgzA== X-Received: by 2002:a5d:534e:: with SMTP id t14mr18793923wrv.109.1629121101904; Mon, 16 Aug 2021 06:38:21 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id v17sm13960685wro.45.2021.08.16.06.38.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Aug 2021 06:38:20 -0700 (PDT) Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Eli Zaretskii <eliz@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <31da8f43-02f7-e6dd-ab38-2160af138a4a@HIDDEN> <83tujp8vd9.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <769c0ee0-6d6f-6177-7929-1ac4ada30951@HIDDEN> Date: Mon, 16 Aug 2021 16:38:19 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <83tujp8vd9.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 47711 Cc: mail@HIDDEN, 47711 <at> debbugs.gnu.org, monnier@HIDDEN, 48841 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.6 (/) On 16.08.2021 14:46, Eli Zaretskii wrote: >>> Text properties are stored separately from the string, so I don't >>> think adding properties can in general be referred to as "change". >> >> Are you thinking of C strings? > > No, about the implementation of Lisp strings in Emacs. I was talking about their behavior. >> Lisp strings carry text properties in addition to the array of >> characters. It doesn't really matter where in the memory the properties >> and the characters reside. > > Well, it does, at least in some situations. The string text is not > affected, and so the code which processes the string will not notice > that it has a property about which that code has no idea. Only > properties that are known to the processing code can affect it; > non-standard properties private to some other code will generally pass > unnoticed. I don't think anybody was suggesting that changing text properties changes the character codes inside the "C string" part of the Lisp string. >>> I'm not sure in the context of completion there's any reason to count >>> as "change" adding properties that don't affect display. >> >> For the context in question, whether the properties affect display is >> not particularly important. Properties affecting display just make it >> easier to notice that something's wrong. Bug involving other properties >> should be more difficult to investigate. > > Once again, if some code invents its private property, not used > anywhere else and not documented anywhere else, then putting such a > property on a string has very high chances of going unnoticed. I hope > this consideration helps this discussion, because saying that > properties change a string blurs the distinction between actually > changing the string text or its properties that affect many parts in > Emacs, and adding some obscure property that is not known to anyone. What muddies the water is arguing against a solid engineering principle with statements like "those mutations are not mutations". Yes, when the properties are prefixed, the damage is reduced. Even then, that increases the possibility of introducing bugs in the very code that sets those properties (like having different code paths where one branch sets them and another does not; forgetting to clear them in the other branch; having subsequent code use the property values set by some previous invocation of the code in question where it took another branch; not to mention the potential troubles with parallel execution, which is not a real concern these days, but we're designing for years ahead, and someday it can be). Memory leaks, too. Our completion pipeline has multiple interchangeable/pluggable parts, so we have to be on the lookout even for problems which do not reproduce with stock Emacs, and that requires solid abstractions. And speaking of "only private properties", the completion-score property can be used by downstream code, with all the associated potential for trouble.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 13:21:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 09:21:37 2021 Received: from localhost ([127.0.0.1]:48985 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFcYX-0007Ll-BU for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 09:21:37 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59452) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1mFcYS-0007LS-Lp; Mon, 16 Aug 2021 09:21:32 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47768) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mFcYM-00022e-Bl; Mon, 16 Aug 2021 09:21:22 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3998 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mFcYL-0004j1-Nk; Mon, 16 Aug 2021 09:21:22 -0400 Date: Mon, 16 Aug 2021 16:21:17 +0300 Message-Id: <83bl5x8r02.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Daniel Mendler <mail@HIDDEN> In-Reply-To: <f53a5330-fe7c-269c-ce34-9f2870e24e61@HIDDEN> (message from Daniel Mendler on Mon, 16 Aug 2021 14:49:45 +0200) Subject: Re: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN> <CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN> <eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN> <87a6lihv7b.fsf@HIDDEN> <63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN> <CALDnm50W_=Y_zP7KLznqcqSx8KJp2-0u2NwpuEGzzAUzCNHvKQ@HIDDEN> <c95dea17-ca29-4dee-d53d-b5d46f7f2cf8@HIDDEN> <83k0kl8sxm.fsf@HIDDEN> <f53a5330-fe7c-269c-ce34-9f2870e24e61@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: monnier@HIDDEN, 48841 <at> debbugs.gnu.org, dgutov@HIDDEN, joaotavora@HIDDEN, larsi@HIDDEN, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > Cc: joaotavora@HIDDEN, 48841 <at> debbugs.gnu.org, dgutov@HIDDEN, > larsi@HIDDEN, monnier@HIDDEN, 47711 <at> debbugs.gnu.org > From: Daniel Mendler <mail@HIDDEN> > Date: Mon, 16 Aug 2021 14:49:45 +0200 > > On 8/16/21 2:39 PM, Eli Zaretskii wrote: > >> João, I am giving hard examples here. What is not an example about > >> "memory leak" or making debugging output verbose thanks to the attached > >> string properties? > > > > FWIW, I also don't understand how adding properties could cause a > > memory leak. When a string is GCed, its properties get GCed as well, > > all of them. Am I missing something? > > If you add string properties to all symbol names this memory will stay > alive for much longer than necessary. That's a very extreme example, something that I wouldn't expect a Lisp program to do, without removing the properties shortly thereafter. And even that isn't a leak. Note that we already put all kind of properties (although not text properties) on symbols. > > As to more difficult debugging, I think adding a couple of properties > > that have simple structure will not impair debugging too much. > > Strings with many properties are not uncommon in Emacs, so we already > > have to deal with that. > > I disagree with that. We are talking about adding string properties to > every symbol name. This is a global side effect and different from > adding string properties to a set of isolated string in a controlled > manner. I also don't understand why one would even want to take any > chances here given that the feature can be implemented in a way which > avoids this global side effect entirely as my patch shows. I understand your aversion from such global effects, but I was talking specifically about the debugging difficulties. > > I would indeed suggest both to make sure there's no performance > > regressions, and would like to see some data similar to what João > > presented, which backs up your assessments about your proposal being > > faster. Since performance is the main motivation for these changes, I > > think it's important for us to be on the same page wrt facts related > > to performance, before we make the decision how to proceed. > > I will prepare some benchmarks. Thank you.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 12:59:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 08:59:10 2021 Received: from localhost ([127.0.0.1]:48923 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFcCn-0002Pk-QH for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 08:59:10 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54842) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1mFcCi-0002Ok-Hy; Mon, 16 Aug 2021 08:59:04 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47060) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mFcCc-0004HU-LT; Mon, 16 Aug 2021 08:58:54 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2559 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mFcCc-0006ac-7q; Mon, 16 Aug 2021 08:58:54 -0400 Date: Mon, 16 Aug 2021 15:58:47 +0300 Message-Id: <83h7fp8s1k.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Daniel Mendler <mail@HIDDEN> In-Reply-To: <e2427908-17c5-ad18-a50a-2f2ebb61982c@HIDDEN> (message from Daniel Mendler on Mon, 16 Aug 2021 11:42:22 +0200) Subject: Re: bug#48841: [PATCH] Add new `completion-filter-completions` API and deferred highlighting References: <f94541d3-5f93-9a23-8256-3bbc453f127a@HIDDEN> <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <837dgrdrec.fsf@HIDDEN> <aff2bd3a-ea3e-1ac6-cf0d-2785c6591c84@HIDDEN> <83mtpkbky3.fsf@HIDDEN> <e2427908-17c5-ad18-a50a-2f2ebb61982c@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org, joaotavora@HIDDEN, monnier@HIDDEN, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: joaotavora@HIDDEN, dgutov@HIDDEN, monnier@HIDDEN, > 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org > From: Daniel Mendler <mail@HIDDEN> > Date: Mon, 16 Aug 2021 11:42:22 +0200 > > >> To address your technical comment - this variable is precisely what one > >> of the technical difficulties mentioned in my other mail is about. The > >> question is how we can retain backward compatibility of the completion > >> style 'all' functions, e.g., 'completion-basic-all-completions', while > >> still allowing the function to return the newly introduced alist format > >> with more data, which enables 'completion-filter-completions' to perform > >> the efficient deferred highlighting. > > > > I understand, but given that we provide this for other packages, it > > shouldn't be an internal variable. > > No, we explicitly don't provide this variable for other packages. It is > explicitly only meant to be used for the existing completion styles > emacs21, emacs22, basic, substring, partial-completion, initials and > flex to opt-in in a backward-compatible/calling convention preserving > way to the alist return format. The idea is to keep the existing APIs > fully backward compatible. > > Other packages should select the format returned from the completion > styles differently. They should return the alist format on Emacs 28 or > if the API 'completion-filter-completions' API is present. In the not so > near future external packages which support only Emacs 28 and upwards > will then only return the alist format and don't have to perform any > detection anymore. What if some package outside minibuffer.el will want to control the format of the returned value, for some reason, like support for old Emacs versions? are we going to disallow that? > >> The new API 'completion-filter-completions' will substitute the existing > >> API 'completion-all-completions'. > > > > That's your hope, and I understand. But we as a project didn't yet > > decide to deprecate the original APIs, so talking about superseding is > > premature. > > It is not the hope - it is the explicit goal. The API has been designed > to replace the existing API 'completion-all-completions'. A goal is not a fact. Until that goal is reached, we cannot in good faith tell people an API is superseded. > We can of > course tone this down. However I, as a package author, would appreciate > if Emacs tells me when a newer API aims to replace another API and when > the documentation is explicit about it. That's understood, and when we make that decision, we will of course announce it. But we didn't do so yet, and this discussion is not even about that decision. It could be, for example, that both APIs will live side by side until we decide whether to deprecate the old one. > Of course if you decide to have > the doc strings written in a different tone, I will adapt my patch > accordingly. Here I am just explaining why I chose the word "superseded" > instead of a more neutral word. I understand your motivation, I'm just saying that we cannot announce deprecation before we actually decide to deprecate. > > But the name says "filter completions". Which would mean you take a > > list of completions and filter out some of them. A completion table > > is much more general object than a list of strings. Thus, I think > > using "filter" here is sub-optimal. > > Okay, you are right about this. But I think even if the name > 'completion-filter-completions' is not 100% precise it still conveys > what the API is about. 'completion-completions-alist' or > 'completion-all-completions-as-alist' are valid names of course, but I > dislike them for their verbosity. Already 'completion-all-completions' > is quite verbose. A strong argument to use this long name is that the > completion style functions are still called > 'completion-basic-all-completions' etc. But if we accept that the new > API 'completion-filter-completions' will actually supersede the existing > API 'completion-all-completions' it makes sense to use a name which will > not hurt our eyes in the long run. However this is of course just a > personal preference of mine. I don't want to spent much time with name > bikeshedding discussions. If you decide on a name, I will adapt my patch > accordingly. Emacs is frequently accused in having names that are hard to discover. The only time where we can improve that is when a symbol is introduced, because later it's impossible for compatibility reasons. So I'd like to come up with a good name before we install the changes. That said, I'll let others chime in and agree or disagree with the name you've chosen. Thanks.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 12:49:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 08:49:56 2021 Received: from localhost ([127.0.0.1]:48897 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFc3v-0002Ay-VF for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 08:49:56 -0400 Received: from server.qxqx.de ([178.63.65.180]:59823 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1mFc3u-0002Af-FE; Mon, 16 Aug 2021 08:49:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=kZrT7LuVRK9XGgsyWGpuxLP8FMvP7eeoAoRJa1adfP8=; b=BH6TKB+fVaN/xvMTztdySZbl+R ICbPRP+GFV1yS4R2oqMVSOGN5kRp6rCsBT2bq3J/+7c9HG0cOZoCV5nGxnAbDenMkZDpZhnpX36Vg axzIfoOp3ByTbm/Tw1zZrSyLjmDosJbk1jC0bANXga0bAhGgMq341ZOM0He1EeQvUBmc=; Subject: Re: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Eli Zaretskii <eliz@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN> <CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN> <eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN> <87a6lihv7b.fsf@HIDDEN> <63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN> <CALDnm50W_=Y_zP7KLznqcqSx8KJp2-0u2NwpuEGzzAUzCNHvKQ@HIDDEN> <c95dea17-ca29-4dee-d53d-b5d46f7f2cf8@HIDDEN> <83k0kl8sxm.fsf@HIDDEN> From: Daniel Mendler <mail@HIDDEN> Message-ID: <f53a5330-fe7c-269c-ce34-9f2870e24e61@HIDDEN> Date: Mon, 16 Aug 2021 14:49:45 +0200 MIME-Version: 1.0 In-Reply-To: <83k0kl8sxm.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: monnier@HIDDEN, 48841 <at> debbugs.gnu.org, dgutov@HIDDEN, joaotavora@HIDDEN, larsi@HIDDEN, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) On 8/16/21 2:39 PM, Eli Zaretskii wrote: >> João, I am giving hard examples here. What is not an example about >> "memory leak" or making debugging output verbose thanks to the attached >> string properties? > > FWIW, I also don't understand how adding properties could cause a > memory leak. When a string is GCed, its properties get GCed as well, > all of them. Am I missing something? If you add string properties to all symbol names this memory will stay alive for much longer than necessary. It is not a memory leak in the strongest sense. The memory is still reachable, but there is still no need to keep the string properties allocated. This is comparable to memory leaks in other GCed languages where memory is also kept alive for longer than necessary. > As to more difficult debugging, I think adding a couple of properties > that have simple structure will not impair debugging too much. > Strings with many properties are not uncommon in Emacs, so we already > have to deal with that. I disagree with that. We are talking about adding string properties to every symbol name. This is a global side effect and different from adding string properties to a set of isolated string in a controlled manner. I also don't understand why one would even want to take any chances here given that the feature can be implemented in a way which avoids this global side effect entirely as my patch shows. >> As I said, I will ensure that my API does not introduce performance >> regressions. And since my new API performs strictly less work than your >> proposal it will necessarily be faster if you consider only the >> filtering, which is what matters for incrementally updating UIs. > > I would indeed suggest both to make sure there's no performance > regressions, and would like to see some data similar to what João > presented, which backs up your assessments about your proposal being > faster. Since performance is the main motivation for these changes, I > think it's important for us to be on the same page wrt facts related > to performance, before we make the decision how to proceed. I will prepare some benchmarks. Daniel
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 12:44:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 08:44:24 2021 Received: from localhost ([127.0.0.1]:48885 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFbyV-0008Ku-Pr for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 08:44:24 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51464) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1mFbyL-0008KR-Sd; Mon, 16 Aug 2021 08:44:14 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46722) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mFbyG-0001uW-Ct; Mon, 16 Aug 2021 08:44:04 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1648 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mFbyG-0000ve-09; Mon, 16 Aug 2021 08:44:04 -0400 Date: Mon, 16 Aug 2021 15:43:59 +0300 Message-Id: <83im058sq8.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Daniel Mendler <mail@HIDDEN> In-Reply-To: <d10119c3-aac5-89c4-e6a0-f6655e53a5a2@HIDDEN> (message from Daniel Mendler on Mon, 16 Aug 2021 14:05:54 +0200) Subject: Re: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN> <CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN> <eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN> <87a6lihv7b.fsf@HIDDEN> <63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN> <CALDnm50W_=Y_zP7KLznqcqSx8KJp2-0u2NwpuEGzzAUzCNHvKQ@HIDDEN> <c95dea17-ca29-4dee-d53d-b5d46f7f2cf8@HIDDEN> <CALDnm53TD=FCf0davQC6q9esVxz687oBGN2LF=Egz3-kz6681Q@HIDDEN> <d10119c3-aac5-89c4-e6a0-f6655e53a5a2@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: monnier@HIDDEN, 48841 <at> debbugs.gnu.org, dgutov@HIDDEN, joaotavora@HIDDEN, larsi@HIDDEN, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: Dmitry Gutov <dgutov@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>, > 47711 <at> debbugs.gnu.org, 48841 <at> debbugs.gnu.org, > Stefan Monnier <monnier@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> > From: Daniel Mendler <mail@HIDDEN> > Date: Mon, 16 Aug 2021 14:05:54 +0200 > > João, the discussion is clearly not progressing. I propose that we both > take a step back and let the Emacs maintainers, who participated in this > discussion, decide on how to proceed. It seems to me that all arguments > and data has been presented and there is no need for further > reiterations in more and more colorful language. As I wrote elsewhere, I'd like to see the performance aspects of this to be presented from both sides, and agreed upon. I don't think we can make the decision before we have performance data we all agree about. The other pros and cons are all of qualitative nature, and involve intuition, personal experience, and personal preferences, so each one will have their own balance. But performance is both basic and qualitative, and we should have the facts and agree on them.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 12:39:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 08:39:56 2021 Received: from localhost ([127.0.0.1]:48871 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFbuF-0008DK-On for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 08:39:56 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50686) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1mFbu8-0008Cs-5T; Mon, 16 Aug 2021 08:39:50 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46626) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mFbu1-00014t-Dy; Mon, 16 Aug 2021 08:39:41 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1381 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mFbu0-0000Ui-Sm; Mon, 16 Aug 2021 08:39:41 -0400 Date: Mon, 16 Aug 2021 15:39:33 +0300 Message-Id: <83k0kl8sxm.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Daniel Mendler <mail@HIDDEN> In-Reply-To: <c95dea17-ca29-4dee-d53d-b5d46f7f2cf8@HIDDEN> (message from Daniel Mendler on Mon, 16 Aug 2021 12:52:58 +0200) Subject: Re: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN> <CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN> <eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN> <87a6lihv7b.fsf@HIDDEN> <63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN> <CALDnm50W_=Y_zP7KLznqcqSx8KJp2-0u2NwpuEGzzAUzCNHvKQ@HIDDEN> <c95dea17-ca29-4dee-d53d-b5d46f7f2cf8@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: monnier@HIDDEN, 48841 <at> debbugs.gnu.org, dgutov@HIDDEN, joaotavora@HIDDEN, larsi@HIDDEN, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: Dmitry Gutov <dgutov@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>, > 47711 <at> debbugs.gnu.org, 48841 <at> debbugs.gnu.org, > Stefan Monnier <monnier@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> > From: Daniel Mendler <mail@HIDDEN> > Date: Mon, 16 Aug 2021 12:52:58 +0200 > > On 8/16/21 12:15 PM, João Távora wrote: > > On Mon, Aug 16, 2021 at 10:09 AM Daniel Mendler <mail@HIDDEN> wrote: > > > >> 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...". > > João, I am giving hard examples here. What is not an example about > "memory leak" or making debugging output verbose thanks to the attached > string properties? FWIW, I also don't understand how adding properties could cause a memory leak. When a string is GCed, its properties get GCed as well, all of them. Am I missing something? As to more difficult debugging, I think adding a couple of properties that have simple structure will not impair debugging too much. Strings with many properties are not uncommon in Emacs, so we already have to deal with that. > As I said, I will ensure that my API does not introduce performance > regressions. And since my new API performs strictly less work than your > proposal it will necessarily be faster if you consider only the > filtering, which is what matters for incrementally updating UIs. I would indeed suggest both to make sure there's no performance regressions, and would like to see some data similar to what João presented, which backs up your assessments about your proposal being faster. Since performance is the main motivation for these changes, I think it's important for us to be on the same page wrt facts related to performance, before we make the decision how to proceed. Thanks.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 12:19:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 08:19:29 2021 Received: from localhost ([127.0.0.1]:48815 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFbaT-0005RO-D9 for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 08:19:29 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44826) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1mFbaS-0005R8-MG; Mon, 16 Aug 2021 08:19:29 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46066) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mFbaM-0002dP-36; Mon, 16 Aug 2021 08:19:22 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4103 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mFbaL-00074k-Mw; Mon, 16 Aug 2021 08:19:22 -0400 Date: Mon, 16 Aug 2021 15:19:17 +0300 Message-Id: <83mtph8tve.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> In-Reply-To: <CALDnm5306P+FrKW12uRcFcLC0K=MCse_asGfAVrnKgVnvZNoSQ@HIDDEN> (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Mon, 16 Aug 2021 13:02:04 +0100) Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <83h7fsbitl.fsf@HIDDEN> <75ce4b68-240f-2f0e-3953-c1f74962c3cd@HIDDEN> <83pmud8uwi.fsf@HIDDEN> <CALDnm5306P+FrKW12uRcFcLC0K=MCse_asGfAVrnKgVnvZNoSQ@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: mail@HIDDEN, 47711 <at> debbugs.gnu.org, monnier@HIDDEN, 48841 <at> debbugs.gnu.org, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: João Távora <joaotavora@HIDDEN> > Date: Mon, 16 Aug 2021 13:02:04 +0100 > Cc: Daniel Mendler <mail@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN>, > Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org > > On Mon, Aug 16, 2021 at 12:57 PM Eli Zaretskii <eliz@HIDDEN> wrote: > > > I was talking about the infrastructure that produces the completion > > candidates, not about the application that uses them. My point is > > that your approach requires the applications using the candidates to > > copy them, whereas previously they could use them without copying. > > If it helps, I think that that is true of all alternatives presented > so far Yes, I know. I was comparing the proposed alternatives to what we have now, and specifically because Dmitry mentioned this aspect.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 12:18:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 08:18:16 2021 Received: from localhost ([127.0.0.1]:48808 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFbZI-0005Ou-BT for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 08:18:16 -0400 Received: from mail-pj1-f48.google.com ([209.85.216.48]:46021) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1mFbZG-0005Oc-4H; Mon, 16 Aug 2021 08:18:15 -0400 Received: by mail-pj1-f48.google.com with SMTP id m24-20020a17090a7f98b0290178b1a81700so27283048pjl.4; Mon, 16 Aug 2021 05:18:14 -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=vG3PtNb8GFe1kTTcPbNe6NfvS5vc+wIhZ/FWyFFtPIA=; b=aSH3HPLhgEj06AokK9atlnXYm/oOd2CjowEF2KvMYq4OxnlLlxnOcYegTgcjSZrUir /Gnqd2IF3JkQsi/P7PDf9sWksjDdJqDcCCOlCJwSJz6tfBtT42fLgRGpo8Bie73KkyEY 3sMa17mBF5tUc4naAeibyvCC4I3vNffSI6++HNQ06W0LODRwswVIMbL/rNCRtMBs4QiP baMmFVNDsnxePgBeGwjgxaerbmFFBAMcb9rqwdLxml5NldIlSBq+0XMr7zorhL6OVPnM CwwKcY4cmbR5IHmKB0AVp2KVJ3ijYxFih/1F43g9ExDOg90vYdFXBYhMNmAr8mZZHUaz ZJBg== 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=vG3PtNb8GFe1kTTcPbNe6NfvS5vc+wIhZ/FWyFFtPIA=; b=Qom4B1JVd2ZKFouUGQ25Szzp34t2JSAqbsBlhonSin5uEhbqc1uyLEuaiu1uiyTGQk sN4Oa+ujRE6TlkJbeChFQEEcarV2LlcTHVkRQ8oIUgh3eH/Sc+a7l5UnBXcAHd3cbLqN hoM25UtCRLfVHM5Lpb8TC7kH9G0DMLh/fCZJf3YLaqUm77Wb+NQ7Ikd88zGsnOZHKnv0 tlcz2WZgiqa06Pbp4DHpPbXpk+lAdmYi64078Vt4JITHGNohBjLQHWJ+vMRwalfWVM7H Cwy8hCHbBsTnf7KKBq7NQAgDWAo6PdLI8rqP4I7BPQn0GvjtrQN+VOUNp7S8p2A77m4G ELJQ== X-Gm-Message-State: AOAM530uHOE8XO7G+R8t3gJtzl2uHZn12DE1K2XH0w6nt4F7tKoRPqi0 +O00AgqYEN4BLhgsPbqsZUPT5S+rqrlkfgWlrfw= X-Google-Smtp-Source: ABdhPJywkcSc4K1vtg2RIk7Im7oLva1pYFsW7yZevcSSbs8sdCdSVuP1J3zmP4M1vGwMvMjrDIjDcCGF+zSjKJ/4/lQ= X-Received: by 2002:a17:90a:3849:: with SMTP id l9mr6083033pjf.7.1629116288241; Mon, 16 Aug 2021 05:18:08 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN> <CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN> <eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN> <87a6lihv7b.fsf@HIDDEN> <63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN> <CALDnm50W_=Y_zP7KLznqcqSx8KJp2-0u2NwpuEGzzAUzCNHvKQ@HIDDEN> <c95dea17-ca29-4dee-d53d-b5d46f7f2cf8@HIDDEN> <CALDnm53TD=FCf0davQC6q9esVxz687oBGN2LF=Egz3-kz6681Q@HIDDEN> <d10119c3-aac5-89c4-e6a0-f6655e53a5a2@HIDDEN> In-Reply-To: <d10119c3-aac5-89c4-e6a0-f6655e53a5a2@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Mon, 16 Aug 2021 13:17:56 +0100 Message-ID: <CALDnm51UMr2ZRPbuNtKZnMPmWPRcOgNNFs1-PA=29_1s=y9cDw@HIDDEN> Subject: Re: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Daniel Mendler <mail@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > Jo=C3=A3o, please feel free to also present your closing arguments here. Sorry, I don't "close" arguments like this. I hope you can provide: * the fixes to the regression identified * the benchmarks you say you have * the patches to icomplete.el that show how it uses your new API * the demonstrations of the bugs you accuse my patch to suffer from Thanks. On Mon, Aug 16, 2021 at 1:05 PM Daniel Mendler <mail@HIDDEN> wro= te: > > Jo=C3=A3o, the discussion is clearly not progressing. I propose that we b= oth > take a step back and let the Emacs maintainers, who participated in this > discussion, decide on how to proceed. It seems to me that all arguments > and data has been presented and there is no need for further > reiterations in more and more colorful language. I would also like to > point out that implying that I don't understand your language is > borderline acceptable. I understand the discussion very well, but I > don't understand why you are using these unfair and invalid means of > discussion. > > For example there could be these decision outcomes: > > 1. The information presented up to now does not allow the maintainers to > make a decision. For example the maintainers may ask for further > clarification from you, Jo=C3=A3o, or they may ask for benchmarks from me= or > a prove that my patch does not lead to performance regressions. > > 2. The maintainers decide that no patch should be merged. > > 2. The maintainers decide that your patch will be merged. I will accept > this decision. > > 3. The maintainers decide that my patch will be merged. You will accept > this decision. > > 4. The maintainers decide that both patches will be merged such that > both approaches will be supported. We both will accept this decision. > > I want to summarize the situation in the following: > > The patches in question address a performance issue in the current > completion machinery which is caused by over-eager copying of the > completion candidate strings and over-eager application of the > highlighting to all candidate strings. For incrementally updating UIs it > would be sufficient to only copy and highlight the strings which are > actually going to be displayed. > > My patch takes the approach to expose the existing two-step completion > process, which consists of filtering and highlighting. By returning the > filtered completion strings and a highlighting function this two-step > process is decomposed and the caller of the API has the ability to call > the highlighting function on only the displayed subset of completion > candidates. I argue that exposing the filtering and highlighting > procession steps is the logical and natural conclusion of the existing > machinery. > > My patch is fully backward compatible and aims to not introduce any > regressions (also no performance regressions) to the existing API. > Furthermore my patch adheres to the current guarantees given by the > existing 'completion-all-completions' API. The completion strings > provided by the completion backend are not mutated in any way, no string > properties are attached. Since the API 'completion-filter-completions' > proposed in my patch does the minimal amount of work necessary (only > filtering), if no highlighting is requested, I argue that the new API is > the most efficient possible API, given the current constraints. > > Furthermore since I am introducing a new API, outstanding issues can be > solved which could not be solved until now given the constraints of the > existing 'completion-all-completions' API. In particular the new API > 'completion-filter-completions' API returns additional data like the end > position of the completion boundaries. Until now the end position was > not made available and 'completion-base-position' just used the length > of the input to guess the end position. In a strict sense this guess is > incorrect and there is a FIXME in minibuffer.el, mentioning this issue. > > The downside of my patch is that it is a large patch. While it adds only > 196 lines of code, which is not much and expected given that it only > reshuffles the existing machinery, it is still a large patch in total. > > On the other side, Jo=C3=A3o's patch avoids the complication of adhering = to > the existing guarantees of the APIs and takes the liberty of attaching > "private" string properties to the completion strings of the completion > table backend. I argue that attaching the string properties is a > violation of the guarantees of the existing API and violates the > expectations of the existing many completion tables. One very severe > scenario is when obarray is used as completion table, since then each > symbol name gets a private property attached. I argue that such global > side effects like attaching string properties to all completion > candidates should better be avoided. There is the issue that the > attached string properties are a potential memory leak. When dumping the > string representation of symbol names, the symbols will have additional > properties which will complicate the debugging experience. Furthermore > it will lead to confusion since the global side effect during completion > will suddenly have an influence of symbols which don't have to do > anything with completion. The big advantage of Jo=C3=A3o's patch is that = it > is very limited in scope and very simple. However I argue that this > simplicity is hard-won and we will regret this approach later due to the > global side effects. > > Therefore I conclude that the two-step process proposed in my patch, > which does not introduce problematic global side effects is the better > approach forward. Furthermore a new API is needed such that more > completion data can be returned, e.g., the completion end position. One > could even return additional match data in the future given that the new > API 'completion-filter-completions' is extensible thanks to its alist > return value. > > Jo=C3=A3o, please feel free to also present your closing arguments here. > > Daniel --=20 Jo=C3=A3o T=C3=A1vora
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 12:08:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 08:08:42 2021 Received: from localhost ([127.0.0.1]:48737 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFbQ2-0002sA-42 for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 08:08:42 -0400 Received: from server.qxqx.de ([178.63.65.180]:45343 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1mFbQ0-0002rn-Ts; Mon, 16 Aug 2021 08:08:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=R55hjCfJUe6SX5kZqUMWgP5U5R+Jn+Et7+fCwvgRegg=; b=xUpr01qQu0n2wvaRzOXBFioD6x WZOQKMXScwZKkhGaryKipNAaoHQY3Z34jY274hOKXT/Dg2nHk+3ngR56N0OHjYcFNE2TObaa+jnWo Fb5gH57N8WwLJjlZjMKWTuy9DJhSIxsAdn8YPaNZv0ICxhLSbprk+ZDPMKloA7Z7te/w=; Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Eli Zaretskii <eliz@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <83h7fsbitl.fsf@HIDDEN> <75ce4b68-240f-2f0e-3953-c1f74962c3cd@HIDDEN> <83pmud8uwi.fsf@HIDDEN> From: Daniel Mendler <mail@HIDDEN> Message-ID: <003d6015-8594-7623-16d9-167991a1ac16@HIDDEN> Date: Mon, 16 Aug 2021 14:08:33 +0200 MIME-Version: 1.0 In-Reply-To: <83pmud8uwi.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org, joaotavora@HIDDEN, monnier@HIDDEN, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) On 8/16/21 1:57 PM, Eli Zaretskii wrote: > I was talking about the infrastructure that produces the completion > candidates, not about the application that uses them. My point is > that your approach requires the applications using the candidates to > copy them, whereas previously they could use them without copying. Okay, I understand. Yes, in my patch the strings returned by 'completion-filter-completions' must not be mutated by the API consumer directly. This should be documented clearly, but it is not unexpected. For example the API 'all-completions' which one can use to obtain the strings from a completion table also requires the caller to not mutate the returned strings. Daniel
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 12:06:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 08:06:06 2021 Received: from localhost ([127.0.0.1]:48722 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFbNV-0002mS-Tj for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 08:06:06 -0400 Received: from server.qxqx.de ([178.63.65.180]:59331 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1mFbNT-0002lo-8G; Mon, 16 Aug 2021 08:06:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Rqm3CwKvaY3irAWRkNIM3r7NyHLM9cGe9M3IfOA8XxM=; b=ktVOSLa8U2WRAXCOadinumlvJp FRn5yd3JtduX91ZpaoVdXSgrjRtx+cemkLkO/k7UphFRNq9cBPahXSsImb8uapcbODMEXeIhBRnGH oh+2hJ/SFUU7usXD9ubtxJrfKs4zQGlYeBC5I+w3mut2ZG26VRhpJIwkn95aORXMAX2s=; Subject: Re: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN> <CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN> <eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN> <87a6lihv7b.fsf@HIDDEN> <63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN> <CALDnm50W_=Y_zP7KLznqcqSx8KJp2-0u2NwpuEGzzAUzCNHvKQ@HIDDEN> <c95dea17-ca29-4dee-d53d-b5d46f7f2cf8@HIDDEN> <CALDnm53TD=FCf0davQC6q9esVxz687oBGN2LF=Egz3-kz6681Q@HIDDEN> From: Daniel Mendler <mail@HIDDEN> Message-ID: <d10119c3-aac5-89c4-e6a0-f6655e53a5a2@HIDDEN> Date: Mon, 16 Aug 2021 14:05:54 +0200 MIME-Version: 1.0 In-Reply-To: <CALDnm53TD=FCf0davQC6q9esVxz687oBGN2LF=Egz3-kz6681Q@HIDDEN> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) João, the discussion is clearly not progressing. I propose that we both take a step back and let the Emacs maintainers, who participated in this discussion, decide on how to proceed. It seems to me that all arguments and data has been presented and there is no need for further reiterations in more and more colorful language. I would also like to point out that implying that I don't understand your language is borderline acceptable. I understand the discussion very well, but I don't understand why you are using these unfair and invalid means of discussion. For example there could be these decision outcomes: 1. The information presented up to now does not allow the maintainers to make a decision. For example the maintainers may ask for further clarification from you, João, or they may ask for benchmarks from me or a prove that my patch does not lead to performance regressions. 2. The maintainers decide that no patch should be merged. 2. The maintainers decide that your patch will be merged. I will accept this decision. 3. The maintainers decide that my patch will be merged. You will accept this decision. 4. The maintainers decide that both patches will be merged such that both approaches will be supported. We both will accept this decision. I want to summarize the situation in the following: The patches in question address a performance issue in the current completion machinery which is caused by over-eager copying of the completion candidate strings and over-eager application of the highlighting to all candidate strings. For incrementally updating UIs it would be sufficient to only copy and highlight the strings which are actually going to be displayed. My patch takes the approach to expose the existing two-step completion process, which consists of filtering and highlighting. By returning the filtered completion strings and a highlighting function this two-step process is decomposed and the caller of the API has the ability to call the highlighting function on only the displayed subset of completion candidates. I argue that exposing the filtering and highlighting procession steps is the logical and natural conclusion of the existing machinery. My patch is fully backward compatible and aims to not introduce any regressions (also no performance regressions) to the existing API. Furthermore my patch adheres to the current guarantees given by the existing 'completion-all-completions' API. The completion strings provided by the completion backend are not mutated in any way, no string properties are attached. Since the API 'completion-filter-completions' proposed in my patch does the minimal amount of work necessary (only filtering), if no highlighting is requested, I argue that the new API is the most efficient possible API, given the current constraints. Furthermore since I am introducing a new API, outstanding issues can be solved which could not be solved until now given the constraints of the existing 'completion-all-completions' API. In particular the new API 'completion-filter-completions' API returns additional data like the end position of the completion boundaries. Until now the end position was not made available and 'completion-base-position' just used the length of the input to guess the end position. In a strict sense this guess is incorrect and there is a FIXME in minibuffer.el, mentioning this issue. The downside of my patch is that it is a large patch. While it adds only 196 lines of code, which is not much and expected given that it only reshuffles the existing machinery, it is still a large patch in total. On the other side, João's patch avoids the complication of adhering to the existing guarantees of the APIs and takes the liberty of attaching "private" string properties to the completion strings of the completion table backend. I argue that attaching the string properties is a violation of the guarantees of the existing API and violates the expectations of the existing many completion tables. One very severe scenario is when obarray is used as completion table, since then each symbol name gets a private property attached. I argue that such global side effects like attaching string properties to all completion candidates should better be avoided. There is the issue that the attached string properties are a potential memory leak. When dumping the string representation of symbol names, the symbols will have additional properties which will complicate the debugging experience. Furthermore it will lead to confusion since the global side effect during completion will suddenly have an influence of symbols which don't have to do anything with completion. The big advantage of João's patch is that it is very limited in scope and very simple. However I argue that this simplicity is hard-won and we will regret this approach later due to the global side effects. Therefore I conclude that the two-step process proposed in my patch, which does not introduce problematic global side effects is the better approach forward. Furthermore a new API is needed such that more completion data can be returned, e.g., the completion end position. One could even return additional match data in the future given that the new API 'completion-filter-completions' is extensible thanks to its alist return value. João, please feel free to also present your closing arguments here. Daniel
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 12:02:26 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 08:02:26 2021 Received: from localhost ([127.0.0.1]:48715 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFbJx-0002ft-VG for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 08:02:26 -0400 Received: from mail-pj1-f47.google.com ([209.85.216.47]:37852) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1mFbJv-0002fV-8N; Mon, 16 Aug 2021 08:02:24 -0400 Received: by mail-pj1-f47.google.com with SMTP id cp15-20020a17090afb8fb029017891959dcbso31975574pjb.2; Mon, 16 Aug 2021 05:02:23 -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=FgipmI8mrux/nK0E7ZMSHjfGrIdRCejKfhBwYRpSzms=; b=NL/i3b2zUrULUZHux5TA+MqbiNNWyPsLvWNIz288/2bHzqBhzF1PX1DAjP52KXueOq OqKJGwHo7W5uEcvkhTGqGNggg95bAF/5VDp8ElPqC608A6to5DwQfu9JwI1JGdhwOj3B iNi9JNWeoByf76QGKUOaunwbnyA7PdY7M/GjkwzJiX5tUHo/QmT/B2jYO9bu4EIicK+O 9ddkvdZeU/29pwC0TDqpzqjuUQHe9qaHiSjMkEklDUjaxBOWdZrUTJy23ifbe9l03tb8 KHBX/wPl9wHopXhQyM78V3pItqJ4ZCyU3xIQHlGWzHdAq+p9jNMFQYcoSHxXiN9ndvDk 9BvQ== 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=FgipmI8mrux/nK0E7ZMSHjfGrIdRCejKfhBwYRpSzms=; b=qh+YkK4baWh29gu+mmNPQZmWuy3GonuzFBhVvqEwKaGAWzlIzMChcx9/rcXchHMdVo eTmNfBulLU9D96a99RZGo74CgPRNR2o/8RTGxhZ2BbUBcs+VzpAo2z0Neb7FSfRu2WVq He5+Z4A07QTKtJLGbAHrB94tIc1H3ok3MXMIXMUIvFK+3eVDjn50UkHmGBKBdxEtAbyD lGmo31dGjk+uq3Ri8uUFZUsgEQSfwx8Ch4uKwRsOiaTowR5sibxC54DmvXDZf5vVw9rj QfUN/+3XevQwY8zbzIj5XepdIJYBKvAwqbf9A9Ckt93vllfKTKfWUGVYnmYkEn7Z+V4t AZww== X-Gm-Message-State: AOAM533OLx07BHDXGgeVlN1jsHlcr2KEp7DNf+TGazkhL47NP2gq1TaI Rh+3vWM7BVWJ99gQ0xn6YIoEgwtq9EnHBkr2G2Y= X-Google-Smtp-Source: ABdhPJzjM5Qis+eLF+MA/lhmfwPXQa7dKbrodyXqHMG9z4pIxWVkYHQWf/UHH6u+FZiAOiv4JLPdPwnMZ1rVYV2C/uc= X-Received: by 2002:a65:6653:: with SMTP id z19mr15605178pgv.394.1629115337363; Mon, 16 Aug 2021 05:02:17 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <83h7fsbitl.fsf@HIDDEN> <75ce4b68-240f-2f0e-3953-c1f74962c3cd@HIDDEN> <83pmud8uwi.fsf@HIDDEN> In-Reply-To: <83pmud8uwi.fsf@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Mon, 16 Aug 2021 13:02:04 +0100 Message-ID: <CALDnm5306P+FrKW12uRcFcLC0K=MCse_asGfAVrnKgVnvZNoSQ@HIDDEN> Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Eli Zaretskii <eliz@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, 47711 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Mon, Aug 16, 2021 at 12:57 PM Eli Zaretskii <eliz@HIDDEN> wrote: > I was talking about the infrastructure that produces the completion > candidates, not about the application that uses them. My point is > that your approach requires the applications using the candidates to > copy them, whereas previously they could use them without copying. If it helps, I think that that is true of all alternatives presented so far (though I haven't read the big patch fully yet). The difference is that the consumers who copy the candidate strings will only copy a much smaller number, typically only the ones that need to be displayed. Whereas currently, all candidate strings are copied, displayed or not. Jo=C3=A3o T=C3=A1vora
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 11:57:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 07:57:16 2021 Received: from localhost ([127.0.0.1]:48686 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFbEy-0002T3-DN for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 07:57:16 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38180) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1mFbEw-0002Se-Kt; Mon, 16 Aug 2021 07:57:15 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44788) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mFbEq-0007if-P5; Mon, 16 Aug 2021 07:57:08 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2716 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mFbEq-0004Nk-CS; Mon, 16 Aug 2021 07:57:08 -0400 Date: Mon, 16 Aug 2021 14:57:01 +0300 Message-Id: <83pmud8uwi.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Daniel Mendler <mail@HIDDEN> In-Reply-To: <75ce4b68-240f-2f0e-3953-c1f74962c3cd@HIDDEN> (message from Daniel Mendler on Mon, 16 Aug 2021 10:48:19 +0200) Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <83h7fsbitl.fsf@HIDDEN> <75ce4b68-240f-2f0e-3953-c1f74962c3cd@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org, joaotavora@HIDDEN, monnier@HIDDEN, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: joaotavora@HIDDEN, monnier@HIDDEN, 48841 <at> debbugs.gnu.org, > 47711 <at> debbugs.gnu.org > From: Daniel Mendler <mail@HIDDEN> > Date: Mon, 16 Aug 2021 10:48:19 +0200 > > On 8/14/21 9:12 AM, Eli Zaretskii wrote: > >> Since up until now completion-pcm--hilit-commonality copied all strings > >> before modifying, completion tables such as described (with "shared" > >> strings) have all been "legal". Suddenly deciding to stop supporting > >> them would be a major API breakage with consequences that are hard to > >> predict. And while I perhaps agree that it's an inconvenience, I don't > >> think it's a choice we can simply make as this stage in c-a-p-f's > >> development. > > > > This sounds like an argument against Daniel's approach as well, no? > > Because if a completion API returns strings it "doesn't own", there > > will be restrictions on Lisp programs that use those strings, because > > those Lisp programs previously could do anything they liked with those > > strings, and now they cannot. Or am I missing something? > > No, in my patch the displayed candidate strings are still copied before > the text properties are attached. The strings are kept intact as they > are now. I was talking about the infrastructure that produces the completion candidates, not about the application that uses them. My point is that your approach requires the applications using the candidates to copy them, whereas previously they could use them without copying.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 11:48:53 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 07:48:53 2021 Received: from localhost ([127.0.0.1]:48677 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFb6r-0002CF-Aw for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 07:48:53 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36928) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1mFb6p-0002Bt-IX; Mon, 16 Aug 2021 07:48:51 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44662) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mFb6j-00032d-4E; Mon, 16 Aug 2021 07:48:45 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2200 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mFb6i-0003Lq-Hr; Mon, 16 Aug 2021 07:48:44 -0400 Date: Mon, 16 Aug 2021 14:48:39 +0300 Message-Id: <83sfz98vag.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <42a56dff-197d-d223-a2d8-12db8577b505@HIDDEN> (message from Dmitry Gutov on Mon, 16 Aug 2021 06:26:58 +0300) Subject: Re: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <83im08bjc3.fsf@HIDDEN> <42a56dff-197d-d223-a2d8-12db8577b505@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: mail@HIDDEN, joaotavora@HIDDEN, monnier@HIDDEN, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 47711 <at> debbugs.gnu.org, monnier@HIDDEN, joaotavora@HIDDEN, > 48841 <at> debbugs.gnu.org > From: Dmitry Gutov <dgutov@HIDDEN> > Date: Mon, 16 Aug 2021 06:26:58 +0300 > > On 14.08.2021 10:01, Eli Zaretskii wrote: > > > Just to make sure we are on the same page: adding a text property to a > > string doesn't mutate a string. Lisp programs that process these > > strings will not necessarily see any difference, and displaying those > > strings will also not show any difference if the property is not > > related to display. So the assumption that seems to be made here, > > that adding a property is the same as mutating a string, is IMO > > inaccurate if not incorrect. > > This is nonsense. > > A program won't necessarily see a difference in *any* changed value, as > long as some part of it stays the same. > > I can zero out the tail of a string, and have a program that only looks > at its first few characters. It wouldn't mean that a string hasn't changed. You are not making any sense. Anyway, if what I wrote doesn't help, feel free to disregard it.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 11:47:12 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 07:47:12 2021 Received: from localhost ([127.0.0.1]:48668 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFb5E-000298-7w for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 07:47:12 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36658) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1mFb5D-00028o-G7; Mon, 16 Aug 2021 07:47:11 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44640) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mFb57-00028Z-QC; Mon, 16 Aug 2021 07:47:05 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2095 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mFb57-0003EM-Ac; Mon, 16 Aug 2021 07:47:05 -0400 Date: Mon, 16 Aug 2021 14:46:58 +0300 Message-Id: <83tujp8vd9.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <31da8f43-02f7-e6dd-ab38-2160af138a4a@HIDDEN> (message from Dmitry Gutov on Mon, 16 Aug 2021 06:17:32 +0300) Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <31da8f43-02f7-e6dd-ab38-2160af138a4a@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: mail@HIDDEN, 47711 <at> debbugs.gnu.org, joaotavora@HIDDEN, 48841 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: mail@HIDDEN, monnier@HIDDEN, 48841 <at> debbugs.gnu.org, > 47711 <at> debbugs.gnu.org > From: Dmitry Gutov <dgutov@HIDDEN> > Date: Mon, 16 Aug 2021 06:17:32 +0300 > > On 14.08.2021 14:29, Eli Zaretskii wrote: > > Text properties are stored separately from the string, so I don't > > think adding properties can in general be referred to as "change". > > Are you thinking of C strings? No, about the implementation of Lisp strings in Emacs. > Lisp strings carry text properties in addition to the array of > characters. It doesn't really matter where in the memory the properties > and the characters reside. Well, it does, at least in some situations. The string text is not affected, and so the code which processes the string will not notice that it has a property about which that code has no idea. Only properties that are known to the processing code can affect it; non-standard properties private to some other code will generally pass unnoticed. > > Whether in some particular situation that could count as a "change" > > depends on that situation and on the particular property, of course. > > I was talking in the general sense: modifying a value. > > One can talk about whether a certain modification matters in certain > situations, but that's not the way to discount a general principle. I didn't want to start a general philosophical discussion about string mutability. I hoped to provide input of specific practical use in the context of this discussion. If what I said is not useful, just disregard it. > > I'm not sure in the context of completion there's any reason to count > > as "change" adding properties that don't affect display. > > For the context in question, whether the properties affect display is > not particularly important. Properties affecting display just make it > easier to notice that something's wrong. Bug involving other properties > should be more difficult to investigate. Once again, if some code invents its private property, not used anywhere else and not documented anywhere else, then putting such a property on a string has very high chances of going unnoticed. I hope this consideration helps this discussion, because saying that properties change a string blurs the distinction between actually changing the string text or its properties that affect many parts in Emacs, and adding some obscure property that is not known to anyone.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 11:37:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 07:37:37 2021 Received: from localhost ([127.0.0.1]:48657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFavx-0001rh-HS for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 07:37:37 -0400 Received: from mail-pl1-f170.google.com ([209.85.214.170]:38758) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1mFavv-0001rO-AX; Mon, 16 Aug 2021 07:37:36 -0400 Received: by mail-pl1-f170.google.com with SMTP id a5so20376640plh.5; Mon, 16 Aug 2021 04:37:35 -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=PP4sRFsXGoPRO3HMfAeZVAdQ65nsBuQPmVZTfft17hA=; b=GoSaAsmAvDaJ2uEnFUQL2xDzpkjCEOWINaIWLQb4j4gnIQT1XIeWP15QWTop+vtWrL dIqyXjGuNSjWTDDIRcm+rc+qvpNOFBTaUa50EZ0knZaSAyqLTEHe+0D7YeafD/auQ5X2 RGKP9WaXJNwr3rFIgUo2eiYBkX/TPV9UyskbbMV9y9jkEXr/90eVe3j7sM1zqpV5/F2R sEAeJib5PBjWZ4elaJdCAyv7vRPZSPdvAn8JxOtmS8PjwAVgtnwE0mWXt99s7LZh3Xde JklCLkX8moxJ/d9NNSghPMprtnY3Ek7bHEBYuda8rUPe2EJWhiwj3b13giMQrvGSMq4H rfzA== 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=PP4sRFsXGoPRO3HMfAeZVAdQ65nsBuQPmVZTfft17hA=; b=DQ/vdrTLsgX8WvR6REAhrMlk+Zc2S53hChzhYTrRE3NU3Q1OhK0INHm3avRoSSHrRK cKtUbaATb0UvCf04ttBCdspBczfm0tDC/b1uyCRmPNTYPHMxdZxCJf8I1vofSsXkFCMo KiBRZEryMrydzoDVzmqw7oBE5b4VQSc9TvPkd97nMFuQKzl6YRhBsRfb/e0mq5r0ymhT bJkkWSk+LZSfV2oD4B0d8wtCofyxXgSaYgcosPV6GhARXRZtUb2HkmT/g93HSvFd2sem uoFdDWUQuUEfDuwKwMxkej3afL7yeUYRDSWNR+CdwkPRcRoNOyaL9UZAGW3IbnC5lqfZ i16A== X-Gm-Message-State: AOAM533DyepoAsd/XxbhrdehaJxKWlhYtH1ZnjfHNXiRhmemoTb1hQe0 b/1O+8nTXOLEsSRlf97XeuSfiCOOJIKpj8KzcCg= X-Google-Smtp-Source: ABdhPJw7BaRbhM71Xp9pUzVXJR+YVQTSu9Q0LemJBUf+41xxZ6Cjz3cWVrjUel5I3GCBaZtwjQzU2ns366mJJydGD10= X-Received: by 2002:aa7:9050:0:b029:3af:7e99:f48f with SMTP id n16-20020aa790500000b02903af7e99f48fmr15986526pfo.2.1629113849377; Mon, 16 Aug 2021 04:37:29 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN> <CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN> <eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN> <87a6lihv7b.fsf@HIDDEN> <63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN> <CALDnm50W_=Y_zP7KLznqcqSx8KJp2-0u2NwpuEGzzAUzCNHvKQ@HIDDEN> <c95dea17-ca29-4dee-d53d-b5d46f7f2cf8@HIDDEN> In-Reply-To: <c95dea17-ca29-4dee-d53d-b5d46f7f2cf8@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Mon, 16 Aug 2021 12:37:17 +0100 Message-ID: <CALDnm53TD=FCf0davQC6q9esVxz687oBGN2LF=Egz3-kz6681Q@HIDDEN> Subject: Re: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Daniel Mendler <mail@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Mon, Aug 16, 2021 at 11:53 AM Daniel Mendler <mail@HIDDEN> wr= ote: > >> There are serious drawbacks of attaching "private" string properties t= o > >> arbitrary strings. For once it complicates debugging seriously if ther= e > >> 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..."= . > Jo=C3=A3o, I am giving hard examples here. If I say to you: "It's quite obvious your patch breaks all Git repositorie= s in Kathmandu, Nepal" I am expected to demonstrate how a patch to Emacs, leads to a obscure security flaw in the Linux operating system, that tickles a butterfly at a certain angle that causes an earthquake in the Kathmandu data center, literally breaking their Git repositories. This is the the kind of statement you are making to me and the kind of logical reasoning I'm looking for. Alternatively, you can provide an actual experiment I can run in my computer that demonstrates the bug. I am not a native English speaker, and maybe you don't understand my language. Another way to explain what I am talking is to talk about "bug reproduction". You say there's a bug in my patch, I am asking you for a "bug reproduction recipe" as defined by most, if not all, the result= s you get by searching "bug reproduction recipe" in the Google search engine. > goal is not to be right here just for the sake of being right. As Eli > said, nobody has to prove anything. This is clearly not what he said. > >> 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. > > As I said, I will ensure that my API does not introduce performance > regressions. Not only that, to produce veracity on that statement you would need some much more demanding proof, which is somehow be able to evaluate all possible APIs to compellingly demonstrate that yours triumphs. > I have a patch for Vertico which shows > this. I can provide patches for 'icomplete-mode' separately later on. Yes, please do. The earlier, the better. > No, we should not merge this problematic patch of yours. See the many > arguments against this proposal. I'm sorry to speak this child-like language, but a problem is a "bad thing"= . An undesirable thing that happens when presumably safe and good action(s) is taken by some user. Can you explain how, given my patch, a user would take a sequence of innocent actions that would lead to a "bad thing" that would _not_ happen if the same sequence of innocent actions were taken in a version of Emacs without the patch applied? That, to me, is what constitutes "a bug/problem in the patch". Let me give you an example: if I make a patch that deletes `/lisp` in the Emacs source tree, the innocent action "make" would probably not work. That would be the problem/"bad thing"/bug in that patch. We cannot proceed this discussion without these explanations. Mind you, I'm not stating, because it is impossible to prove, that my patch cannot possibly generate problems, subtle or obvious (that, by the way, is my interpretation of what Eli meant). But since you so confidently state that it does, it's quite reasonable that I ask you for examples that demonstrate it. Once you do demonstrate these bugs, it's reasonable I will go about fixing them. Exactly as you say you are going to do. I demonstrated with code and numbers a regression in _your_ patch, and you say are going to fix it. That's great, and that's the way it should be. But you possibly wouldn't go about fixing it if I hadn't demonstrated the regression compellingly, just as I can't go about fixing a "memory leak" or "debugging difficulties" if you don't explain what these things mean to you or how my patch causes them. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 10:53:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 06:53:10 2021 Received: from localhost ([127.0.0.1]:48623 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFaEv-000701-S4 for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 06:53:10 -0400 Received: from server.qxqx.de ([178.63.65.180]:42099 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1mFaEt-0006zS-Mq; Mon, 16 Aug 2021 06:53:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=/fVONndn1d2yojf57smO1XDuVRiSgpuk9VBMHyJfqo0=; b=IG5RSU61Y3C7Qtn3VtFY1CebtN +QPuxDouSXj1jJDLk3YuN8NerQGacWg826fbv27K1W4K4SkfLPHt6nBueSDh5KslUAx1/MigfCm+o USkrYrDdUGpOqnmNw6GjAa54BOEu+YC3aOsZg6Zvz6MbuekLzZ8IqlAsoY3ZQ21Bv2QQ=; Subject: Re: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN> <CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN> <eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN> <87a6lihv7b.fsf@HIDDEN> <63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN> <CALDnm50W_=Y_zP7KLznqcqSx8KJp2-0u2NwpuEGzzAUzCNHvKQ@HIDDEN> From: Daniel Mendler <mail@HIDDEN> Message-ID: <c95dea17-ca29-4dee-d53d-b5d46f7f2cf8@HIDDEN> Date: Mon, 16 Aug 2021 12:52:58 +0200 MIME-Version: 1.0 In-Reply-To: <CALDnm50W_=Y_zP7KLznqcqSx8KJp2-0u2NwpuEGzzAUzCNHvKQ@HIDDEN> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) On 8/16/21 12:15 PM, João Távora wrote: > On Mon, Aug 16, 2021 at 10:09 AM Daniel Mendler <mail@HIDDEN> wrote: > >> 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...". João, I am giving hard examples here. What is not an example about "memory leak" or making debugging output verbose thanks to the attached string properties? You always repeat your demands but whatever I write it is not satisfactory for you. Is it possible to convince you? Can you try to interpret my arguments in a positive and constructive light somehow and fill them with meaning such that it makes sense to you? My goal is not to be right here just for the sake of being right. As Eli said, nobody has to prove anything. >> 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. As I said, I will ensure that my API does not introduce performance regressions. And since my new API performs strictly less work than your proposal it will necessarily be faster if you consider only the filtering, which is what matters for incrementally updating UIs. >> 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ão for bringing this to my attention. However one should >> 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. There is also no manual documentation of 'completion-all-completions'. Of course you are right that it is early to make these decisions, but the new API 'completion-filter-completions' is designed in a way to allow adoption by 'icomplete-mode'. It is important to design the API such that adoption is possible. I have a patch for Vertico which shows this. I can provide patches for 'icomplete-mode' separately later on. > 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. As argued multiple times here now, the change you are proposing is fragile. It will lead to problems later on. The goal is not to find the smallest change which leads to a performance boost, all API violations allowed. Attaching "private" string properties to arbitrary strings is an API violation which we will regret later and which will make Emacs harder to debug and harder to use. > I think we should move to that, solving the bug#48841 while we > do the evaluation of all aspects of your contributions. No, we should not merge this problematic patch of yours. See the many arguments against this proposal. Daniel
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 10:16:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 06:16:00 2021
Received: from localhost ([127.0.0.1]:48599 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1mFZeu-0005me-BP
for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 06:16:00 -0400
Received: from mail-pj1-f49.google.com ([209.85.216.49]:50939)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>)
id 1mFZep-0005mL-7s; Mon, 16 Aug 2021 06:15:55 -0400
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)
MIME-Version: 1.0
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN>
<56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN>
<CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN>
<38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN>
<CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN>
<9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN>
<CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN>
<8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN>
<837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN>
<5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN>
<CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN>
<0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN>
<CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN>
<eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN> <87a6lihv7b.fsf@HIDDEN>
<63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN>
In-Reply-To: <63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN>
From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
Date: Mon, 16 Aug 2021 11:15:33 +0100
Message-ID: <CALDnm50W_=Y_zP7KLznqcqSx8KJp2-0u2NwpuEGzzAUzCNHvKQ@HIDDEN>
Subject: Re: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new
`completion-filter-completions` API and deferred highlighting
To: Daniel Mendler <mail@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 47711
Cc: Lars Ingebrigtsen <larsi@HIDDEN>, 47711 <at> debbugs.gnu.org,
Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org,
Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On Mon, Aug 16, 2021 at 10:09 AM Daniel Mendler <mail@HIDDEN> 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)<cursor here>
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
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 09:42:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 05:42:32 2021 Received: from localhost ([127.0.0.1]:48557 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFZ8Z-0004u9-TM for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 05:42:32 -0400 Received: from server.qxqx.de ([178.63.65.180]:43069 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1mFZ8Y-0004ts-8W; Mon, 16 Aug 2021 05:42:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=C6FYAFTRxF50v0M2jWCYcMTMDZouKfxCvDwJMzz16sk=; b=FKUNVDxD41IMLfHD0mdoT3ASsD n3JSH3Cw1ZWQxsEb4xxFSb6GITypglkL0jp1mlqd/9S4aom7WFdGcGAWDwvHSV8H39mwsQ19mtL0i lUt0Wz1Rm2H835cMHlsoIZuWmt8e9ySFM5KF6+UFScatCxCtVJ3u0ijJPUX5qTV2hHcM=; Subject: Re: bug#48841: [PATCH] Add new `completion-filter-completions` API and deferred highlighting To: Eli Zaretskii <eliz@HIDDEN> References: <f94541d3-5f93-9a23-8256-3bbc453f127a@HIDDEN> <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <837dgrdrec.fsf@HIDDEN> <aff2bd3a-ea3e-1ac6-cf0d-2785c6591c84@HIDDEN> <83mtpkbky3.fsf@HIDDEN> From: Daniel Mendler <mail@HIDDEN> Message-ID: <e2427908-17c5-ad18-a50a-2f2ebb61982c@HIDDEN> Date: Mon, 16 Aug 2021 11:42:22 +0200 MIME-Version: 1.0 In-Reply-To: <83mtpkbky3.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org, joaotavora@HIDDEN, monnier@HIDDEN, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Hello Eli, here I respond to the comments you sent out after I've already sent the overhauled patch. On 8/14/21 8:27 AM, Eli Zaretskii wrote: >> The function 'completion-filter-completions' receives a completion table >> as argument. The strings produced by this table are returned >> unmodified, but of course the completion table has to produce them. For >> a static completion table (e.g., in the simplest case a list of strings) >> the completion table itself will not allocate strings. In this scenario >> 'completion-filter-completions' will not perform any string allocations, >> only the list will be allocated. This is what leads to major >> performance gains. > > My point was that at least some of this should be in the description, > otherwise it will leave the reader wondering. I agree with this. The documentation should be improved. >>>> +(defvar completion--filter-completions nil >>>> + "Enable the new completions return value format. >>> >>> Btw, why is this an internal variable? Shouldn't all completion >>> styles ideally support it? If so, it should be a public variable, >>> documented in the ELisp manual. And the name should also end with -p, >>> since it's a boolean. How about completion-filter-completions-format-p? >> >> (As I understood the style guide '-p' is not a good idea for boolean >> variables, since a value is not a predicate in a strict sense.) >> >> To address your technical comment - this variable is precisely what one >> of the technical difficulties mentioned in my other mail is about. The >> question is how we can retain backward compatibility of the completion >> style 'all' functions, e.g., 'completion-basic-all-completions', while >> still allowing the function to return the newly introduced alist format >> with more data, which enables 'completion-filter-completions' to perform >> the efficient deferred highlighting. > > I understand, but given that we provide this for other packages, it > shouldn't be an internal variable. No, we explicitly don't provide this variable for other packages. It is explicitly only meant to be used for the existing completion styles emacs21, emacs22, basic, substring, partial-completion, initials and flex to opt-in in a backward-compatible/calling convention preserving way to the alist return format. The idea is to keep the existing APIs fully backward compatible. Other packages should select the format returned from the completion styles differently. They should return the alist format on Emacs 28 or if the API 'completion-filter-completions' API is present. In the not so near future external packages which support only Emacs 28 and upwards will then only return the alist format and don't have to perform any detection anymore. >>> Also, the "This function has been superseded..." part should be a new >>> paragraph, so that it stands out. (And I'm not yet sure we indeed >>> want to say "superseded" here, but that's part of the on-going >>> discussion. maybe use a more neutral language here, like "See also".) >> >> The new API 'completion-filter-completions' will substitute the existing >> API 'completion-all-completions'. > > That's your hope, and I understand. But we as a project didn't yet > decide to deprecate the original APIs, so talking about superseding is > premature. It is not the hope - it is the explicit goal. The API has been designed to replace the existing API 'completion-all-completions'. We can of course tone this down. However I, as a package author, would appreciate if Emacs tells me when a newer API aims to replace another API and when the documentation is explicit about it. Of course if you decide to have the doc strings written in a different tone, I will adapt my patch accordingly. Here I am just explaining why I chose the word "superseded" instead of a more neutral word. >>> Is "filter" really the right word here (in the doc string)? "Filer" >>> means you take a sequence and produce another sequence with some >>> members removed. That's not what this API does, is it? Suggest to >>> use a different name, like completion-completions-alist or >>> completion-all-completions-as-alist. >> >> "Filter" seems like exactly the right word to me. The function takes a >> list of strings (or a completion table) and returns a subset of matching >> completion strings without further modifications to the strings. See >> above what I wrote about allocations. > > But the name says "filter completions". Which would mean you take a > list of completions and filter out some of them. A completion table > is much more general object than a list of strings. Thus, I think > using "filter" here is sub-optimal. Okay, you are right about this. But I think even if the name 'completion-filter-completions' is not 100% precise it still conveys what the API is about. 'completion-completions-alist' or 'completion-all-completions-as-alist' are valid names of course, but I dislike them for their verbosity. Already 'completion-all-completions' is quite verbose. A strong argument to use this long name is that the completion style functions are still called 'completion-basic-all-completions' etc. But if we accept that the new API 'completion-filter-completions' will actually supersede the existing API 'completion-all-completions' it makes sense to use a name which will not hurt our eyes in the long run. However this is of course just a personal preference of mine. I don't want to spent much time with name bikeshedding discussions. If you decide on a name, I will adapt my patch accordingly. >>>> +Only the elements of table that satisfy predicate PRED are considered. >>>> +POINT is the position of point within STRING. The METADATA may be >>>> +modified by the completion style. The return value is a alist with >>>> +the keys: >>>> + >>>> +- base: Base position of the completion (from the start of STRING) >>> >>> "Base" here means the beginning? If so, why not call it "beg" or >>> somesuch? >> >> Base position is a fixed term which is already used in minibuffer.el for >> completions. See also 'completion-base-position' for example. > > Well, we don't have to keep bad habits indefinitely. It's okay to > lose them and use better terminology. Or at least to explain that > terminology in parentheses the first time it is used in some context. Okay, I agree. However I tried to avoid including superfluous changes with my patch set. We should add more context and documentation and then rename the variables in another patch if we decide that we want to go through with it. >>> Are we really losing the completion-score property here? If so, why? >> >> Yes, the property is removed in the current patch. It is not actually >> used for anything in the new implementation. But it is possible to >> restore the property such that 'completion-all-completions' always >> returns scored candidates as it does now. See my other mail regarding >> the caveats of the current patch. > > I'd prefer not to lose existing features, because that'd potentially > make the changes backward-incompatible. The overhauled patch (version 2) ensures that no features are lost. The patch is fully backward compatible. There is a potential performance regression in 'completion-all-completions' as identified by João. I have yet to confirm this regression. In any case, it should be fixable since the refactored 'completion-all-completions' API does precisely the same amount of work as it does now. Furthermore more documentation should be added to my patch. As of now 'completion-all-completions' is not mentioned in the info manual and 'completion-filter-completions' is also not added there. We may want to improve the documentation of that. But for now I would like to limit my documentation improvements to expanding the doc strings of the functions involved in my patch. Daniel
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 09:08:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 05:08:55 2021
Received: from localhost ([127.0.0.1]:48488 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1mFYbp-0003yu-Ms
for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 05:08:55 -0400
Received: from server.qxqx.de ([178.63.65.180]:33691 helo=mail.qxqx.de)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <mail@HIDDEN>)
id 1mFYbn-0003ye-BM; Mon, 16 Aug 2021 05:08:40 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de;
s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:
MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:
Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
List-Subscribe:List-Post:List-Owner:List-Archive;
bh=GJcT/T5DVTuHMs67rjtK1AoQVRPLwkXyW16s1GuaJfQ=; b=mcXl/177spo4DFSgMO5rICqYIR
75/3YzAOxMWILnRCf6B7BUnCXi26il3qrnACsZKMwWM3/SAgDOzvgyBXxl68lpbg2q0raDMtzo6mp
gQxuCbALUXXoCHXyqhjjJZKsttKSS9itzkbIzlbycWfYXP53dAxFWI7m7QnRnQHu90EU=;
Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new
`completion-filter-completions` API and deferred highlighting
To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>,
Dmitry Gutov <dgutov@HIDDEN>
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN>
<56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN>
<CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN>
<38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN>
<CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN>
<9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN>
<CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN>
<8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN>
<837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN>
<5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN>
<CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN>
<0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN>
<CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN>
<eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN> <87a6lihv7b.fsf@HIDDEN>
From: Daniel Mendler <mail@HIDDEN>
Message-ID: <63e03b18-db81-3b11-c692-0af9df20c506@HIDDEN>
Date: Mon, 16 Aug 2021 11:08:31 +0200
MIME-Version: 1.0
In-Reply-To: <87a6lihv7b.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47711
Cc: Lars Ingebrigtsen <larsi@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org,
47711 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)
On 8/16/21 6:25 AM, João Távora wrote:
> Yes, I currently conclude that there are 0 drawbacks identified to
> creating, _via_ string properties, an association of, say, property
> 'joaot/answer' with value '42' to _any_ string in my current and future
> Emacs runtimes.
>
> I conclude that because --- apart from your aesthetics considerations
> ("do we really want to see...") --- I have not seen identification of
> such drawbacks. Have I missed any?
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. But even if we could chose this approach
with global side-effects I don't see a reason to do it given the
approach I am proposing in my patch, which avoids these problems entirely.
1. My approach decomposes the already existing completion machinery into
two steps: 1. filtering and 2. highlighting. It does not change the
fundamentals of the completion machinery. This decomposition of the
existing infrastructure is also what leads to the small number of added
lines to minibuffer.el, even if the patch itself is not as small as we
would like to have it.
2. Why take the chances of introducing potentially harmful global side
effects by attaching string properties to arbitrary strings if we can
avoid it easily?
3. The `completion-filter-completions` API is the fastest possible API
for filtering since it does not change the strings at all, it does not
attach string properties or modify the strings in any other way. By
construction, it is a pure function which only filters the list of
candidates. This makes the function easy to use and easy to reason
about. An API which adds private properties to the strings cannot be as
fast and non-intrusive.
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ão for bringing this to my attention. However one should
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. Given this a potential regression of
'completion-all-completions' would matter less for the incrementally
updating UIs. But of course I feel the same way as João - a performance
regression in the API 'completion-all-completions' is unacceptable. It
will be fixed.
Daniel
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 08:53:40 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 04:53:40 2021 Received: from localhost ([127.0.0.1]:48464 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFYNI-0003ZM-Aq for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 04:53:40 -0400 Received: from server.qxqx.de ([178.63.65.180]:34305 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1mFYNH-0003Z0-16; Mon, 16 Aug 2021 04:53:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=fpp4hAYM18zw+5pcKevICIykRc1pCDf5Y3PkSL0tb7Y=; b=OUfE89ov3IcQQzb6hGevkjrz8P irOW11NZG7k5ND6knED5g+woz2oU8VIk/25SMlkYTUj+A4ClRHUTENivqvtCtQYR7OMjQ6z54W1uz xZ3v5s46ROs3ffVlLWiC1fxMPMWTfBoIaAegq2FvWkOf9Bm07J/8O8F4YR+5R83t1EXE=; Subject: Re: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <87sfzca0zm.fsf@HIDDEN> <4cac92d2-056d-e7fb-0664-2dbccb5f980c@HIDDEN> <87eeauhvg6.fsf@HIDDEN> From: Daniel Mendler <mail@HIDDEN> Message-ID: <62d4ebdd-8d9c-13d3-77d2-df36352d4803@HIDDEN> Date: Mon, 16 Aug 2021 10:53:31 +0200 MIME-Version: 1.0 In-Reply-To: <87eeauhvg6.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) On 8/16/21 6:20 AM, João Távora wrote: > It's not me who is saying it, it's my Emacs :-) The real problem is that > with Daniel's patch, the frontends using the current API (as in > icomplete/fido) measurably become _slower_. Though not by much (around > 10%), it is still a shame. I have to check this. I claim that 'completion-all-completions' should not get slower with my patch. If it gets indeed slower as your benchmark shows, this should be fixed and can be fixed since I am not doing something else than decomposing the highlighting and filtering processes, which are already present in the current machinery. The amount of work stays the same. However in the case the new 'completion-filter-completions' API is used, the filtering will get much faster since no highlighting and copying takes place. Daniel
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 08:48:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 04:48:35 2021 Received: from localhost ([127.0.0.1]:48437 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFYIJ-0003Ql-9P for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 04:48:35 -0400 Received: from server.qxqx.de ([178.63.65.180]:33607 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1mFYIE-0003QR-3v; Mon, 16 Aug 2021 04:48:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=JPHtbETPUUl+hbFRN+vAcwY4jQIo9t7zr8cK40eYWmA=; b=lILtorBIeUZejadXdlsAZAftz8 GwSlbBDxMmVJt4+9lA1546PwKiCUr1waQRx+VDMgjqBTQNwCo+X/f+bx1+8upDNzUPuRR5jbBnxTd dicn2cjyHJ1hNMTJJApMyqelX3Z8nI3ocxPk2/+29uxlHkpj/Oqr6YHgExJhoXIYGomM=; Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Eli Zaretskii <eliz@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <83h7fsbitl.fsf@HIDDEN> From: Daniel Mendler <mail@HIDDEN> Message-ID: <75ce4b68-240f-2f0e-3953-c1f74962c3cd@HIDDEN> Date: Mon, 16 Aug 2021 10:48:19 +0200 MIME-Version: 1.0 In-Reply-To: <83h7fsbitl.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: 47711 <at> debbugs.gnu.org, joaotavora@HIDDEN, 48841 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) On 8/14/21 9:12 AM, Eli Zaretskii wrote: >> Since up until now completion-pcm--hilit-commonality copied all strings >> before modifying, completion tables such as described (with "shared" >> strings) have all been "legal". Suddenly deciding to stop supporting >> them would be a major API breakage with consequences that are hard to >> predict. And while I perhaps agree that it's an inconvenience, I don't >> think it's a choice we can simply make as this stage in c-a-p-f's >> development. > > This sounds like an argument against Daniel's approach as well, no? > Because if a completion API returns strings it "doesn't own", there > will be restrictions on Lisp programs that use those strings, because > those Lisp programs previously could do anything they liked with those > strings, and now they cannot. Or am I missing something? No, in my patch the displayed candidate strings are still copied before the text properties are attached. The strings are kept intact as they are now. Daniel
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 08:47:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 04:47:30 2021 Received: from localhost ([127.0.0.1]:48432 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFYHG-0003On-88 for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 04:47:30 -0400 Received: from server.qxqx.de ([178.63.65.180]:58513 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1mFYH6-0003OM-6C; Mon, 16 Aug 2021 04:47:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=DXzv+Bnip6z/cdxMuTfEFoOWdakNTpWYQig4GgvIjnQ=; b=SSb5x9ZQ8ZsoUGdP+4TKoqrmPu ZYbOzyMx0c2frl89WsNnyvckcXnI8XtekCQ7ngPYb/Gy4u7jhZmLioX5utXVEh9JpCKi5V4Dlvama vU534OzP73bchDa85/UD87Ofk9BEUOkTgly/TVFZR7Q3P8TYwOPHHO3IvPry6oxzNsl8=; Subject: Re: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Eli Zaretskii <eliz@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <83im08bjc3.fsf@HIDDEN> From: Daniel Mendler <mail@HIDDEN> Message-ID: <1d8ac48c-1627-cfa0-640c-9c1371612787@HIDDEN> Date: Mon, 16 Aug 2021 10:47:06 +0200 MIME-Version: 1.0 In-Reply-To: <83im08bjc3.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: 48841 <at> debbugs.gnu.org, dgutov@HIDDEN, joaotavora@HIDDEN, monnier@HIDDEN, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) On 8/14/21 9:01 AM, Eli Zaretskii wrote: > Just to make sure we are on the same page: adding a text property to a > string doesn't mutate a string. Lisp programs that process these > strings will not necessarily see any difference, and displaying those > strings will also not show any difference if the property is not > related to display. So the assumption that seems to be made here, > that adding a property is the same as mutating a string, is IMO > inaccurate if not incorrect. While I agree that adding text properties is not mutation of the string text itself it still mutates the string data structure. Dmitry made a good point about this - if a completion table uses obarray as backend to the completion table you suddenly attach text properties to symbol names. This is not a good idea. I actually had such an issue once in a package I developed, where I accidentally attached text properties (via the mutating put-text-property API) to some strings I didn't own. This lead to unexpected side effects at other places where I didn't expect the strings to have properties attached. Daniel
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 04:25:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 00:25:54 2021
Received: from localhost ([127.0.0.1]:48153 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1mFUCA-0002k2-9M
for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 00:25:54 -0400
Received: from mail-wm1-f50.google.com ([209.85.128.50]:41724)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>)
id 1mFUC9-0002jm-34; Mon, 16 Aug 2021 00:25:53 -0400
Received: by mail-wm1-f50.google.com with SMTP id
c129-20020a1c35870000b02902e6b6135279so9318558wma.0;
Sun, 15 Aug 2021 21:25:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:cc:subject:references:date:in-reply-to:message-id
:user-agent:mime-version:content-transfer-encoding;
bh=xraikt2tOdI1hqt2PIK4lpMWEd383AhNGIeQUFzgCYk=;
b=RB9s5ay9cJpj3JfZmyhyoSLYIFXMT5ydIoSYNM3u6zCL6QlpGmZP2oNQCpch40raog
TOHiW70m6WVmD1IdrZCxKZvAscX+UzO9wJoo6ghAtyTj45PA1Jl5cvDG4tscWaKO7bJ2
uGZPLmpv17sXGuYZBXWjxtzMqJjA9n/ww+/yYF9L11+dKO8YBO5X6FNDu9dM7rnBFDQE
8I+yDwSiE1yPsJdptldyXf05QGVlN9T1nIC79gqv1bjkPHylki2GlSf2awZCMQogspE8
SjmoZD3rlPMNfNvr2gyqsxtqCb8FiK0Ljy+5mEH25TYDBKppS4hi+YI7kUzX6RdbGpG6
mq5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
:message-id:user-agent:mime-version:content-transfer-encoding;
bh=xraikt2tOdI1hqt2PIK4lpMWEd383AhNGIeQUFzgCYk=;
b=CvDHKtql6GmxrOse1+WhX89HKeZrb34/WTjTgbhKm1YPXvb1ojuVaJs2I9hIRJYOkV
ZnDWQ2U2+hj+q6JkeqayGwPKvuz3dOmh2gxyx/gXqKhItaaQMZW7fNiKEEDHm519mNdK
Sh9TKdowX/dqYMTokHDMk2gtNtGJP1yfB2eJg9jMtxQBkHRKr2S9Ob3EFNVutDW+bO+A
qKxEI4TzsrvHYq844jcP8gPbixvXtAMvRiqVsMcS6Ypw+dzt0ija4EPQZ3ivR4pp61gi
6NH8269JDqwZaiwXYLgXFNmpqCVa/3F3po5XyOBomdkqTlONKxxmQF7R9ygvOSuiNP9B
lB1g==
X-Gm-Message-State: AOAM530kcnA4Y8lnn3jgc7WPsnLOC4ljT8TdBk6AxMlp4YY9VEneglkf
r1Tv6KRyjY7CKd8bnnOqZFLyr9MU12M=
X-Google-Smtp-Source: ABdhPJwbYccrVXXTamaDRZJRM8ivS1HWK5Mr3M7d3sOwlkIhGYiqetskN2G/SF/Q/F6yYHq7PvDBLA==
X-Received: by 2002:a7b:cf0c:: with SMTP id l12mr13322338wmg.62.1629087946912;
Sun, 15 Aug 2021 21:25:46 -0700 (PDT)
Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132])
by smtp.gmail.com with ESMTPSA id h11sm9847108wrq.64.2021.08.15.21.25.45
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sun, 15 Aug 2021 21:25:46 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new
`completion-filter-completions` API and deferred highlighting
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN>
<3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN>
<CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN>
<56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN>
<CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN>
<38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN>
<CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN>
<9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN>
<CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN>
<8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN>
<87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN>
<87wnootec0.fsf@HIDDEN>
<5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN>
<CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN>
<0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN>
<CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN>
<eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN>
Date: Mon, 16 Aug 2021 05:25:44 +0100
In-Reply-To: <eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN> (Dmitry Gutov's
message of "Mon, 16 Aug 2021 06:59:52 +0300")
Message-ID: <87a6lihv7b.fsf@HIDDEN>
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: 47711
Cc: Daniel Mendler <mail@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>,
Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org,
47711 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Dmitry Gutov <dgutov@HIDDEN> writes:
> On 16.08.2021 06:53, Jo=C3=A3o T=C3=A1vora wrote:
>> But why do it, since a string plist is a such a nice place to do these
>> associations and there's -- apart from your aesthetics considerations
>> -- 0 drawbacks identified?
>
> You read all the explanations, and THAT'S your conclusion?
Yes, I currently conclude that there are 0 drawbacks identified to
creating, _via_ string properties, an association of, say, property
'joaot/answer' with value '42' to _any_ string in my current and future
Emacs runtimes.
I conclude that because --- apart from your aesthetics considerations
("do we really want to see...") --- I have not seen identification of
such drawbacks. Have I missed any?
Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 04:20:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 00:20:37 2021 Received: from localhost ([127.0.0.1]:48146 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFU73-0002av-2z for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 00:20:37 -0400 Received: from mail-wr1-f47.google.com ([209.85.221.47]:43672) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1mFU70-0002ae-HF; Mon, 16 Aug 2021 00:20:35 -0400 Received: by mail-wr1-f47.google.com with SMTP id z9so21578529wrh.10; Sun, 15 Aug 2021 21:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=6ORklZy2oh7+mIpgyzo/CZybnxRFNWUtbViQ+U+jU1o=; b=YL5LwTo17TvVYrpoNbfomTr0onwcObAQEtAFYSujsdtf3kybfR4RNg/AzbmC5d788V zc5R/0Y8+ufO/IID9VNIkX2GvdpcnyOgq5kjZseX1rU+wKLKZLqGJAHroIZC052u/FCj WDQ6B/rmVuklCfE0hq+U83kfr3WOby+DUsKNQ6lvCNh0bs5wfUUwZ4Bz+r1ZZuWjsDtX CUEErG7fzFY0hLaiTmP+zp1cZVqMsoNV7Hkp/ByhGeI1jTAjYDXwvEsEVjd0AOnX8rcA tERmS+PVbO+OSntEBAcOd4w9oN2v7WEe7KASbC3pLMK57/kdKLnNlyZXHWrgYcuDSRA7 4vyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=6ORklZy2oh7+mIpgyzo/CZybnxRFNWUtbViQ+U+jU1o=; b=KJ3WsdoN2n2fLipF6wF8qJEj4G+jfR82z2Zf5RsyVrnB6vhdqXiRlzOlnCQcmo5oFZ j2v/X4x3Venyn/nfV7QoTO8nmtlTEEHwIOuezJxDxEDvY/a4CIW0ACGTkKIOe09eUI2g D9kIkPLivLeqQKoKfYZc0TFpjLqqvsaRMbD8TIztxdiTcB9oJ9NPc7z6J4WbOhRTxfWl 4ToFnMzPX0vLqViF6w9JrWOvAXpH9zIs0/Z5gRu1vdh5HFAnCk0tdPdvWXCp06QyHkQa ZW244N0vnmp8M9PxPsoz0W8S6IacO3yS82VYOqGTwbB23zmtg2wCuF3AXmV57jyGl5wJ 8QzA== X-Gm-Message-State: AOAM531ygnM6WIZS7Z2O3kRYBi7mtNGRCIjgGB63VxqfsNQdTpXMchOG U7iDVkWMWHMbo7lBlduqbhi6/NkN3cw= X-Google-Smtp-Source: ABdhPJyqbcT14E1S1SsGdjfOZya8JhfeBXkq4rBHSUaGdB+Ob/fDPByYkpxDCFR/yApduR3DU7+9dg== X-Received: by 2002:a5d:6da4:: with SMTP id u4mr16291268wrs.50.1629087628279; Sun, 15 Aug 2021 21:20:28 -0700 (PDT) Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132]) by smtp.gmail.com with ESMTPSA id k13sm1619589wms.33.2021.08.15.21.20.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Aug 2021 21:20:27 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <87sfzca0zm.fsf@HIDDEN> <4cac92d2-056d-e7fb-0664-2dbccb5f980c@HIDDEN> Date: Mon, 16 Aug 2021 05:20:25 +0100 In-Reply-To: <4cac92d2-056d-e7fb-0664-2dbccb5f980c@HIDDEN> (Dmitry Gutov's message of "Mon, 16 Aug 2021 06:48:32 +0300") Message-ID: <87eeauhvg6.fsf@HIDDEN> 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: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> writes: > As I pointed out later in the email you're replying to, copying won't > happen N times. _Currently_, as in origin/master, it happens N times. In my patch, when a frontend adheres to the thing, it happens D times where D is the amount of strings you need to display. I guess if you do the work to adapt a frontend to work with the new API proposed in Daniel's patch it will be about the same (though likely in many more lines of Elisp). > First of all, note that scoring is only essential to the 'flex' > style. Whereas the improvements we're discussing should benefit all, > and can be more pronounced if the scoring don't need to be performed. Yep, I agree. But I don't see why the same principles I espouse -- which really amount to: let the style know it doesn't need to face-propertize -- can't be applied to other styles that don't need scoring. Although those don't seem to suffer from any performance problems, at least I haven't seens any complaints/reports/mesurements like you did for bug#48841. > But ok, let's talk about flex in particular. Yes, I think that is important since it is the style known to be least performant by its very lax nature. > I'm guessing you just skip the C step in your benchmarks? Which is > something that breaks our current contract. Right. Skipping the 'C =3D Copying step' is the whole point. It breaks our contract because the completion styles currently promise to "face"-propertize the string. So this is why I propose to let the completion-style know that it doesn't need to. When it is told of that, it is relieved of the necessity of copying the string. It is the frontend that will do that copy just before face-propertizing and displaying the string. As you note, and reality shows, that's much faster. There is no disagreement here. > Still, Daniel's patch should provide a comparable performance Kinf of, from what I've read, it _should_ open the way for that to happen. From what I understand, you must then change the frontend (in a big way?) to stop using completion-all-completions and start using the new thing. That work has not been done, as far as I know. Whereas in my proposal (which is now a patch posted to bug#48841) you change the frontend in a very minor way, and that work _has_ been done. Icomplete was very easy to adapt. I can try adapting company soon. In practice, we can't kill off completion-all-completions and start everyone on completion-filter-completions (if that's what it's called). So if the latter does turn out to be a step in the right direction (I'm mostly waiting on Stefan to chime in), then I also don't see why we couldn't have, as Eli suggested, both strategies for lazy highlighting at some point in the future. > improvement. If you're saying it doesn't give numbers as good, I'll > have to give it a more thorough read and testing tomorrow to comment > on that. It's not me who is saying it, it's my Emacs :-) The real problem is that with Daniel's patch, the frontends using the current API (as in icomplete/fido) measurably become _slower_. Though not by much (around 10%), it is still a shame. Yes, do your testing and please, as always, try to report as quantitatively as possible, so that we can really compare apples to apples. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 04:00:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 16 00:00:03 2021 Received: from localhost ([127.0.0.1]:48125 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFTn9-00024L-7y for submit <at> debbugs.gnu.org; Mon, 16 Aug 2021 00:00:03 -0400 Received: from mail-wr1-f43.google.com ([209.85.221.43]:34705) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1mFTn6-00022i-P2; Mon, 16 Aug 2021 00:00:01 -0400 Received: by mail-wr1-f43.google.com with SMTP id h13so21678016wrp.1; Sun, 15 Aug 2021 21:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=d2GuwYH/OdC8HDu+lSnSMT9xRK5kCYBVEDUP4oi0MZM=; b=uTwWVwq4ZwGlWV/QY+WWaC8zZdUtdrnMW7LZNN7A6oxjyGTz6i/Mi/EJFAMjZ3sCQy Y9HMXUX7mZLng+6YhcypmAt+lbIxItyAaMXmYoKljh6dsRiTlM2vysk0k+L/Y57kFpk1 3VjdJvGo6TMcE8thEvKr0vhx24C7noEeEs8oLH1JhqWeYqIVxNqoy/iB+eSc59RztqzW m0pVPXwYeD79jyHok3Q2RBM/n//yKAMO6R+sHG44XT/Qkx6cM1L83WObolhoM9sOv6Bm bd1CFviTzdi1VfS4ubKpBSRei8k5wkFGmL29QLVeH95u5tjWlI+mQfvoyMjCgoh2Tidi Jo7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=d2GuwYH/OdC8HDu+lSnSMT9xRK5kCYBVEDUP4oi0MZM=; b=ZDiKvHD2WjjKr4AZcSAZyvIo7a0u9Ch0cEXAwiiVytZ7zKJGg+GBiP8Lh5L0QHwzC7 0PmDlmzMW7aK6w5jPH1eouJ64wdY9+Fosp6EbPbrvRnO1ZrTM9hRBsK/s8+WlM3ZiXK5 tn36pr900UI7kMXzHZXAEdoQuoK67qkxBax55KUnS2giTp9ehM1P6QVC694rp5hblA9b Kjv3t1i4q02IKtp+llpF0I0qabBOpWSPRlaOtMxej7juE3laHMjbwcgxkHN+KzYw2HE4 nLNwVGC1Tnf0C8H1lUPTl6SAiy9OE/PEJ8lzLXw/90ddK24kEOFHj762j/AOjbVbcCrm rsrw== X-Gm-Message-State: AOAM530maPgAi6saT69UVtan49cOEQX7LAWWQvz4sXyemPkSEex/azla LHi5XuSMmnLA38IQtzsD1jDxor0Sny8= X-Google-Smtp-Source: ABdhPJzngxCUGZ9JhdYE4wBXFsHbXyxA7ML1nlcykdFMllRAkl5xfvw4blwUoYUviuVfwu/2ARNv8g== X-Received: by 2002:a5d:64ef:: with SMTP id g15mr9422616wri.135.1629086394957; Sun, 15 Aug 2021 20:59:54 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id f17sm10074999wrt.49.2021.08.15.20.59.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 15 Aug 2021 20:59:54 -0700 (PDT) Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN> <CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <eecaa682-496e-8173-caf7-2f9781cc7102@HIDDEN> Date: Mon, 16 Aug 2021 06:59:52 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.6 (/) On 16.08.2021 06:53, João Távora wrote: > But why do it, since a string plist is a such a nice place to do these > associations and there's -- apart from your aesthetics considerations > -- 0 drawbacks identified? You read all the explanations, and THAT'S your conclusion?
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 03:54:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 15 23:54:29 2021 Received: from localhost ([127.0.0.1]:48112 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFThh-0001ua-Pb for submit <at> debbugs.gnu.org; Sun, 15 Aug 2021 23:54:29 -0400 Received: from mail-pj1-f48.google.com ([209.85.216.48]:53780) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1mFThY-0001uB-Q7; Sun, 15 Aug 2021 23:54:20 -0400 Received: by mail-pj1-f48.google.com with SMTP id j1so24399797pjv.3; Sun, 15 Aug 2021 20:54:16 -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=5U8epICC1itkFK7Ot8G6B3eKqRd2LOVPQEmirX1WEQI=; b=jxdnZS1FpAM8YS/mMD7kzFj0mtHzMu3zXrle8ijqhVn4K8vxhSEBK8XBDTWW5Ulfal 1TfJ53Kp3XMldOSbitiN1Wg8G2YOSOcGxcnRVWaerr3OoosNzJnnf955hL4RUyKe0qnc pocnoLbXK8bt8JipFWmDnGkiseoDYsLDDgzFgawd/myMJ61DeVRPE05EZi0OU8p6iZbp FaAlPsllupTojXEf9QoNZqfHyMs19zhExBmB5bo6KorUm1or2z4LOwsb8vL9+a/GZjvX T+6TWRp6Z3Nmys42lvybHuoLEeYKHCsl2lks6DL8f8IyHUzvyRYJ/1tHc019p1kIEHTx IpPA== 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=5U8epICC1itkFK7Ot8G6B3eKqRd2LOVPQEmirX1WEQI=; b=bF6ZSo/YG7xb1vO4uR3HlVYbBRgLpSHjvkM7xk9QUc0jMxZQMnQnMFj9qE2bBFESSA cAnV7A+sAqZ/JvtFxM2wTF2RjMzDl3qBHPfbvSz2edHNBH6lkhmLd1+2CtxyeNRKOrl0 Lx06gyypEbtaho7INdSwX+vf+iIY0OsagTRA3It5apmrOIECO8yk6bYTV7YlVApp8tb/ N4cx8A6mP/FY6PEyT7nOmXjl8JOPLZljrdQeGXYrscZlyAReewtWyiDGMrhc7OHlcMzD A8UNBKTBhmaV3f0PD6n4Ro6q6frFnfysi/o52/pwbTAeQt71rk2AYkTwmMZqs+aE5biV sGDA== X-Gm-Message-State: AOAM533jrgNLT+djLmOQNZLGETco2HSzVqy8msbSi8ntCgP5HyurBjIC 5Hm2rPp0A5bBhc+WVdDjLsOIPrWHBeUKfGLdGtg= X-Google-Smtp-Source: ABdhPJw/eF2aVy16C6VGDXYzzJxISRy2gtTQ/5B/MqJg9pUwG0KUwr2/9Dw/q+u73fbyzqNfFi+1CZaXBjlEq2mMRkA= X-Received: by 2002:a17:902:d487:b0:12d:89d3:a6b with SMTP id c7-20020a170902d48700b0012d89d30a6bmr11825580plg.52.1629086050783; Sun, 15 Aug 2021 20:54:10 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN> In-Reply-To: <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Mon, 16 Aug 2021 04:53:59 +0100 Message-ID: <CALDnm52x_S2UXE=YVokCWEZf9Gqc0O+g4ZVhi+R60SCeq6JtzA@HIDDEN> Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Dmitry Gutov <dgutov@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Mon, Aug 16, 2021 at 4:31 AM Dmitry Gutov <dgutov@HIDDEN> wrote: > > On 16.08.2021 06:27, Jo=C3=A3o T=C3=A1vora wrote: > > I wouldn't mind that at all. For me, it's quite the same as evaluating > > (symbol-plist 'car) and seeing (is-vehicle t number-of-wheels 4) along = with > > all the other byte-compilation stuff already there. > > Those serve a real purpose, not just work as an accidental cache for > some earlier computation. Caches also serve "a real purpose". the gv-expander there would be the "cache of an earlier computation". And I'm not sure what "accidental" means, but if it means "implementation detail for something I don't care about", I agree `completion-score` is "accidental". Should it be called `completion-score-internal-cache-dont-look-here`? Maybe. Bottom line here is that an outside observer has no clue, and shouldn't need or want to have a clue, on what "foreign" properties attached to strings or symbols are meant. This is why Eli says, and I agree, that if the property isn't display related, it's all good. No-one but the setter and reader of that particular property mind. The CL systems I've worked with use package qualifiers to fine-grain this even further, but they use the same principle. That Elisp allows a string property list doesn't really make a difference IMO. And none of this really really matters to the discussion. If we absolutely had to store these associations away from the string plist, (for some aesthetic reason, I guess), we could just use hash-tables. Then we could return the string unchanged (and uncopied) and largely keep performance intact. But why do it, since a string plist is a such a nice place to do these associations and there's -- apart from your aesthetics considerations -- 0 drawbacks identified? Jo=C3=A3o T=C3=A1vora
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 03:48:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 15 23:48:43 2021 Received: from localhost ([127.0.0.1]:48103 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFTcA-0001mC-LO for submit <at> debbugs.gnu.org; Sun, 15 Aug 2021 23:48:43 -0400 Received: from mail-wr1-f52.google.com ([209.85.221.52]:38864) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1mFTc8-0001lu-BW; Sun, 15 Aug 2021 23:48:41 -0400 Received: by mail-wr1-f52.google.com with SMTP id u16so4479636wrn.5; Sun, 15 Aug 2021 20:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4BWckHAxffwgEJeyO1tLFsBqmwUJUtAVqNgNJVrxWAE=; b=jsbczeL+xRdtbkDfx2OONBFi8nnmGKmvDJrYBWgftiiAkmrTxXcmzpyzxiPp7SceT6 wKzyI5XCQzD9OulT8irby/BG6oQ6ssjdKHpwYxos9Jmk2U2iyePILe7uJwHS6sSEt8B5 M4nu3n4vTUbP6Spq8eVsQogrMgHMIPKHKFKNbU7+0Txx+qrdWvL7Qfs+VGv/n5MrLiYc ViuvDD15+KDI8dbQP/vlEAHUhzyXNOwhAShVausuAEr5aNe9n9pKCQolkU5w2eF8x+B4 UqlqzstE31+koKHRbQ8OSxTIQ/1E0uveoh6k1GuV5D3gRMURlZJw491L9dgjjuYRBu8L 64IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=4BWckHAxffwgEJeyO1tLFsBqmwUJUtAVqNgNJVrxWAE=; b=BRWu+dSCBHDXsCg86UsWqpo58D4BHIpDSaBhlIy6nXcxxHcym44MlPOhwoySf9ZYXN upMEF92CA8jGM0cmGoC8xwvJ2K+dH+FH/U3bSEtiC+2fCbcYceg29yUITJAQ1lKEh9hg ejnCKHnn8Hzx4CZ2Z88YEhNP3GA98KKgyi9/XK450pX0MqEDAiULsa3n/RJzOqT5kFA1 9xXgwSuXCd3vemTG/VNpRFk+Sxq/l4aSPlqpy5ldXXwy2VEkGPQKCOkT4UpJcmOxdGUh R8SgMKM3M4zRIQtykkIaX8ooabSSlRki//Kp2iMzr6HtX8OAXqdvjcyUCelJJKCNu7Bk JDkw== X-Gm-Message-State: AOAM531dtKQD07GdL5LFqcyyYitjJvFBHEeZpBuBFbXgPBss6sAwoEe1 cwf5JrEVS8srZF4DRR5h8BAecTWyzJk= X-Google-Smtp-Source: ABdhPJww1P+mqruluBF5QDFEvKw6xiYCIYpTpexCH/wDiRNgTNbouR7y2gWmehFel0dbkwksXZvfVA== X-Received: by 2002:a5d:6386:: with SMTP id p6mr15956716wru.143.1629085714223; Sun, 15 Aug 2021 20:48:34 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id l7sm9468851wmj.9.2021.08.15.20.48.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 15 Aug 2021 20:48:33 -0700 (PDT) Subject: Re: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> <87sfzca0zm.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <4cac92d2-056d-e7fb-0664-2dbccb5f980c@HIDDEN> Date: Mon, 16 Aug 2021 06:48:32 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <87sfzca0zm.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.6 (/) On 14.08.2021 11:23, João Távora wrote: > Dmitry Gutov <dgutov@HIDDEN> writes: > >> Aside from the mutability/ownership issue, >> >> On 13.08.2021 15:05, João Távora wrote: >>> If one removes these lines, the process becomes much faster, but there is a >>> problem with highlighting. My idea is indeed to defer highlighting by not >>> setting the 'face property directly on that shared string, but some >>> other property >>> that is read later from the shared string by compliant frontents. >> >> I haven't done any direct benchmarking, but I'm pretty sure that this >> approach cannot, by definition, be as fast as the non-mutating one. >> >> Because you go through the whole list and mutate all of its elements, >> you have to perform a certain bit of work W x N times, where N is the >> size of the whole list. > > Let's call W the work that you perform N times in this istuation. In > the non-mutation, let's call it Z. So > > W <= Z, because Z not only propertizes the string with a calculation of > faces but _also copies its character contents_. As I pointed out later in the email you're replying to, copying won't happen N times. > Also I think it's better to start about copying rather than mutating. > As Eli points out, putting a text property in a string (my idea) is not > equivalent with "mutating" it. In common industry terms, that's mutation. Lisp strings are not C strings, they are aggregate objects. >> Whereas the deferred-mutation approach will only have to do its bit >> (which is likely more work, like, WWW) only 20 times, or 100 times, or >> however many completions are displayed. And this is usually >> negligible. > > I think you're going in the same fallacy you went briefly in the other > bug report. The flex and pcm styles (meaning > completion-pcm--hilit-commonality) has to go through all the completions > when deciding the score to atribute to each completion that we already > know matches the pattern. That's because this scoring is essential to > sorting. That's a given in both scenarios, copying and non-copying. First of all, note that scoring is only essential to the 'flex' style. Whereas the improvements we're discussing should benefit all, and can be more pronounced if the scoring don't need to be performed. But ok, let's talk about flex in particular. > Then, it's true that only a very small set of those eventually have to > be displayed to the user, depending on where wants she wants her > scrolling page to be. So that's when you have to apply 'face' to, say > 20 strings, and that can indeed be pretty fast. But where does the > information come from? > > - Currently, it comes from the string's 'face' itself, which was copied > entirely. > > - In the non-copying approach, it must come from somewhere else. One > idea is that it comes from a new "private" property 'lazy-face', also > in the string itselv, but which was _not_ copied. Another idea is > just to remember the pattern and re-match it to those 20 strings. Let's say that the cost to compute the score (on one completion) is S. And the cost to highlight it is H. The cost to copy a string is C (that would be amortized cost, including the subsequent GCs). The current algorithm costs: N x (C + S + H) C is unavoidable because of the existing API guarantees. A non-mutating algorithm can cost: N x S (for sorting) + 100 x (C + S + H) (let's say we didn't even cache the scoring info) ...where 100 is the number of displayed completions (the number is usually lower). As we measured previously, copying is quite expensive. Even in the above, not-caching approach we win ((N - 100) x (C + H)), and, okay, lose 100 x S. For high values of N, it should be a clear win. > I think the second alternative is always faster. > >> However big the difference is going to be, I can't say in advance, of >> course, or whether it's going to be shadowed by some other performance >> costs. But the non-mutating approach should have the best optimization >> potential when the list is long. > > Don't think so. I'm doing benchmarks, will post soon. I'm guessing you just skip the C step in your benchmarks? Which is something that breaks our current contract. Still, Daniel's patch should provide a comparable performance improvement. If you're saying it doesn't give numbers as good, I'll have to give it a more thorough read and testing tomorrow to comment on that.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 03:32:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 15 23:32:03 2021 Received: from localhost ([127.0.0.1]:48086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFTM2-0000qv-UK for submit <at> debbugs.gnu.org; Sun, 15 Aug 2021 23:32:03 -0400 Received: from mail-wm1-f44.google.com ([209.85.128.44]:40778) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1mFTM1-0000m2-Lm; Sun, 15 Aug 2021 23:32:01 -0400 Received: by mail-wm1-f44.google.com with SMTP id f12-20020a05600c4e8c00b002e6bdd6ffe2so8144551wmq.5; Sun, 15 Aug 2021 20:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ikPRGbaH3/T2gGcoVYmunjrKkikyMmJTvMUt584VY4I=; b=iIfQZmfyfMVyTpotHKPgmDG7rIQ2SMt6UBKrylUWrdOvlrS2Hc6rSZ9Hak4TgEOA4r jccMDFFPaj0mQFKQZ52r+NbjrBaDS20QdtX3vftpWxv6LjepuzuVSHw/lmh/ghAaxaSL M8p39tboRwQSoAVtVLGMc4buz2hwFZJu6VfkzPdXnseY+vG08LjlDZvZ7s4AlCbUhKTz V9cfn+WxodEhVPThycfwtdZpc28iBGas/iUf8jE4rTWNdOY/gaLFyOUXeKTH8aI36FhE +BH1jiSfAHIxUf3YFIRDFAy6Oq4ZJVluaEbqbExMqyHP3bpVJD4WOxgk1T6BUyEI3s2y /28w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=ikPRGbaH3/T2gGcoVYmunjrKkikyMmJTvMUt584VY4I=; b=BjIq7Y+OO4TeMJl9+/8lOZGK+r7tVpycAniHCtYVYDNo1ymBhgnUIMr3vRgDqAWozQ kgQxWRr82gEkMLo/U6BKz2lEoz6IPbOYSjjY31RTQDldq3X3/CKXnyU6XlmJM/tRjzOl o4KbF5xUg8lffGrSQxxZ0ef3F/1TPaXqdQccwKLNb95taAEEGKfkmD7XDFRBo8XlobZR SRMTvbQTJrnSyctsTjOf3zKx+n1lrsRf093Brdg86vbLnQue7npns7RvJFnryu/CKbci BGgmfh7d/cwqLDvlbQtgo314OwErguZQauipJRiYR8Jw80HY6+bq0QDexqDWMdSWHmyG NMiQ== X-Gm-Message-State: AOAM531TCQ1swcCXqFGVAkRuN0uLTZAWDATKMYE7Ic8HJ7aIv0cvY5tq GtKNZX6XlD0HI+BjaBp27JBfd8Kzz5A= X-Google-Smtp-Source: ABdhPJxugN+DM7cE2KdKXkpqgIStJhRdl+Gc8od4Jjtp1AYYyonSZT49wfzzPkDubtYeDStakZRJcA== X-Received: by 2002:a1c:f002:: with SMTP id a2mr13478861wmb.79.1629084715969; Sun, 15 Aug 2021 20:31:55 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id w1sm8830714wmc.19.2021.08.15.20.31.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 15 Aug 2021 20:31:55 -0700 (PDT) Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@HIDDEN> Date: Mon, 16 Aug 2021 06:31:54 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.6 (/) On 16.08.2021 06:27, João Távora wrote: > I wouldn't mind that at all. For me, it's quite the same as evaluating > (symbol-plist 'car) and seeing (is-vehicle t number-of-wheels 4) along with > all the other byte-compilation stuff already there. Those serve a real purpose, not just work as an accidental cache for some earlier computation.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 03:27:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 15 23:27:43 2021 Received: from localhost ([127.0.0.1]:48078 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFTHr-0007ZC-C7 for submit <at> debbugs.gnu.org; Sun, 15 Aug 2021 23:27:43 -0400 Received: from mail-pj1-f46.google.com ([209.85.216.46]:46777) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1mFTHp-0007Yt-65; Sun, 15 Aug 2021 23:27:41 -0400 Received: by mail-pj1-f46.google.com with SMTP id w13-20020a17090aea0db029017897a5f7bcso25217295pjy.5; Sun, 15 Aug 2021 20:27:41 -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=THe/EBE3o/Xs+vLnOgxL99jiwYDsHvA1ibY5VWm72UY=; b=fzHWbgWng70CfutZoXzUKkyXJxUAsZSl+l+ZNERBDBX384D7ydjcYu60ae7YI+H+j3 aFM+gZCJoUQsgHkyySd5hk2bov0kD8JmOG4L/7ipBw5thIExJNbaa1gpd+2/B65jgSj6 YX2xUf+vcktPbLMlvOYSMqBOyaHmpjHIoWMxO75oiykqvd3c/rScuk0WyIqwEOpx7l0q Bygx1Wz3ymfMf13dPJubTVOH3PsbqPI+XB+4zakkg+gyQK5FvXOOCMGWEvAhhP7+p0HT YtsIKduwKwquuS4lHOLY/3XLBe04R90OOCaqlT+6s+BdoIZpsN9xz2rE9hilebURUcDD VqSg== 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=THe/EBE3o/Xs+vLnOgxL99jiwYDsHvA1ibY5VWm72UY=; b=fsg/YDRktpY+ph5JCTW/Y5FFP1RMoUjBr7LeFcsX/u92vj3vvRUqoeQgsPjBPpgfJ0 xd5lHBvFYi2LKuxjsYITMXOzr2CJHbMCBxS5vL+eBTQlR7zfQgqyelrKFNbc0O7IjP0o QCWsVOiJJxpM8Ylh4L87w4lPStGFF/MbIKl09+49PgCKeXaTOPjLh4utf1YlsnPF3oXK epvQ0ZEj+xLGfK4rBhSZVac4hW04fPZrKs11SCZKRxIY+VYrkDrHOhWcPeGVN3R8t/i6 ASLNASSEntuO4PFpJoFU0WfnkDfu7I0ZxF/DfmOkdC+53dnHYKQ2Y62BkMo5nlGaT4J3 vHyQ== X-Gm-Message-State: AOAM533Sa3sPbdxdq7a9t4IR7WUifyVTApJ6PAekQ5usD7PZgG5mo6JD vXSXCeU9Tadh8JU9h7laqx9YsJoLrb1ac8HZ14w= X-Google-Smtp-Source: ABdhPJwXRDNZqcDvyWUJ5GYKbhiWoBmi1myOucrCSy0TmEivEx6WflHuw7taqOWFHuBAAKTnEVndnpFTM+iiaRliSsA= X-Received: by 2002:a17:90a:a091:: with SMTP id r17mr15138587pjp.56.1629084455343; Sun, 15 Aug 2021 20:27:35 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> In-Reply-To: <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Mon, 16 Aug 2021 04:27:24 +0100 Message-ID: <CALDnm51xYehwuGhMubovLTv_nqtdJYvOmH2e-bH3cCjf0PS2WQ@HIDDEN> Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Dmitry Gutov <dgutov@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Mon, Aug 16, 2021 at 4:21 AM Dmitry Gutov <dgutov@HIDDEN> wrote: > And even if the effects are usually not serious, are we really okay with > evaluating (symbol-name 'car) someday and seeing lots of properties > attached to it? I wouldn't mind that at all. For me, it's quite the same as evaluating (symbol-plist 'car) and seeing (is-vehicle t number-of-wheels 4) along with all the other byte-compilation stuff already there. Jo=C3=A3o T=C3=A1vora
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 03:27:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 15 23:27:08 2021 Received: from localhost ([127.0.0.1]:48073 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFTHH-0007YD-Td for submit <at> debbugs.gnu.org; Sun, 15 Aug 2021 23:27:08 -0400 Received: from mail-wr1-f46.google.com ([209.85.221.46]:38856) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1mFTHG-0007Xe-IW; Sun, 15 Aug 2021 23:27:07 -0400 Received: by mail-wr1-f46.google.com with SMTP id u16so4439971wrn.5; Sun, 15 Aug 2021 20:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=64L5cJPDoPRrS5Chh6NOZfcomFk5jztUAvnroYkjfPw=; b=fjigDKyawAO1shNmVuscU1AZyAArtiQcs3PVAS0Mjv7CNg3gjLc3yHODK92qHMvI58 JF3oBPpCnX+GMDfDUAJ1DPsPjJqwI51Iduo+Yb6n9WlxLr/5VuR0sWUK9tuHJKCpCjG1 Q6Ja3KSzknM09G57DfuwxJkapSfRgSrDnAV3VxQqn52bM8JLIfXliv4nvnecRO6myTKP SSKGYJ1gisG+ItQzxULAPnPQNo3KqZByKmpbeo/Y7qZvhSNnFhnDq60ErRdRXX6YLpc6 GD01nHMdFi2KzvRIFrtD5BqJUXBRSAFzLlfwnwLZbjfKkjMkoVV5RfcWOUJhwqhbVezt v6iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=64L5cJPDoPRrS5Chh6NOZfcomFk5jztUAvnroYkjfPw=; b=lfY0aJqX17pgr/KrwQCcFcMWfz3tabLDvv3zzbArJInSdEmf0bKTz2JudhHfKWME7W OGGtlaqnkk9/a5l3c1brL0jnduDuyG1Qshl5KSszNTPciar7XoXqItV7eD9e9xKGyqw+ YJYT8y/42KDgX5iJpmkdyrxbnuKVwKOwps3Y5K6mX2T6kPdAa5vg1dAx6d7SiXZp+dh4 w73aFMSrb3RsmJTQW2wVEccBkomnU733IgkCTNKQjAnM4ZjT+cfrkK4rMlRhlTrhcZbd CzThntPdqSBA5lRLnKKT0JXpYw682Lp7Bq7ZEel+N8/T4uf8hMPa2njfbU9mj3cN8SWv HxBQ== X-Gm-Message-State: AOAM531cbP5wQeWDiV2WLKFlqzSkeVTfh3xzMFnqJIM7nkmq5oVfVCPm 5AJpsOgZaQgtEHMk+UMw/pV+MP+gk3I= X-Google-Smtp-Source: ABdhPJyVliP1KOFR+r10ppj6J661h+p0H9YHW7C15qmTn8R30bpVXr/AWYkT/eZbqJK87JFYDpFk0w== X-Received: by 2002:a5d:42c9:: with SMTP id t9mr15847021wrr.356.1629084420779; Sun, 15 Aug 2021 20:27:00 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id n10sm4316110wms.3.2021.08.15.20.26.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 15 Aug 2021 20:27:00 -0700 (PDT) Subject: Re: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Eli Zaretskii <eliz@HIDDEN>, Daniel Mendler <mail@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <83im08bjc3.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <42a56dff-197d-d223-a2d8-12db8577b505@HIDDEN> Date: Mon, 16 Aug 2021 06:26:58 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <83im08bjc3.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 47711 Cc: joaotavora@HIDDEN, monnier@HIDDEN, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.6 (/) On 14.08.2021 10:01, Eli Zaretskii wrote: > Just to make sure we are on the same page: adding a text property to a > string doesn't mutate a string. Lisp programs that process these > strings will not necessarily see any difference, and displaying those > strings will also not show any difference if the property is not > related to display. So the assumption that seems to be made here, > that adding a property is the same as mutating a string, is IMO > inaccurate if not incorrect. This is nonsense. A program won't necessarily see a difference in *any* changed value, as long as some part of it stays the same. I can zero out the tail of a string, and have a program that only looks at its first few characters. It wouldn't mean that a string hasn't changed.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 03:21:27 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 15 23:21:27 2021 Received: from localhost ([127.0.0.1]:48063 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFTBm-0007Pt-Na for submit <at> debbugs.gnu.org; Sun, 15 Aug 2021 23:21:26 -0400 Received: from mail-wr1-f51.google.com ([209.85.221.51]:38463) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1mFTBj-0007Pc-Us; Sun, 15 Aug 2021 23:21:24 -0400 Received: by mail-wr1-f51.google.com with SMTP id u16so4428362wrn.5; Sun, 15 Aug 2021 20:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=/SDdnV/qJpRL1tdLDLIG8DzV4voetJU/pAmP2OsCwmQ=; b=INK893s60seq21i3Dj5Kh+rfJDiOwPaCCk5Nt1TrGFQjLttNjPcyQKwFkedSi0/JMg ZFiWptBDGU+IByd4h1QasfSz6f+mYeFU5EKKnQ0Vxz7cVhQtV7BwN8G0MnhSecJkpmK+ 8lPEBsaRhE+PXj5zlPjj8IHHCsrliEQ97zZeNBZGCopMFfsHf199L0HVcNMu96mb0zKb VV6Cs/FYyM7+XhvSCqY4IQk4u76cYXN1KTPCJqQhD+Y+jXneHJJW2gaLCW8udzkqmtZI nhioPrrSSlcWpO2NqKVgHY/OKuvEFJKVuWa+ClvlGjfCMLTfMdcyXmVVbpv4zXWIOj6I +Pnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=/SDdnV/qJpRL1tdLDLIG8DzV4voetJU/pAmP2OsCwmQ=; b=FvfOUWi83UiAk17HICrLJ0e/yOyEEklfNwN7ztrDR5znOUlKO3x01nD5u71kiwdlbl i5MpjUF3sBkS5b8IWyQTBbtR55G1spk7YBJi6rHpw3aNfddt37SNsKAQK1sd5O6ctee6 Eyb2E3eid0Dzj3bvKmZmoo9rJMIUohkGcxsEpuxzt8s4xmE9ybUJ9idnStg6GdufdpSL IgTgZ9bbCwLEvFGztA81nKsNwbhU5hhmbcPPx6JAz68/CfPRHhiT4XkvpcgIKlmqbqaR 1n+PVo+cDGgggqsagvTjvVPwonRbMjtmKoDQXMbJFnc3A3bO1PdOpU9dD6Z8paVPXjEo 6WVw== X-Gm-Message-State: AOAM530/V20OZR4i60nwdh+3tIhEHQ57/yHb2+gudBKxnAOSpJ6a2xK6 eV8Ug9IJNx0PQpJAWONdxffnRsVDli8= X-Google-Smtp-Source: ABdhPJyYmnt+dnaCSXEoR1/rysVo1gOgb6lV5DwDleVLpb2yhlFNUeLcnSxtUgUrJ9JW8l/NArVtyA== X-Received: by 2002:adf:e9c3:: with SMTP id l3mr16098689wrn.300.1629084078386; Sun, 15 Aug 2021 20:21:18 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id t14sm9177633wmj.2.2021.08.15.20.21.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 15 Aug 2021 20:21:18 -0700 (PDT) Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Lars Ingebrigtsen <larsi@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <5d70b0ad-3838-ddb8-d341-9a5531d9da73@HIDDEN> Date: Mon, 16 Aug 2021 06:21:16 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <87wnootec0.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 47711 Cc: mail@HIDDEN, 47711 <at> debbugs.gnu.org, monnier@HIDDEN, 48841 <at> debbugs.gnu.org, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.6 (/) On 14.08.2021 15:12, Lars Ingebrigtsen wrote: > It is a destructive change, but we may just declare that completion > functions are allowed to destructively change the inputs in certain very > prescribed ways. I'd rather avoid that, though, if at all possible, > because it may lead to subtle bugs all over the place. That would be a breaking change, but it's a possibility, of course. If we couldn't find a better way to implement this. > Stefan just reminded me (in a different bug report) that we've long > meant to extend the text property machinery with a "namespace" or > "plane" concept. The impetus for this is really the font locking > machinery which wants to manage some text properties that other packages > also want to manage. "Planes" for text properties are just prefixed properties, I guess? That's different from the situation with font-lock. > The idea is that the display machinery would combine all the planes > before displaying, but each package would just manage its own "plane". > If we had something like this, then using this mechanism in the > completion context would make sense -- we could then say that completion > isn't allowed to alter anything except text properties in its private > plane. Yes, if the code makes sure to only use prefixed properties, that would limit the damage. It could still affect repeated (parallel?) uses of the same values in the same piece of code. And even if the effects are usually not serious, are we really okay with evaluating (symbol-name 'car) someday and seeing lots of properties attached to it?
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 03:17:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 15 23:17:43 2021 Received: from localhost ([127.0.0.1]:48050 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mFT8A-0007IV-Ov for submit <at> debbugs.gnu.org; Sun, 15 Aug 2021 23:17:42 -0400 Received: from mail-wm1-f49.google.com ([209.85.128.49]:37399) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1mFT88-0007IE-6k; Sun, 15 Aug 2021 23:17:41 -0400 Received: by mail-wm1-f49.google.com with SMTP id c8-20020a7bc008000000b002e6e462e95fso1142688wmb.2; Sun, 15 Aug 2021 20:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=wrMjrV8qQgdb2hCWp4i6jVb0kXGOCWq9X7R/gxFJh3Y=; b=VQC7CqZ+QlIdgYzmvEB0JUixt++PP0zheGv4CEg4hvEsfzG9p5Y4uQILjNneEIrOx8 ExwG3fJCrZRmAyALE57A3jadmlCTJAvYf9Bg4+Hc8jYHRYRx0ZuKuO8MEmlpZ1sx9O0f hiotEmN03kV+SeOq3AEEs7o4h/r7cLhHjBBQRDmwPxUchUghIFWRTivbsJdNrkQ+rVas WedqUQP8bixNccyZr/s3K9/ED1PurhYinE0NHv1/ZKAIEeNFGip/dqbVem+1DCnIfayH kxv2+ilYSV2k2aaGbs3G8pFHfmggYnG256fqqpjEaOI6n5tDiFq2oAI9ZGvhaJ9L0nAd ppTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=wrMjrV8qQgdb2hCWp4i6jVb0kXGOCWq9X7R/gxFJh3Y=; b=gseS7LRraWC/6zNmf/ty8ve+frcEEkECEnOuzrarIgH0IXUa3hPxBozRbyanPziqJ+ 2lBk60tBlbr2WzCyEFO8/tzqYpwNPhmyO+aSPK9axpPYTbfewp+0qX+7EClGk/2TxxZv Ve7SZyhHt+qstnWO/SfoVgwVAcCOJg46beyI8/4wde5b4OF5rzaP2r0Ddy8CoBxT5iD1 fPDKmqymXCyej4En8g3otnseZvVV2tKsa3s/t7FJXcx+/Sb3/wbpAxExdrPm5wIkhxtG WkvuWp73jpoWeAn4P1XpUj2aJTNN58A0R8NwFAADAPGS3xPHMv3idLWboyfcC55YlOx1 rNkw== X-Gm-Message-State: AOAM531VIB3hR06EuH2+ua0+S8m4Gvrbl63wFDlOUCjtE3LE0dTNjXUA jtIh3MQJxtHMRFXf6tuy3aZuOxe4Peg= X-Google-Smtp-Source: ABdhPJxXaa7rFIciOBkeaJ/YuFNR6EPpQeJNc0JVHlj3aG5kcC4JpzQNtsbWqxWHLS47LPB219CJBQ== X-Received: by 2002:a05:600c:a08:: with SMTP id z8mr13420412wmp.165.1629083854298; Sun, 15 Aug 2021 20:17:34 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id b20sm9724439wmj.20.2021.08.15.20.17.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 15 Aug 2021 20:17:33 -0700 (PDT) Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Eli Zaretskii <eliz@HIDDEN>, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <31da8f43-02f7-e6dd-ab38-2160af138a4a@HIDDEN> Date: Mon, 16 Aug 2021 06:17:32 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <837dgob6yo.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 47711 Cc: mail@HIDDEN, monnier@HIDDEN, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.6 (/) On 14.08.2021 14:29, Eli Zaretskii wrote: > Text properties are stored separately from the string, so I don't > think adding properties can in general be referred to as "change". Are you thinking of C strings? Lisp strings carry text properties in addition to the array of characters. It doesn't really matter where in the memory the properties and the characters reside. > Whether in some particular situation that could count as a "change" > depends on that situation and on the particular property, of course. I was talking in the general sense: modifying a value. One can talk about whether a certain modification matters in certain situations, but that's not the way to discount a general principle. > I'm not sure in the context of completion there's any reason to count > as "change" adding properties that don't affect display. For the context in question, whether the properties affect display is not particularly important. Properties affecting display just make it easier to notice that something's wrong. Bug involving other properties should be more difficult to investigate.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 15 Aug 2021 00:03:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 14 20:03:29 2021
Received: from localhost ([127.0.0.1]:45532 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1mF3cf-0006KK-5O
for submit <at> debbugs.gnu.org; Sat, 14 Aug 2021 20:03:29 -0400
Received: from mail-wr1-f41.google.com ([209.85.221.41]:35501)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>)
id 1mF3cd-0006K3-D0; Sat, 14 Aug 2021 20:03:27 -0400
Received: by mail-wr1-f41.google.com with SMTP id q10so18386833wro.2;
Sat, 14 Aug 2021 17:03:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:cc:subject:references:date:in-reply-to:message-id
:user-agent:mime-version:content-transfer-encoding;
bh=qklDJ5gPDaNiJGUeObEycQTArsmErnSMftxyioCEZWM=;
b=PkFu5fYdl2NYm+8n3UE2+ICJducbUpqKse/nlXI8HXlbJGdqcCRbcquZlGnn6X5QcT
e7XtwTnz1Sq1PASmhDX01c7fHkacEXNzA0HFMdRp8ZxoJetF/K392SngIsF+bJeP6r6m
1xR8DQbrgYmBKYfgWiao1ra/iJYqjd4ah4SD8+0S4u7nXOuMiDEjrzzFY5/Tbv0AI6Ez
xXkD8Nr/JPcWKTOq9XvBepPEts5F6Qm1j0wTkfpamcUX5IPZBjoPumdwtw9YoEoRtae9
oN2MIGqCxj5PYezGZJQvKeFXxcron1zG+pGHh+CcTcQmOQqmW4ABGxeSfg4YKm3tT6PS
EE0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
:message-id:user-agent:mime-version:content-transfer-encoding;
bh=qklDJ5gPDaNiJGUeObEycQTArsmErnSMftxyioCEZWM=;
b=VXdJWx8IWM31cFiVoetwVhjgcgy5w+4V3qiX0sPb7iHvAgDorxQPewjVrF006QoCMl
11pLQq0thVvSLgSKVPIEeTFKjV8D9SxsR15fOrFBNlNpffhEimRe0BjshZPTEgh5tnqa
oEW7elD1CeUGjmlnc3JW8f/CnmqeMqBC956RKI3SDZcsVKrlplbgIjLPgkmF0cjdhBTZ
pIPEy7IZc79CvRSpc5E1NjryF+SUirnesXy/Jq9rT2xFAhLuKraJFK/lOkQ0tKIQr+Rj
TAGcq2w6qs4EL6HaW189LRZxc5PDxLGBQdRQF92/6rta6BPFbObeFGGvgA9sZ+lZYeXb
OqdA==
X-Gm-Message-State: AOAM531YwnxOY6+u54svB3iSQvSON3xlihLMnL+lRdrT2vEKLKKWS5hB
RcKqe5mqGBrck55u9wXvMt0=
X-Google-Smtp-Source: ABdhPJyUCZaxxxOBi9K8i35OHATog1u0JejE8y4B2qRfotNjDgBltcumqscOgQDXq2Tgy/t0KO4vRQ==
X-Received: by 2002:a5d:5703:: with SMTP id a3mr10510017wrv.333.1628985801441;
Sat, 14 Aug 2021 17:03:21 -0700 (PDT)
Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132])
by smtp.gmail.com with ESMTPSA id s10sm7598232wrv.54.2021.08.14.17.03.19
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sat, 14 Aug 2021 17:03:20 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#47711: [PATCH VERSION 2] Add new
`completion-filter-completions` API and deferred highlighting
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN>
<fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN>
<3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN>
<CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN>
<56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN>
<CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN>
<38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN>
<CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN>
<9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN>
<83im08bjc3.fsf@HIDDEN> <877dgo8ihf.fsf@HIDDEN>
Date: Sun, 15 Aug 2021 01:03:18 +0100
In-Reply-To: <877dgo8ihf.fsf@HIDDEN> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?=
=?utf-8?Q?a=22's?= message of "Sat, 14 Aug 2021 10:48:28 +0100")
Message-ID: <87tujr7ewp.fsf@HIDDEN>
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: 47711
Cc: Daniel Mendler <mail@HIDDEN>, dgutov@HIDDEN,
monnier@HIDDEN, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:
> in the absence of any controlled benchmarks I did some of
> my own, using the most controlled environment I could devise. I start
> Emacs like so:
>
> ~/Source/Emacs/emacs/src/emacs -Q -f fido-mode -f fido-vertical-mode -=
l ~/tmp/benchmark.el ~/tmp/benchmark.el
I have know tweaked the benchmark slightly to make it easier to evaluate
speed qualitatively. Here's what I've been using.
(require 'cl-lib)
=20=20=20=20
(fido-mode 1)
(fido-vertical-mode 1)
=20=20=20=20
;; Introduce 150 000 new functions to really slow things down.
;; Probably more than most non-Spacemancs people will have :-)
(defmacro lotsoffunctions ()
`(progn
,@(cl-loop repeat 150000
collect `(defun ,(intern (symbol-name (gensym "heyhey")))=
() 42))))
=20=20=20=20
(lotsoffunctions)
=20=20=20=20
(when nil
;; Press C-u C-x C-e C-m quickly to produce a quantitative sample
(benchmark-run (completing-read "" obarray))
=20=20=20=20
;; Or just press C-h f to experience how fast/slow completion is.
)
The results are the same as the ones I reported in the previous email.
I've also cleaned up my previous patch of the
scratch/icomplete-lazy-highlight-attempt-2 branch slightly. It is now
fully opt-in for frontends and completion-styles, so the backward
compatibility problems which I speculated seem to have been exaggerated.
I'm still studying it for flaws, but anyone can have a look. And, of
course, there are many different ways to realize the "opt-in" for
frontends/styles. I just chose the one that seemed the simplest given
the current completion framework.
The performance is still very good, it reduces the usual waiting time in
long lists of completions to about half of what it currently is.
Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 14 Aug 2021 13:29:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 14 09:29:19 2021 Received: from localhost ([127.0.0.1]:43840 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mEtiw-0007Hv-Mq for submit <at> debbugs.gnu.org; Sat, 14 Aug 2021 09:29:18 -0400 Received: from quimby.gnus.org ([95.216.78.240]:33192) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <larsi@HIDDEN>) id 1mEtiu-0007He-5k; Sat, 14 Aug 2021 09:29:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=xRxGA7F4YEqXq+8FnWlqiVa/Azmuq2pSfPDNleoGrRI=; b=kMAw8LpeatKL2Th0QxC+E7FaCO ODH/dK4iF4cu9p9iDHlsF/HGLhfoQ7xmvEcPFkvE/O8AsGxteVztzDc5kf2k3iR0dwIW2DE0wqqjz 6HGmoD4+4s42x8R5pqGcD5nG8VevB6IWk+Rgag96VKrs6YS5v4iiskLIDe/YFTPZds/s=; Received: from [84.212.220.105] (helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <larsi@HIDDEN>) id 1mEtii-0001Or-36; Sat, 14 Aug 2021 15:29:08 +0200 From: Lars Ingebrigtsen <larsi@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> <8335rcb3oo.fsf@HIDDEN> Date: Sat, 14 Aug 2021 15:29:03 +0200 In-Reply-To: <8335rcb3oo.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 14 Aug 2021 15:39:51 +0300") Message-ID: <87a6lktasg.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.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 @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii <eliz@HIDDEN> writes: > How can that work if at display time all the "planes" are combined? > It would mean that the code which produced the original strings will > get them displayed differently after completion. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: mail@HIDDEN, joaotavora@HIDDEN, 48841 <at> debbugs.gnu.org, dgutov@HIDDEN, monnier@HIDDEN, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii <eliz@HIDDEN> writes: > How can that work if at display time all the "planes" are combined? > It would mean that the code which produced the original strings will > get them displayed differently after completion. That's in the font-lock context, where font-lock will do faces on its "plane" while other packages can do faces on their own "planes", and they'll be combined on display. It not relevant in the context of this bug report, but I thought I'd just mention the general design. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 14 Aug 2021 12:40:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 14 08:40:17 2021 Received: from localhost ([127.0.0.1]:43798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mEsxR-00069g-HA for submit <at> debbugs.gnu.org; Sat, 14 Aug 2021 08:40:17 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41018) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1mEsxM-00069G-3k; Sat, 14 Aug 2021 08:40:12 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49494) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mEsxE-00057C-Rp; Sat, 14 Aug 2021 08:40:00 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3166 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mEsxE-0002mD-Bm; Sat, 14 Aug 2021 08:40:00 -0400 Date: Sat, 14 Aug 2021 15:39:51 +0300 Message-Id: <8335rcb3oo.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Lars Ingebrigtsen <larsi@HIDDEN> In-Reply-To: <87wnootec0.fsf@HIDDEN> (message from Lars Ingebrigtsen on Sat, 14 Aug 2021 14:12:31 +0200) Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> <87wnootec0.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: mail@HIDDEN, joaotavora@HIDDEN, 48841 <at> debbugs.gnu.org, dgutov@HIDDEN, monnier@HIDDEN, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen <larsi@HIDDEN> > Cc: Joo Tvora <joaotavora@HIDDEN>, > mail@HIDDEN, > dgutov@HIDDEN, monnier@HIDDEN, 48841 <at> debbugs.gnu.org, > 47711 <at> debbugs.gnu.org > Date: Sat, 14 Aug 2021 14:12:31 +0200 > > Stefan just reminded me (in a different bug report) that we've long > meant to extend the text property machinery with a "namespace" or > "plane" concept. The impetus for this is really the font locking > machinery which wants to manage some text properties that other packages > also want to manage. > > The idea is that the display machinery would combine all the planes > before displaying, but each package would just manage its own "plane". > If we had something like this, then using this mechanism in the > completion context would make sense -- we could then say that completion > isn't allowed to alter anything except text properties in its private > plane. How can that work if at display time all the "planes" are combined? It would mean that the code which produced the original strings will get them displayed differently after completion. Anyway, I'm not sure why you are talking about display here: the properties which are supposed to store the information about completion aren't supposed to affect display.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 14 Aug 2021 12:12:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 14 08:12:46 2021 Received: from localhost ([127.0.0.1]:43757 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mEsWs-000168-1M for submit <at> debbugs.gnu.org; Sat, 14 Aug 2021 08:12:46 -0400 Received: from quimby.gnus.org ([95.216.78.240]:60890) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <larsi@HIDDEN>) id 1mEsWq-00015s-7p; Sat, 14 Aug 2021 08:12:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=0UbbhNCk79EjpLVHOt6hx3/gHrhJ7w9EVHreQXcmOmM=; b=BH2dmC+23gOI7SFNcwIj5Z8c5/ wkI9ex0yyU6NSnPqlJd/i4K71qa6frp2RdleRovoYKHAODzMfMra3TYC+G4KDjb3mCLqXK4KKq5N6 RvhQ13CyKxpF1ei1JreFEIIqef0neg38gPSm2QJhfi1oxK9FLpg/sRlvWMjdaLuAR32w=; Received: from [84.212.220.105] (helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <larsi@HIDDEN>) id 1mEsWe-0000TL-42; Sat, 14 Aug 2021 14:12:36 +0200 From: Lars Ingebrigtsen <larsi@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> <837dgob6yo.fsf@HIDDEN> Date: Sat, 14 Aug 2021 14:12:31 +0200 In-Reply-To: <837dgob6yo.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 14 Aug 2021 14:29:03 +0300") Message-ID: <87wnootec0.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.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 @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii <eliz@HIDDEN> writes: > Text properties are stored separately from the string, so I don't > think adding properties can in general be referred to as "change". > > Whether in some particular situation that could count as a [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: mail@HIDDEN, =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, 48841 <at> debbugs.gnu.org, dgutov@HIDDEN, monnier@HIDDEN, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii <eliz@HIDDEN> writes: > Text properties are stored separately from the string, so I don't > think adding properties can in general be referred to as "change". > > Whether in some particular situation that could count as a "change" > depends on that situation and on the particular property, of course. > I'm not sure in the context of completion there's any reason to count > as "change" adding properties that don't affect display. It is a destructive change, but we may just declare that completion functions are allowed to destructively change the inputs in certain very prescribed ways. I'd rather avoid that, though, if at all possible, because it may lead to subtle bugs all over the place. Stefan just reminded me (in a different bug report) that we've long meant to extend the text property machinery with a "namespace" or "plane" concept. The impetus for this is really the font locking machinery which wants to manage some text properties that other packages also want to manage. The idea is that the display machinery would combine all the planes before displaying, but each package would just manage its own "plane". If we had something like this, then using this mechanism in the completion context would make sense -- we could then say that completion isn't allowed to alter anything except text properties in its private plane. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 14 Aug 2021 11:29:40 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 14 07:29:40 2021 Received: from localhost ([127.0.0.1]:43683 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mErr5-0006JF-Qu for submit <at> debbugs.gnu.org; Sat, 14 Aug 2021 07:29:40 -0400 Received: from eggs.gnu.org ([209.51.188.92]:60850) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1mErr0-0006Iv-6Q; Sat, 14 Aug 2021 07:29:34 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47960) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mErqu-0006q2-Cr; Sat, 14 Aug 2021 07:29:24 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2620 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mErqt-0007lR-5U; Sat, 14 Aug 2021 07:29:24 -0400 Date: Sat, 14 Aug 2021 14:29:03 +0300 Message-Id: <837dgob6yo.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> In-Reply-To: <87y29471ov.fsf@HIDDEN> (message from =?utf-8?B?Sm/Do28g?= =?utf-8?B?VMOhdm9yYQ==?= on Sat, 14 Aug 2021 11:36:32 +0100) Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <87y29471ov.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: mail@HIDDEN, 47711 <at> debbugs.gnu.org, monnier@HIDDEN, 48841 <at> debbugs.gnu.org, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: João Távora <joaotavora@HIDDEN> > Date: Sat, 14 Aug 2021 11:36:32 +0100 > Cc: Daniel Mendler <mail@HIDDEN>, > Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, > 47711 <at> debbugs.gnu.org > > > And in the example above, the values are those that the > > lispref/objects.texi says we should not change (though it gives > > (symbol-name 'cons) as example). "Not mutable", in its parlance. IIRC > > the related discussions mentioned that modifying such values could > > lead to a segfault in some previous Emacs versions. Maybe not anymore, > > but it's still not a good idea. > > You're extrapolating "change" to also include attaching properties to > symbols. I think that document just means that you can't do stuff like > > (aset "cons" 0 ?z) > > or > > (aset (symbol-name 'cons) 0 ?z) > > I don't think it means you can't > > (put-text-property 0 1 'joaot/muahahah 42 (symbol-name 'cons)) > > But maybe Eli or someone else more knowledgeable in the deep internals > of Emacs can correct me. Text properties are stored separately from the string, so I don't think adding properties can in general be referred to as "change". Whether in some particular situation that could count as a "change" depends on that situation and on the particular property, of course. I'm not sure in the context of completion there's any reason to count as "change" adding properties that don't affect display.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 14 Aug 2021 11:22:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 14 07:22:16 2021 Received: from localhost ([127.0.0.1]:43675 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mErk0-000684-AV for submit <at> debbugs.gnu.org; Sat, 14 Aug 2021 07:22:16 -0400 Received: from mail-wr1-f49.google.com ([209.85.221.49]:45664) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1mErjw-00067h-K4; Sat, 14 Aug 2021 07:22:14 -0400 Received: by mail-wr1-f49.google.com with SMTP id v4so9665078wro.12; Sat, 14 Aug 2021 04:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2lzMRiTN9L+ibgaMoQVjLU1cDSXr8p2TDREAUlYpyHw=; b=KtOGOSadTAivI+sMaG6Z6n5tKwV9ww1gyYmNIGTGVZyB97ya1xbDJRnwcp0kzKRZEY PoNmwXjiN84dxzXXdFsLHZu1dY+dFGi8R+G7VsmF9uu75doIV470wK+vvrNkIGqq5oF7 5lXdH2Zh87DLnGcJWdKBHcoSyjd4NDQ54LKV96L/lCRfqUtrWjC2IEgBG8CnZBX/LVse Ge/J716dgLZRPAGc9w0Pg4X5tYrIVs7if5uWoY04HN0OQ42Hq3L9HIAtXaoT1kwoF8Vq ZfznUT8rQWZZEA50PfQhafBRFekQ+zBB+4N3WW2a5D48rjEUVEaxUnb1zKX8Qtxk+LVd YErw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=2lzMRiTN9L+ibgaMoQVjLU1cDSXr8p2TDREAUlYpyHw=; b=dfPwo/eCR6EhPrIzmHuvvv2z/+3RiB3BL5GJU7psxKEWglwZY+MelPg/7InHoF1C2F XQTY8yYAyKsBBxRcSSpb0tEgGiwLMg1AVnu28OXDWCDqiYs2wg4IH+7Q1wlDqo3wR1ZM PoLwudx744Lbh1EScmPHWOc1C5nOVA7lBhOm4qB6qYyNOJnLntHO1TBqA0trcAvCHvG9 vG9ECTnNVytY7e2ukBDICfLhCe4fjeIto10DmM442xQrlqfi1RTqtiBN3R8tlL3lcpsm AWAha/yueYlnE43yJ8NQgrX0I3BvoLnsU1bN3/vhJUATlXq1WXdcmTJ89gojqf/frn4n lL2A== X-Gm-Message-State: AOAM533B540ekMmbfMcfwwVHVzpDJYcrGbRmNq8CI3zwJAy4vletyysy goddsQyHDv4WAT5dFtbWduf10t6/YhI= X-Google-Smtp-Source: ABdhPJzjf7FPFGHs13PIjXxd+flbf6DnhuFohEbMnGizSM9H9gQDNOAyBHclQjs/QeqAc28qCLDrEA== X-Received: by 2002:a05:6000:18a4:: with SMTP id b4mr8133637wri.162.1628940126633; Sat, 14 Aug 2021 04:22:06 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id q75sm4370937wme.40.2021.08.14.04.22.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 Aug 2021 04:22:05 -0700 (PDT) Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Eli Zaretskii <eliz@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> <83h7fsbitl.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <1982cc2e-f955-7f15-0781-65cdbbe96759@HIDDEN> Date: Sat, 14 Aug 2021 14:22:04 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <83h7fsbitl.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 47711 Cc: mail@HIDDEN, 47711 <at> debbugs.gnu.org, joaotavora@HIDDEN, 48841 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.6 (/) On 14.08.2021 10:12, Eli Zaretskii wrote: >> From: Dmitry Gutov <dgutov@HIDDEN> >> Date: Sat, 14 Aug 2021 05:47:43 +0300 >> Cc: Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, >> 47711 <at> debbugs.gnu.org >> >> I thought I explained the problem with this previously. >> >> It's basically this: we cannot mutate what we don't own. Across all of >> completion functions out there, there will be such that return "shared" >> strings (meaning, not copied or newly allocated) from their completion >> tables. And modifying them is bad, with consequences which can present >> themselves in unexpected, often subtle ways. >> >> Since up until now completion-pcm--hilit-commonality copied all strings >> before modifying, completion tables such as described (with "shared" >> strings) have all been "legal". Suddenly deciding to stop supporting >> them would be a major API breakage with consequences that are hard to >> predict. And while I perhaps agree that it's an inconvenience, I don't >> think it's a choice we can simply make as this stage in c-a-p-f's >> development. > > This sounds like an argument against Daniel's approach as well, no? > Because if a completion API returns strings it "doesn't own", there > will be restrictions on Lisp programs that use those strings, because > those Lisp programs previously could do anything they liked with those > strings, and now they cannot. Or am I missing something? Good question. It is not. The completion tables described above have all been doing "legal" things, in our general understanding. But any callers of completion-all-completions were never really allowed to modify the returned strings (those still were strings that code "doesn't own"). Of course, some of those callers (I don't know any, though) might have taken advantage of being able to modify the strings with impunity because of completion-all-completions' implementation detail, but they'll have a chance to clean up their act when switching to completion-filter-completions. >> 1. (setq s (symbol-name 'car)) >> >> 2. (put-text-property 1 3 'face 'error s) >> >> 3. Switch to a buffer in fundamental mode >> >> 4. (insert (symbol-name 'car)) --> see the error face in the buffer >> >> Now imagine that some completion table collects symbol names by passing >> obarray through #'symbol-name rather than #'all-completions, and voila, >> if the completion machinery adds properties (any properties, not just >> face) to those strings, you have just modified a bunch of global values. >> That's not good. > > How is this different from Daniel's proposal of returning the original > strings? AFAIU, he just shifts the responsibility from the completion > code to the caller of the completion code, but basically leaves the > problem still very much real and pretty much into our face. This is a shift of responsibility in the right direction. The callers might as well do the string copying when needed, but the fact of the matter is, they usually only need to "copy" 20-100 strings (or however many is displayed), if they need to modify them at all. That's where we win: copying 100 strings is better than copying 10000. Gotta run now, will reply to other email later.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 14 Aug 2021 10:36:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 14 06:36:53 2021
Received: from localhost ([127.0.0.1]:43633 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1mEr21-0002iS-B9
for submit <at> debbugs.gnu.org; Sat, 14 Aug 2021 06:36:53 -0400
Received: from mail-wr1-f54.google.com ([209.85.221.54]:37387)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>)
id 1mEr1s-0002i1-Db; Sat, 14 Aug 2021 06:36:44 -0400
Received: by mail-wr1-f54.google.com with SMTP id r6so16717117wrt.4;
Sat, 14 Aug 2021 03:36:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:cc:subject:references:date:in-reply-to:message-id
:user-agent:mime-version:content-transfer-encoding;
bh=Bh27k0LEsx5DFXwN7gWYs7DxXUNYaLIjbu6ommRbxA8=;
b=kY3CHHhQPgxYfZeYOt4QG8fG3N2dFqnffJS3kMYkIjvl+wEvD+BS/sHE2NuChbqzAa
D4HElyd6MqwzNTwVJaeT6FQ6LKwoqIKm4g0yKJ3oQpeBsg4se6oPjNTzKkumbkDBYGpr
pjpnT5CF3bNOU14bbK7Z2PbQs0inEKQOge+OABAkZsSrm69W2Hp4yc5MSP9N6BQzM9Ay
LK/z2biTj28/xjdOe/Q7EGHgiTIdxCks/Rm5TSYR+fIYJAtdABmAaXaKpNb0Qh/aDkrt
YhWQHObfly+w0+D5TeJFYHrObATriUCqu6NsJcCTmE+SqBx+ywu14VGjwCJE0W4iVReh
6oKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
:message-id:user-agent:mime-version:content-transfer-encoding;
bh=Bh27k0LEsx5DFXwN7gWYs7DxXUNYaLIjbu6ommRbxA8=;
b=GFi1kooyF9K6kD5WOhruUZCsgahBUr/OtCP0+7FSU4jMRgCUT6On70fIkPBpX0QiVd
DSQF9O01zrwPhfVtlaTtoNwZIdsEYL8sSU48VjrsGEuylvv0ScV16TI78DjjF6Gl4MPW
7uc0ZaMetXeX0R9jmqJZS/KK1VfAE6oeFERbBdiSB12UiNLyK6uPZORmgaZI0h3okVnV
ExRZsX7kjA47zhr9wEv9fN2+wJiXGarW4fHTn6qL74nzAB44Cfi85e89eUF1La2eEqjq
Y5VoXqiAZfNBlt1o+FIzmxdM7uAGXnUBVrUqOXYHwfeGAsfJrj4SXO9x9g7JgotTECeH
UlHQ==
X-Gm-Message-State: AOAM531Hp91nzm9zqA0llTP2Yx2Ujt2//uZ1QKC4J1UNmCeNa/NwU7Lk
bhax5eEIMhKH6PrY6j4mit5GwNMgdfM=
X-Google-Smtp-Source: ABdhPJzhS09Z/f61UZIaCPeue+OeZ21p0Mzyvuu4983LqVr6GkAUSlSIt2ZLLV39lmhe7drkDbsGBg==
X-Received: by 2002:adf:e107:: with SMTP id t7mr7755483wrz.165.1628937394463;
Sat, 14 Aug 2021 03:36:34 -0700 (PDT)
Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132])
by smtp.gmail.com with ESMTPSA id z137sm4350807wmc.14.2021.08.14.03.36.33
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sat, 14 Aug 2021 03:36:33 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#47711: [PATCH VERSION 2] Add new
`completion-filter-completions` API and deferred highlighting
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN>
<fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN>
<3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN>
<CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN>
<56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN>
<CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN>
<38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN>
<CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN>
<9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN>
<CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN>
<8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN>
Date: Sat, 14 Aug 2021 11:36:32 +0100
In-Reply-To: <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> (Dmitry Gutov's
message of "Sat, 14 Aug 2021 05:47:43 +0300")
Message-ID: <87y29471ov.fsf@HIDDEN>
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: 47711
Cc: Daniel Mendler <mail@HIDDEN>,
Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org,
47711 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Dmitry Gutov <dgutov@HIDDEN> writes:
> It's basically this: we cannot mutate what we don't own. Across all of
> completion functions out there, there will be such that return
> "shared" strings (meaning, not copied or newly allocated) from their
> completion tables. And modifying them is bad, with consequences which
> can present themselves in unexpected, often subtle ways.
I agree with this premise. But would you call putting a uniquely named
text property in them a modification or mutation of said strings? I
don't.
> Since up until now completion-pcm--hilit-commonality copied all
> strings before modifying, completion tables such as described (with
> "shared" strings) have all been "legal".
Again, if I take one of this shared strings, in whichever environment
running row now, and I secretly attach a privatte "joaot/blargh"
property to it, there is very very low likelyhood that that will hurt
anybody.
You seem to be worrying about re-setting the 'face' property (a public
property by excellence) and that's the very same bug I experienced and
have described early. It's not even a hard bug to see. Just remove the
copy-sequence in `completion-pcm--hilit-commonality' and see strange
stuff happening.
But if you set some other property, _that_ bug _doesn't_ occur. Do some
other bugs occur? I don't know, I don't think we'll ever know, for
_any_ change.
Furthermore, there are other ways to forego the copying in
`completion-pcm--hilit-commonality and not even touch _ANY_ string
property.
> Suddenly deciding to stop supporting them would be a major API
> breakage with consequences that are hard to predict. And while I
> perhaps agree that it's an inconvenience, I don't think it's a choice
> we can simply make as this stage in c-a-p-f's development.
>
> To give an example of a subtle consequence:
>
> 1. (setq s (symbol-name 'car))
>
> 2. (put-text-property 1 3 'face 'error s)
>
> 3. Switch to a buffer in fundamental mode
>
> 4. (insert (symbol-name 'car)) --> see the error face in the buffer
It's not even subtle :-) Yes this is why have seen from the beginning in
bug#48841. I think it was even I who reported it to you.
The principle to follow can be summarized as this: "Don't touch values
of properties you don't own in objects you don't own."
So just don't touch the 'face' property in things you don't own! But
feel free to touch the "dmitry/blargh" property even in objects you
don't own.
So 'c-p--h-l' doesn't "own" face. So it must either create an object
that it owns or set something that it does own. 'completion-score' is
"owned" by 'c-p--h-l'. Only it can write it (though others can read
it).
> Now imagine that some completion table collects symbol names by
> passing obarray through #'symbol-name rather than #'all-completions,
> and voila, if the completion machinery adds properties (any
> properties, not just face) to those strings, you have just modified a
> bunch of global values. That's not good.
Why? Maybe I'm missing something. Why is adding properties -- that
no-one but the completion machinery knows about -- to those shared
strings "not good"? What bad thing can happen if I do?
> And in the example above, the values are those that the
> lispref/objects.texi says we should not change (though it gives
> (symbol-name 'cons) as example). "Not mutable", in its parlance. IIRC
> the related discussions mentioned that modifying such values could
> lead to a segfault in some previous Emacs versions. Maybe not anymore,
> but it's still not a good idea.
You're extrapolating "change" to also include attaching properties to
symbols. I think that document just means that you can't do stuff like
(aset "cons" 0 ?z)
or
(aset (symbol-name 'cons) 0 ?z)
I don't think it means you can't
(put-text-property 0 1 'joaot/muahahah 42 (symbol-name 'cons))
But maybe Eli or someone else more knowledgeable in the deep internals
of Emacs can correct me.
If indeed I'm wrong, there are other ways to forego the copying in
`c-p---hilit-commonality` and still don't incurr in any such "mutation".
We must keep our eyes on the prize: copying -- not property-attaching --
is the real bummer here.
scratch/icomplete-lazy-highlight-attempt-2, although still incomplete,
is one such approach, though it still sets `completion-score` on the
"shared" string, used later for sorting. But also that could be
prevented (again, only if it turns out to be actually problematic IMO).
Jo=C3=A3o
PS: Maybe I've not stated it clearly enough: I *don't* object to -- or
endorse -- Daniel's patch. My point was solely that it mixes too many
things for me to be intellectually able to review its functional merits,
and that those things should be separated into multiple problems and
patches to make this evaluation easier. Maybe someone with superior
intellecutal capacity can review -- on substance -- as it stands.
See my other reply containing benchmarks. Daniel's patch doesn't
perform well there, but for all I know, it can co-exist with my
non-copying approach, and we can all have our cake.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 14 Aug 2021 09:48:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 14 05:48:52 2021
Received: from localhost ([127.0.0.1]:43575 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1mEqHX-0007bT-Rc
for submit <at> debbugs.gnu.org; Sat, 14 Aug 2021 05:48:51 -0400
Received: from mail-wm1-f49.google.com ([209.85.128.49]:53088)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>)
id 1mEqHO-0007at-6L; Sat, 14 Aug 2021 05:48:42 -0400
Received: by mail-wm1-f49.google.com with SMTP id f10so5259283wml.2;
Sat, 14 Aug 2021 02:48:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:cc:subject:references:date:in-reply-to:message-id
:user-agent:mime-version;
bh=IS4QwsDKH6F4eWyXx6K0rL7ucoThMsH5rpcQmB+fRc8=;
b=OJdEtXu9nvilRpB8PfhTS6L2QOIUYP043g1Fv82poBBkAx3FMobRNV1sXK/U6hBEuz
CKZNa6is7lzW4Tc8z0noc1ahwfzUYbJu8Qo2MiDd5klm3iID/SnCbJ+BYOgX3ZYUPBGK
TnJrQV1xxyrmdgekIX5EmLf2LoCJHWkWIOPldExlzNAGIpGurhdpVN4wZtU2/Ik4QaiC
6vdRwmIGFh6WJWO7XhZjO9M+2FLA/OuyI8Mf3VozvOW1idEThkzIyRiJNb7OpeTdFWAk
8jN8fsvCY/l8DMmY2i50pWkJ9BU5cV726+1CZ4YyRYHAkPTFvOU16GIxTUWcuKgqnQJN
WF/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
:message-id:user-agent:mime-version;
bh=IS4QwsDKH6F4eWyXx6K0rL7ucoThMsH5rpcQmB+fRc8=;
b=DK8hkUSafjUj7HKuFo4qv4tNEUmLFRwhLN3rddJVozkV8G/tJ8S5f8AHWKyR7agxEu
A4hCPcrjHp9iexu1GSoqWHGZpFqLzav63fEkQTwLIaoNk/qGHP1xW+MQh4GzG9fvBrMh
DrHGm/ZG4CQwdmbb5iff6n2UlKGZZTt/L3KAx/QWb2RRrRSquqS6sZmkRaA4Ht8/Jyes
Fwk0B7jl0q22cTlxji/VcEsHf3Yadm09Joj8GWVPkotFYkEjWkmmqrO1OxkxEqYKeAhQ
6SRKGr3sgTauMPM/U7Rmo0kliW93TfixyKbcPVi3Dro7StRKP67J6IPCBDX6sF5d22Gz
bn4Q==
X-Gm-Message-State: AOAM532MiwwLhW9luFJ652V2YTeSeZbH3+gc2Vdf/XmOVqBtXUOODx90
I/S+h2kmUbxiX81Mmrvt4Ms=
X-Google-Smtp-Source: ABdhPJzMOTtxnVBtJYFETxD9xrGT4o4DfULs9PSItYoSoGFyQeGQPc+agS/dVtKe8a52F5XjCb+cug==
X-Received: by 2002:a1c:9852:: with SMTP id a79mr6632045wme.2.1628934512004;
Sat, 14 Aug 2021 02:48:32 -0700 (PDT)
Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132])
by smtp.gmail.com with ESMTPSA id c15sm3983732wrw.93.2021.08.14.02.48.30
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sat, 14 Aug 2021 02:48:31 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#47711: [PATCH VERSION 2] Add new
`completion-filter-completions` API and deferred highlighting
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN>
<fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN>
<3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN>
<CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN>
<56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN>
<CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN>
<38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN>
<CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN>
<9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN>
<83im08bjc3.fsf@HIDDEN>
Date: Sat, 14 Aug 2021 10:48:28 +0100
In-Reply-To: <83im08bjc3.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 14 Aug
2021 10:01:48 +0300")
Message-ID: <877dgo8ihf.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 47711
Cc: Daniel Mendler <mail@HIDDEN>, dgutov@HIDDEN,
monnier@HIDDEN, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Eli Zaretskii <eliz@HIDDEN> writes:
>> > On Fri, Aug 13, 2021 at 1:22 PM Daniel Mendler <mail@HIDDEN=
> wrote:
>> >=20
>> >> It is important to keep this property since this will preclude many b=
ugs
>> >> due to string mutation.
>> > I am aware of this, of course. Can you give examples of these "many b=
ugs"?
>> > Perhaps other than the one I already described and addressed?
>> No, Jo=C3=A3o, this is not how it goes. I don't have to prove to you th=
at
>> your idea introduces bugs. You have to show that mutation of the
>> completion table strings (which are not supposed to be mutated) will not
>> lead to bugs, which are hard to find.
> Please calm down, both of you. No one has to prove anything to anyone
> here, that's not how Emacs development works. We need to see which
> idea is better, and if none is significantly better, we will probably
> have both of them living side by side.
>
> And while asking for an example of potential bugs is reasonable,
> asking for a proof that a change will NOT lead to bugs isn't.
As far as I remember, I have done the first. I found bugs and addressed
them. I cannot _prove_ that my change will not leads to bugs indeed:
no-one can with any change. I've just stated repeteadly that I'm not
aware of any such bugs. I can understand intuition" for bugs to a
certain extent (everyone has intuition), but this intuition must always
resolve into actual reality to be useful in the end.
> So how
> about a couple of examples where having original strings unchanged is
> important, which could then be discussed?
Good idea, so in the absence of any controlled benchmarks I did some of
my own, using the most controlled environment I could devise. I start
Emacs like so:
~/Source/Emacs/emacs/src/emacs -Q -f fido-mode -f fido-vertical-mode -l =
~/tmp/benchmark.el ~/tmp/benchmark.el
I prime the obarry with lots of symblos to make completion purposedly
slow:
(require 'cl-lib)
(cl-loop repeat 300000 do (intern (symbol-name (gensym))))
I attach the file. Then I try a run of 10 invocations of
;; Press C-u C-x C-e C-m quickly to produce a sample.=20=20
(benchmark-run (completing-read "" obarray))
This, I think, is a good representation of the responsiveness of the
completion system. It always prints well after I finish typing, so I
don't think I'm inducing any artificial slowdows while it waits for my
input. When not measuring quantitatively, I also feel the difference in
responsiveness between different approaches.
Summarized results with an assortment of Emacs builds.
- the current master (254dc6ab4ca8e6a549a795f9eaf45378ce51b61f).
20.25 seconds total
=20=20=20
- Applying Daniel's patch over 254dc6.
23.41 seconds total
=20=20=20
- The theoretical best situation where we don't highlight in
completion-pcm--hilit-commonality (like 254dc6, but just removed
the copy-sequence)
10.70 seconds total
- Experimental patch published in
scratch/icomplete-lazy-highlight-attempt-2 (not finished, still
needs a way for frontends to opt into the optimization).
10.80 seconds total
I invite you all to reproduce these results.
In conclusion, I don't think Daniel's patch is going in the right
direction, *performance-wise*, for the kind of responsiveness scenarios
that I am concerned with, and which were discussed with Dmitry in
bug#48841. It seems to slow down the process by about 10%.
Note 1: there may be *other* performance scenarios that I am not aware
of, where Daniel's patch excels. I've requested these benchmarks,
regrettably without any success.
Note 2: doesn't mean that there aren't *other* merits to Daniel's patch,
but I have not understood these yet. That is due to the stated fact
that the patch is very long, and seems to comprise performance
improvements, refactorings, and API redesign. It has no documentation
in manual and/or examples on how to use the new API.
>> >> Note that your idea also does not address the other issues which are
>> >> addressed by my patch.
>> >=20
>> > That's for sure. My patch idea addresses only that single problem.
>> > I think this is a good property of patches: to solve one thing, not ma=
ny.
>>=20
>> No, this is not necessarily true. This is only good if the problem is
>> solved in a way which is future proof. The idea of mutating the strings
>> is a hack and not a solution.
>
> Just to make sure we are on the same page: adding a text property to a
> string doesn't mutate a string. Lisp programs that process these
> strings will not necessarily see any difference, and displaying those
> strings will also not show any difference if the property is not
> related to display. So the assumption that seems to be made here,
> that adding a property is the same as mutating a string, is IMO
> inaccurate if not incorrect.
Yes, in Lisp it is very common to attach a "private" property to an
object. If no-one else knows about the existence of that property, then
attaching it is not harmful. Generally, of course: there are situations
where adding a private property brings side-effects to other parts of
the code. But IMO that other code is in the wrong, not the one that
adds properties.
Also, to be clear, attaching a different property (as in, not 'face') to
the completion string is only _one_ of the ways of the ways to bypass
copying. According to my measurements, performance doesn't seem to be
decided by property attachments, but by copying or not copying of the
character data of said strings in completion-pcm--hilit-commonality.
Jo=C3=A3o
--=-=-=
Content-Type: application/emacs-lisp
Content-Disposition: attachment; filename=benchmark.el
Content-Transfer-Encoding: quoted-printable
Content-Description: benchmark.el
(require 'cl-lib)
;; Introduce 300 000 new symbols to slow things down. Probably more
;; than most non-Spacemancs people will have :-)
(cl-loop repeat 300000 do (intern (symbol-name (gensym))))
(when nil
;; Press C-u C-x C-e C-m quickly to produce a sample
(benchmark-run (completing-read "bla" obarray))
;; scratch/icomplete-lazy-highlight-attempt-2 (dbfe6f72e3608db4488bbc9bbc=
22d876746b1012)
(cl-reduce #'+
'((1.060225172 4 0.40529085799999987)
(1.084274293 4 0.40401850100000036)
(1.075857223 4 0.4066735760000002)
(1.096181884 4 0.41024331699999994)
(1.090617755 4 0.4027740900000003)
(1.092172347 4 0.4073497049999997)
(1.064530759 4 0.40525715400000006)
(1.088796966 4 0.4075235989999997)
(1.052578979 4 0.39851351000000035)
(1.0952534230000002 4 0.4396319659999999))
:key #'car);; 10.800488801
;; Current situation origin/master (254dc6ab4ca8e6a549a795f9eaf45378ce51b=
61f)
(cl-reduce #'+
'((2.094681183 15 1.299947048)
(2.061771249 14 1.248384553000001)
(1.9915545579999998 14 1.1808336689999983)
(2.1072676080000003 15 1.2833755230000001)
(2.100205698 15 1.2943715630000003)
(1.940760815 14 1.1518027680000005)
(1.919338815 14 1.127410448)
(2.0683418259999997 14 1.272936392)
(1.9932618739999999 15 1.1983156959999999)
(1.969784269 17 1.140629235))
:key #'car) ;; 20.246967895000004
;; Daniel's patch from Mon, 12 Jul 2021 21:40:32 +0200
(cl-reduce #'+
'((2.371949053 12 1.0679449390000002)
(2.411950542 12 1.0926466229999985)
(2.3595232590000004 12 1.0562706020000006)
(2.386636212 12 1.0797333340000002)
(2.37649102 12 1.0579168220000001)
(2.315395413 12 0.9729727209999997)
(2.310257558 12 0.9982636050000004)
(2.283203076 12 0.9730703639999998)
(2.302582002 13 0.9867599240000002)
(2.292846619 15 0.9585957429999998))
:key #'car) ;; 23.410834754
;; Theoretical best (don't care about highlighting, so don't copy)
(cl-reduce #'+
'((1.090906703 4 0.40746227999999984)
(1.052931397 4 0.4143886020000007)
(1.114877434 4 0.42559067599999967)
(1.0578293460000001 4 0.40872522)
(1.086898854 4 0.4109444489999996)
(1.0749850980000002 4 0.41140822900000007)
(1.076554257 4 0.4121859250000002)
(0.998330274 4 0.3969351310000002)
(1.064626675 4 0.4286588339999997)
(1.079113392 4 0.44295618700000006))
:key #'car) ;; 10.69705343
)
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 14 Aug 2021 08:23:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 14 04:23:48 2021 Received: from localhost ([127.0.0.1]:43510 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mEoxF-0005O3-06 for submit <at> debbugs.gnu.org; Sat, 14 Aug 2021 04:23:48 -0400 Received: from mail-wr1-f49.google.com ([209.85.221.49]:36492) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1mEox5-0005NY-7j; Sat, 14 Aug 2021 04:23:39 -0400 Received: by mail-wr1-f49.google.com with SMTP id b13so16406279wrs.3; Sat, 14 Aug 2021 01:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=PbE/O458f4w1AgSVDgGeifvLtJWnYHfLvklmc66ifKw=; b=r4GFs6/YIoNbxO9A3AhZshKw8xKPXEi/GCsoOt5lD/zXIZpM4PN5Of0jkm5/MD40LB SMUM7p6C0w6y3voUSs52UydRmLrkM0b5KGQPF3FUkDnmIg8dz9Q3EjiK+jzqsGIKdnN2 ibfngZ3SqmKXAwkybP1fnLcmuKL3bNBfTJBPxRohx+mFHYBTiGCEN4T6wLlujbOkcXqW kZN/waUTySLyUJERyOs8+feDDU4zT6TPvi/usj22Y+rMp8J/m/iydEb9TsqoZUFqPrFm 8kKe7eUrrMtP+uRUyYD8kCwFqsWKQbSX3bufB1YoWRxBonZ+pDRdbFQMBFQEz5izjd3R XyVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=PbE/O458f4w1AgSVDgGeifvLtJWnYHfLvklmc66ifKw=; b=S7Vj7+9BJ0Xy25H7WuASDth3Q6fVU0VMVNO0H+tWZbBELCcTYRuaGfFLbxTZUHCuU+ cGE3kzEKOqFz3NCCcrAwx14U6zW43oszTaqmQc2RJdys6vyv2AGhvy3wuYYYNJzfyyG0 2hXRw/S4+Rrk1OKSS9PHg4WH9ukxZSIPRGajrkd+qzG7Z21IGx7ZxNAkzwfItlYV1XY5 zkecBvBbjqM599sd06u6QoKHGg1pbXvzknk3Vgj+CbhKdCUOKBbG2nr4/EQFmLbJxtzm MYWBtGNuBgamqYXW48LbzKIuk/ulqt262W2ipbHqzM8Cwqy5QDNH+IeYvg/ekYm16Xqz 5/lg== X-Gm-Message-State: AOAM532NYOQFPTnIyonOt0s6zM3IRmISYCtLsvuxCVYvz1izjrnP3Cgt WRfipPNgR6ru+2YMkgQccD9cTAkgFlc= X-Google-Smtp-Source: ABdhPJw13EjCIKhW4B0XX0PCwubNK8eU02A7Jj4+dq420uMlLn626Rrwj8Ocwoi2pBUWwsK9BH6wMg== X-Received: by 2002:adf:d085:: with SMTP id y5mr7301176wrh.209.1628929408907; Sat, 14 Aug 2021 01:23:28 -0700 (PDT) Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132]) by smtp.gmail.com with ESMTPSA id x18sm3687486wmc.17.2021.08.14.01.23.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 14 Aug 2021 01:23:27 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> Date: Sat, 14 Aug 2021 09:23:25 +0100 In-Reply-To: <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> (Dmitry Gutov's message of "Sat, 14 Aug 2021 05:55:17 +0300") Message-ID: <87sfzca0zm.fsf@HIDDEN> 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: 47711 Cc: Daniel Mendler <mail@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> writes: > Aside from the mutability/ownership issue, > > On 13.08.2021 15:05, Jo=C3=A3o T=C3=A1vora wrote: >> If one removes these lines, the process becomes much faster, but there i= s a >> problem with highlighting. My idea is indeed to defer highlighting by n= ot >> setting the 'face property directly on that shared string, but some >> other property >> that is read later from the shared string by compliant frontents. > > I haven't done any direct benchmarking, but I'm pretty sure that this > approach cannot, by definition, be as fast as the non-mutating one. > > Because you go through the whole list and mutate all of its elements, > you have to perform a certain bit of work W x N times, where N is the > size of the whole list. Let's call W the work that you perform N times in this istuation. In the non-mutation, let's call it Z. So W <=3D Z, because Z not only propertizes the string with a calculation of faces but _also copies its character contents_. Also I think it's better to start about copying rather than mutating. As Eli points out, putting a text property in a string (my idea) is not equivalent with "mutating" it. > Whereas the deferred-mutation approach will only have to do its bit > (which is likely more work, like, WWW) only 20 times, or 100 times, or > however many completions are displayed. And this is usually > negligible. I think you're going in the same fallacy you went briefly in the other bug report. The flex and pcm styles (meaning completion-pcm--hilit-commonality) has to go through all the completions when deciding the score to atribute to each completion that we already know matches the pattern. That's because this scoring is essential to sorting. That's a given in both scenarios, copying and non-copying. Then, it's true that only a very small set of those eventually have to be displayed to the user, depending on where wants she wants her scrolling page to be. So that's when you have to apply 'face' to, say 20 strings, and that can indeed be pretty fast. But where does the information come from? - Currently, it comes from the string's 'face' itself, which was copied entirely. - In the non-copying approach, it must come from somewhere else. One idea is that it comes from a new "private" property 'lazy-face', also in the string itselv, but which was _not_ copied. Another idea is just to remember the pattern and re-match it to those 20 strings. I think the second alternative is always faster. > However big the difference is going to be, I can't say in advance, of > course, or whether it's going to be shadowed by some other performance > costs. But the non-mutating approach should have the best optimization > potential when the list is long. Don't think so. I'm doing benchmarks, will post soon. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 14 Aug 2021 07:16:26 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 14 03:16:26 2021 Received: from localhost ([127.0.0.1]:43478 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mEnu6-0003di-ES for submit <at> debbugs.gnu.org; Sat, 14 Aug 2021 03:16:26 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51596) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1mEnu4-0003dS-7x; Sat, 14 Aug 2021 03:16:25 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44022) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mEntz-0001rd-33; Sat, 14 Aug 2021 03:16:19 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2898 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mEnty-0006r5-Iw; Sat, 14 Aug 2021 03:16:18 -0400 Date: Sat, 14 Aug 2021 10:16:08 +0300 Message-Id: <83fsvcbio7.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> (message from Dmitry Gutov on Sat, 14 Aug 2021 05:55:17 +0300) Subject: Re: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: mail@HIDDEN, 47711 <at> debbugs.gnu.org, joaotavora@HIDDEN, 48841 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Dmitry Gutov <dgutov@HIDDEN> > Date: Sat, 14 Aug 2021 05:55:17 +0300 > Cc: Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, > 47711 <at> debbugs.gnu.org > > On 13.08.2021 15:05, João Távora wrote: > > If one removes these lines, the process becomes much faster, but there is a > > problem with highlighting. My idea is indeed to defer highlighting by not > > setting the 'face property directly on that shared string, but some > > other property > > that is read later from the shared string by compliant frontents. > > I haven't done any direct benchmarking, but I'm pretty sure that this > approach cannot, by definition, be as fast as the non-mutating one. Daniel seems to think otherwise, AFAIU. > Because you go through the whole list and mutate all of its elements, > you have to perform a certain bit of work W x N times, where N is the > size of the whole list. > > Whereas the deferred-mutation approach will only have to do its bit > (which is likely more work, like, WWW) only 20 times, or 100 times, or > however many completions are displayed. And this is usually negligible. > > However big the difference is going to be, I can't say in advance, of > course, or whether it's going to be shadowed by some other performance > costs. But the non-mutating approach should have the best optimization > potential when the list is long. So I guess the suggestion to have a benchmark is still useful, because the estimations of which approach has better performance vary between you three. So maybe producing such benchmarks would be a good step?
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 14 Aug 2021 07:13:12 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 14 03:13:12 2021 Received: from localhost ([127.0.0.1]:43470 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mEnqy-0003XW-Im for submit <at> debbugs.gnu.org; Sat, 14 Aug 2021 03:13:12 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51076) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1mEnqx-0003X9-3n; Sat, 14 Aug 2021 03:13:11 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43950) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mEnqr-0007Pp-6e; Sat, 14 Aug 2021 03:13:05 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2698 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mEnqq-0006TB-UW; Sat, 14 Aug 2021 03:13:05 -0400 Date: Sat, 14 Aug 2021 10:12:54 +0300 Message-Id: <83h7fsbitl.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> (message from Dmitry Gutov on Sat, 14 Aug 2021 05:47:43 +0300) Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: mail@HIDDEN, 47711 <at> debbugs.gnu.org, joaotavora@HIDDEN, 48841 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Dmitry Gutov <dgutov@HIDDEN> > Date: Sat, 14 Aug 2021 05:47:43 +0300 > Cc: Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, > 47711 <at> debbugs.gnu.org > > I thought I explained the problem with this previously. > > It's basically this: we cannot mutate what we don't own. Across all of > completion functions out there, there will be such that return "shared" > strings (meaning, not copied or newly allocated) from their completion > tables. And modifying them is bad, with consequences which can present > themselves in unexpected, often subtle ways. > > Since up until now completion-pcm--hilit-commonality copied all strings > before modifying, completion tables such as described (with "shared" > strings) have all been "legal". Suddenly deciding to stop supporting > them would be a major API breakage with consequences that are hard to > predict. And while I perhaps agree that it's an inconvenience, I don't > think it's a choice we can simply make as this stage in c-a-p-f's > development. This sounds like an argument against Daniel's approach as well, no? Because if a completion API returns strings it "doesn't own", there will be restrictions on Lisp programs that use those strings, because those Lisp programs previously could do anything they liked with those strings, and now they cannot. Or am I missing something? > 1. (setq s (symbol-name 'car)) > > 2. (put-text-property 1 3 'face 'error s) > > 3. Switch to a buffer in fundamental mode > > 4. (insert (symbol-name 'car)) --> see the error face in the buffer > > Now imagine that some completion table collects symbol names by passing > obarray through #'symbol-name rather than #'all-completions, and voila, > if the completion machinery adds properties (any properties, not just > face) to those strings, you have just modified a bunch of global values. > That's not good. How is this different from Daniel's proposal of returning the original strings? AFAIU, he just shifts the responsibility from the completion code to the caller of the completion code, but basically leaves the problem still very much real and pretty much into our face.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 14 Aug 2021 07:02:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 14 03:02:23 2021 Received: from localhost ([127.0.0.1]:43465 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mEngR-0003HZ-FC for submit <at> debbugs.gnu.org; Sat, 14 Aug 2021 03:02:23 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50200) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1mEngH-0003H8-Ok; Sat, 14 Aug 2021 03:02:14 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43850) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mEngB-0006iO-5Y; Sat, 14 Aug 2021 03:02:03 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2015 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mEngA-0003L8-2Y; Sat, 14 Aug 2021 03:02:03 -0400 Date: Sat, 14 Aug 2021 10:01:48 +0300 Message-Id: <83im08bjc3.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Daniel Mendler <mail@HIDDEN> In-Reply-To: <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> (message from Daniel Mendler on Fri, 13 Aug 2021 14:56:38 +0200) Subject: Re: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: 48841 <at> debbugs.gnu.org, dgutov@HIDDEN, joaotavora@HIDDEN, monnier@HIDDEN, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Daniel Mendler <mail@HIDDEN> > Date: Fri, 13 Aug 2021 14:56:38 +0200 > Cc: 47711 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, > 48841 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN> > > On 8/13/21 2:37 PM, João Távora wrote: > > On Fri, Aug 13, 2021 at 1:22 PM Daniel Mendler <mail@HIDDEN> wrote: > > > >> It is important to keep this property since this will preclude many bugs > >> due to string mutation. > > > > I am aware of this, of course. Can you give examples of these "many bugs"? > > Perhaps other than the one I already described and addressed? > > No, João, this is not how it goes. I don't have to prove to you that > your idea introduces bugs. You have to show that mutation of the > completion table strings (which are not supposed to be mutated) will not > lead to bugs, which are hard to find. Please calm down, both of you. No one has to prove anything to anyone here, that's not how Emacs development works. We need to see which idea is better, and if none is significantly better, we will probably have both of them living side by side. And while asking for an example of potential bugs is reasonable, asking for a proof that a change will NOT lead to bugs isn't. So how about a couple of examples where having original strings unchanged is important, which could then be discussed? > >> Note that your idea also does not address the other issues which are > >> addressed by my patch. > > > > That's for sure. My patch idea addresses only that single problem. > > I think this is a good property of patches: to solve one thing, not many. > > No, this is not necessarily true. This is only good if the problem is > solved in a way which is future proof. The idea of mutating the strings > is a hack and not a solution. Just to make sure we are on the same page: adding a text property to a string doesn't mutate a string. Lisp programs that process these strings will not necessarily see any difference, and displaying those strings will also not show any difference if the property is not related to display. So the assumption that seems to be made here, that adding a property is the same as mutating a string, is IMO inaccurate if not incorrect. And once again: please tone down your responses, both of you. TIA.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 14 Aug 2021 06:45:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 14 02:45:31 2021 Received: from localhost ([127.0.0.1]:43457 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mEnQB-0002rU-M3 for submit <at> debbugs.gnu.org; Sat, 14 Aug 2021 02:45:31 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48858) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1mEnQ7-0002r6-Sw; Sat, 14 Aug 2021 02:45:28 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43728) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mEnQ1-0000b7-A2; Sat, 14 Aug 2021 02:45:21 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4976 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mEnPz-0004qn-W4; Sat, 14 Aug 2021 02:45:20 -0400 Date: Sat, 14 Aug 2021 09:45:09 +0300 Message-Id: <83k0kobk3u.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Daniel Mendler <mail@HIDDEN> In-Reply-To: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> (message from Daniel Mendler on Fri, 13 Aug 2021 12:38:28 +0200) Subject: Re: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: dgutov@HIDDEN, monnier@HIDDEN, joaotavora@HIDDEN, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Daniel Mendler <mail@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, João Távora > <joaotavora@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, > Dmitry Gutov <dgutov@HIDDEN> > Date: Fri, 13 Aug 2021 12:38:28 +0200 > > I attached the overhauled patch, which addresses most of the comments by > Eli. In comparison to my last patch, the patch is fully backward > compatible and preserves all existing tests. As before, there are tests > which check the new functionality for each existing completion style. Thanks. You were faster than me, so I sent a few more comments to the old patch today.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 14 Aug 2021 06:27:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 14 02:27:21 2021 Received: from localhost ([127.0.0.1]:43443 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mEn8b-0002PJ-8q for submit <at> debbugs.gnu.org; Sat, 14 Aug 2021 02:27:21 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47728) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1mEn8Y-0002P1-Ah; Sat, 14 Aug 2021 02:27:20 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43570) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mEn8Q-0002HA-RY; Sat, 14 Aug 2021 02:27:10 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3865 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1mEn8Q-0005wA-CI; Sat, 14 Aug 2021 02:27:10 -0400 Date: Sat, 14 Aug 2021 09:27:00 +0300 Message-Id: <83mtpkbky3.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Daniel Mendler <mail@HIDDEN> In-Reply-To: <aff2bd3a-ea3e-1ac6-cf0d-2785c6591c84@HIDDEN> (message from Daniel Mendler on Thu, 12 Aug 2021 10:47:17 +0200) Subject: Re: bug#48841: [PATCH] Add new `completion-filter-completions` API and deferred highlighting References: <f94541d3-5f93-9a23-8256-3bbc453f127a@HIDDEN> <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <837dgrdrec.fsf@HIDDEN> <aff2bd3a-ea3e-1ac6-cf0d-2785c6591c84@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: 47711 <at> debbugs.gnu.org, monnier@HIDDEN, joaotavora@HIDDEN, 48841 <at> debbugs.gnu.org, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 48841 <at> debbugs.gnu.org, dgutov@HIDDEN, joaotavora@HIDDEN, > monnier@HIDDEN, 47711 <at> debbugs.gnu.org > From: Daniel Mendler <mail@HIDDEN> > Date: Thu, 12 Aug 2021 10:47:17 +0200 > > >> The `completions` value is the list of completion strings *without* > >> applied highlighting. The completion strings are returned unmodified, > >> which avoids allocations and results in performance gains for > > > > This is unclear: how can you return a list of strings which you > > produce without allocating the strings? > > The function 'completion-filter-completions' receives a completion table > as argument. The strings produced by this table are returned > unmodified, but of course the completion table has to produce them. For > a static completion table (e.g., in the simplest case a list of strings) > the completion table itself will not allocate strings. In this scenario > 'completion-filter-completions' will not perform any string allocations, > only the list will be allocated. This is what leads to major > performance gains. My point was that at least some of this should be in the description, otherwise it will leave the reader wondering. > >> +(defvar completion--filter-completions nil > >> + "Enable the new completions return value format. > > > > Btw, why is this an internal variable? Shouldn't all completion > > styles ideally support it? If so, it should be a public variable, > > documented in the ELisp manual. And the name should also end with -p, > > since it's a boolean. How about completion-filter-completions-format-p? > > (As I understood the style guide '-p' is not a good idea for boolean > variables, since a value is not a predicate in a strict sense.) > > To address your technical comment - this variable is precisely what one > of the technical difficulties mentioned in my other mail is about. The > question is how we can retain backward compatibility of the completion > style 'all' functions, e.g., 'completion-basic-all-completions', while > still allowing the function to return the newly introduced alist format > with more data, which enables 'completion-filter-completions' to perform > the efficient deferred highlighting. I understand, but given that we provide this for other packages, it shouldn't be an internal variable. > > Also, the "This function has been superseded..." part should be a new > > paragraph, so that it stands out. (And I'm not yet sure we indeed > > want to say "superseded" here, but that's part of the on-going > > discussion. maybe use a more neutral language here, like "See also".) > > The new API 'completion-filter-completions' will substitute the existing > API 'completion-all-completions'. That's your hope, and I understand. But we as a project didn't yet decide to deprecate the original APIs, so talking about superseding is premature. > > Is "filter" really the right word here (in the doc string)? "Filer" > > means you take a sequence and produce another sequence with some > > members removed. That's not what this API does, is it? Suggest to > > use a different name, like completion-completions-alist or > > completion-all-completions-as-alist. > > "Filter" seems like exactly the right word to me. The function takes a > list of strings (or a completion table) and returns a subset of matching > completion strings without further modifications to the strings. See > above what I wrote about allocations. But the name says "filter completions". Which would mean you take a list of completions and filter out some of them. A completion table is much more general object than a list of strings. Thus, I think using "filter" here is sub-optimal. > >> +Only the elements of table that satisfy predicate PRED are considered. > >> +POINT is the position of point within STRING. The METADATA may be > >> +modified by the completion style. The return value is a alist with > >> +the keys: > >> + > >> +- base: Base position of the completion (from the start of STRING) > > > > "Base" here means the beginning? If so, why not call it "beg" or > > somesuch? > > Base position is a fixed term which is already used in minibuffer.el for > completions. See also 'completion-base-position' for example. Well, we don't have to keep bad habits indefinitely. It's okay to lose them and use better terminology. Or at least to explain that terminology in parentheses the first time it is used in some context. > > Are we really losing the completion-score property here? If so, why? > > Yes, the property is removed in the current patch. It is not actually > used for anything in the new implementation. But it is possible to > restore the property such that 'completion-all-completions' always > returns scored candidates as it does now. See my other mail regarding > the caveats of the current patch. I'd prefer not to lose existing features, because that'd potentially make the changes backward-incompatible. Thanks.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 14 Aug 2021 03:11:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 13 23:11:36 2021 Received: from localhost ([127.0.0.1]:43392 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mEk5A-0005ye-Bl for submit <at> debbugs.gnu.org; Fri, 13 Aug 2021 23:11:36 -0400 Received: from mail-wr1-f48.google.com ([209.85.221.48]:40583) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1mEk58-0005yJ-2K; Fri, 13 Aug 2021 23:11:34 -0400 Received: by mail-wr1-f48.google.com with SMTP id k29so15760049wrd.7; Fri, 13 Aug 2021 20:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=8qJF3v8JbwJAZ15jhDdtLSeHlHSTougNt1Um+Emevgs=; b=uhb3Yu2G/KwF7e23ESrN4j/Fh07Y51CsdrtrHwzY2W3mXnf2hTJ+nyFKDVb1cB09t0 utWlFJEmCtPOi1lSSISjfuadcx1seTUW8FNXGAaXP5GYHuCrgxhEkyoeckULXB6hYw1d hcMvXWlpglvE1U6x6dBxhqqoIqspz8DoK5OFzxfkWH+VOFzUb6sncRrvYWMd8FcL3riD LYupotBinwmXxXkps3k3UKa+IArjNeeQ2/uLlBOSckA5X0FT+wanYvp8tuwcWDbT4VW9 Php/VN8Fu0s0SkbB3WNC4779V6VFZgYoovzxA2+33u//UtCPTPUdPX4iszORMtaq10TC tZrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=8qJF3v8JbwJAZ15jhDdtLSeHlHSTougNt1Um+Emevgs=; b=WQ1H4EbH4EBesGEw0wHtd400mwrs92osOVMjjQS6bKOq1DgBNSZ1KkttUCw5401CLQ W2sTz3+tIB4ClHZw3QIM0lOgleBfPRJZ17yei489eI/448D/YnGgO0Y6HP6Paf7IJ6M6 Lboe/kXXMTljbtRK+JZxXA1PSil9uyzBqkb3JW8v+rIT5zkBLXuNNQBgDZx25U02BJ/u AMWT+SPigIwEnyx+XJ1o4F5utwEQMZNt0PIFtiqn6OLArZv/0cGwPwpDqw3O1hqtCYby 55S8SrGaju4iC2mjMmWQJqEdJE79D7Ty+UfdacCoq9/4WH5H7GJA+8/8e1vlSIgL+GUl OVyg== X-Gm-Message-State: AOAM530YfUQaXZJZVwpeDnHEmo8GDF4SVgH5Gk3XV9KcnbXOKmbabtL2 sVBNDKeYQ//8MXSUpsICGxxQgiUBchc= X-Google-Smtp-Source: ABdhPJxsO782oJW6/wOSeAg58zlmFyQfHKUIV+YHUBe0p3NUhjFYEMpSgTKZfhOE8W+l2fTU/YsL6Q== X-Received: by 2002:a5d:42c2:: with SMTP id t2mr6137986wrr.49.1628910688214; Fri, 13 Aug 2021 20:11:28 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id z126sm3235705wmc.11.2021.08.13.20.11.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Aug 2021 20:11:27 -0700 (PDT) Subject: Re: bug#48841: [PATCH] Add new `completion-filter-completions` API and deferred highlighting To: Daniel Mendler <mail@HIDDEN>, "emacs-devel@HIDDEN" <emacs-devel@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <5dba40c7-681b-392d-486a-ae71090d27f4@HIDDEN> Date: Sat, 14 Aug 2021 06:11:26 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 47711 Cc: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.6 (/) Hi Daniel, I haven't yet read the patch in detail, but it sounds like a move in the right direction (even if it doesn't include the long-overdue overhaul of the whole API). A few notes on the new stuff: > Finally the `highlight` value is a function taking a list of completion strings and returns a new list of new strings with highlighting applied. First of all, I'd really like it to be a function that applies to individual completion strings, not the whole collection. That would make it much easier to use in company-capf without having to rewrite a lot of code in the presentation layer. Second, perhaps instead of modifying the strings themselves it could return some data (like a list of faces-intervals tuples) that could be used to do so? Again, in company-capf's we end up parsing the face properties in the string, so those modifications are just extra work for CPU which we could eliminate. This is less critical, though. On 11.08.2021 19:11, Daniel Mendler wrote: > There are currently two issues with the patch with regards to backward > compatibility. Fortunately they are fixable with a little effort. > > 1. I would like to deprecate `completion-score' or remove it altogether, > but unfortunately `completion-score' is used in the wild. In order to > preserve `completion-score', bind `completion--filter-completions' in > the highlighting functions. Add `completion-score' in > `completion-pcm--hilit-commonality' when > `completion--filter-completions' is nil. And third: I think completion-score could ultimately use the same treatment as 'highlight'. Meaning, being returned up the stack together with completions, so other bits of code could look up those values. I don't have a clear picture of this yet, but see the recently filed bug#49888. If we want to be able to combine matching scores with recency scores, simply sorting the completions after matching is not going to cut it. Not sure if this is something we can tackle now, but keeping this possible evolution in mind could help us make good choices in the current migration.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 14 Aug 2021 02:55:27 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 13 22:55:27 2021 Received: from localhost ([127.0.0.1]:43376 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mEjpW-0005Zq-Vc for submit <at> debbugs.gnu.org; Fri, 13 Aug 2021 22:55:27 -0400 Received: from mail-wr1-f45.google.com ([209.85.221.45]:41909) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1mEjpV-0005ZW-9A; Fri, 13 Aug 2021 22:55:25 -0400 Received: by mail-wr1-f45.google.com with SMTP id x10so9434671wrt.8; Fri, 13 Aug 2021 19:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=RrMsSouFaapPEAk74ymKj85jn+NHe8o5ot//bYK6Y7U=; b=COd7ecBI7d9wbKFTROI+mvyr0iWMzOONcICvbmCVXLgz+ledAdeUe7APuGkKWgY+Jd cKsB6Jw6eN/FU+3FG1D22/HfwNJ37eVjpsMDWYBDzOFQ33B+gnUrNiWG7HAPSPBVy+TD LIFLJl9g1H6dWbm0aNq9GbrEMbmydt6KJElf76D0Y0ryFayy2XtAhagdDsb82l7IM0Gv AXgGm9CDZUH2mKmqSHTwx0ylFJGJ6STudzscB+U0ktueqX+C9ZE/CBlb8qtoKEikHWHf 5Gig5+TFtb6dIWj1juymBsPFdhWkzWF3UrFHfF+Squ/YfPDI9z/3SpouUUAv8unDrq2J 2rqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=RrMsSouFaapPEAk74ymKj85jn+NHe8o5ot//bYK6Y7U=; b=H8t6MI28Sl2fTK2O/up2bWmS2nA5jTdWxCXMHw/hgaQ8CJ6IjlrgyieaUq18wfzWaP ormbF0YU/riADgVwyVjUdLGqLVopAtKUIudbrwehAa/era4Ni968D0EdyYJEViHr+kMY xI7UEMU4t37EeV7+U2HFf03vpDFyKHoeB5H0zRIbikpvCjBIp4+iS3/kO9q7ySMDW6Er N36ABqbcjdD7heNtjBHKRsLSyO5mkUkr8hxCJe/cVkG1brBWeD21cdduhgd2+KDOIQtg M/RJTlyur1ts58M5pHNttNRB8Q5M0j0hLy6kTHRfYeJw1VQQYb/EyckDzT9cCXFkvrJh 4CqQ== X-Gm-Message-State: AOAM533+KR1BiRY9V2JtmxhPQVfKusq2NE2SrPcn9jFrhGB1VypJuezz xcLAqjo8jnh1E/Qz3ZjR+4Hk+9kaqD0= X-Google-Smtp-Source: ABdhPJxpWonVHMT/qpjjgzVsfYxYiCwu8gMPFaSBLngN8O5F+J1FfE4DFsuty8mw7DKIAbbIYwXJGw== X-Received: by 2002:adf:9c8c:: with SMTP id d12mr6159409wre.71.1628909719415; Fri, 13 Aug 2021 19:55:19 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id i21sm3353014wrb.62.2021.08.13.19.55.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Aug 2021 19:55:19 -0700 (PDT) Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, Daniel Mendler <mail@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <328f87eb-6474-1442-e1ca-9ae8deb2a84a@HIDDEN> Date: Sat, 14 Aug 2021 05:55:17 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 47711 Cc: Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.6 (/) Aside from the mutability/ownership issue, On 13.08.2021 15:05, João Távora wrote: > If one removes these lines, the process becomes much faster, but there is a > problem with highlighting. My idea is indeed to defer highlighting by not > setting the 'face property directly on that shared string, but some > other property > that is read later from the shared string by compliant frontents. I haven't done any direct benchmarking, but I'm pretty sure that this approach cannot, by definition, be as fast as the non-mutating one. Because you go through the whole list and mutate all of its elements, you have to perform a certain bit of work W x N times, where N is the size of the whole list. Whereas the deferred-mutation approach will only have to do its bit (which is likely more work, like, WWW) only 20 times, or 100 times, or however many completions are displayed. And this is usually negligible. However big the difference is going to be, I can't say in advance, of course, or whether it's going to be shadowed by some other performance costs. But the non-mutating approach should have the best optimization potential when the list is long.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 14 Aug 2021 02:47:54 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 13 22:47:54 2021 Received: from localhost ([127.0.0.1]:43369 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mEjiD-0005Oo-Rr for submit <at> debbugs.gnu.org; Fri, 13 Aug 2021 22:47:54 -0400 Received: from mail-wm1-f45.google.com ([209.85.128.45]:40490) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1mEjiC-0005OW-1a; Fri, 13 Aug 2021 22:47:52 -0400 Received: by mail-wm1-f45.google.com with SMTP id f12-20020a05600c4e8c00b002e6bdd6ffe2so5160108wmq.5; Fri, 13 Aug 2021 19:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=YJw6OlV4lASsh/tUTN6SzIwACHP933YFdLTFK0MkuqM=; b=Vidv7X/VQNIy18MEfGR9+nO2HYx3p9uH5yds3+TK7an4SST2+36hNaFlToeGos1yzU ZXPEaOpJzr5nAm2atp8TRLaxcrJx59uNbGTcfk7ElXQLM6craANPxqMRQ/TJbw12OkVS lC0+2s9E6OgAmxOnj8t2Qhui612cejdqTiSIhupU9/FRSTtmV0qUYMJmda0IWsImEzbn DKsFPCnqf7m0sx09tPSKXKlkBvncG41XVJ6Cq3K5sANAomQJa8sH4P9GAr6+2fVnmIX9 w8xO/J7VMNT6j80LLgl56LJNAtV57ifHaDToXoKmypw3CPOhSfbrl6x7N0bZIfhRQ7xR 2TFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=YJw6OlV4lASsh/tUTN6SzIwACHP933YFdLTFK0MkuqM=; b=nR1zS8Nn309e6wVeitw1G4GtSPeEcG9GrIwjnVhWO70ig2C6FOM97NZkOHB4MyExCs X/DPOTnUIk77LeUS5ETxtYZRizhEKjozvMkKAiWOH2VOxkBTWoJpsbeZaq+BtGp+eKeb hWvDeoVOCZ4faOBObfh9j2PgNAW6clgferd+ak0/cx8HUE1Hg706HUK32wirZWauT4zm kXzquiRez+FniGAL7lf5pkd26FbkrmgB03mTjrER/KDSwJUHGzKVEOdhV5LJ1EvlTmox JC592hdQW9AUDUNbVJncKNQoJ7tR8XDlj9TeiZ/OFnLqvYBmYDc5LvJDilhju+ZeA8n/ yhLw== X-Gm-Message-State: AOAM531g56FoYOaYmEL8muZY8+YnZJw7nkYCU37bqilNQgOB1iu8oIO1 4oK+xKI7C2XpW2L5of8woHtOyR7P9XU= X-Google-Smtp-Source: ABdhPJzxplFEaS0USQ1x53CqyR9NU8Z7vLpfrynY2I7Tg+tlEzk6uUD8ELyaLrcjfBvTR/qCtD+o/w== X-Received: by 2002:a1c:a743:: with SMTP id q64mr5205240wme.74.1628909266069; Fri, 13 Aug 2021 19:47:46 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id l2sm3072055wme.28.2021.08.13.19.47.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Aug 2021 19:47:45 -0700 (PDT) Subject: Re: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, Daniel Mendler <mail@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <8a36e61a-1c5b-bf3b-a454-077348589c4f@HIDDEN> Date: Sat, 14 Aug 2021 05:47:43 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 47711 Cc: Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.6 (/) Hi folks, Sorry I'm late to this party. On 13.08.2021 16:36, João Távora wrote: >>>> By separating the filtering and mutation >>>> (highlighting, scoring) my patch addresses the problem at hand in the >>>> proper way. >>>> [ ... ] >>>> Mutation would be a reasonable choice here if the problem could not be >>>> solved in a proper way. But in fact it can be solved in a proper way >>>> without mutating the strings at all as my patch shows. >>> "proper" is just an reasonably empty adjective. There are different ways to >>> go about this, of course. What's "proper" and isn't is hard to debate >>> objectively. >> You are contradicting yourself here. You agree that string mutation is >> better be avoid. If we define "proper" as avoids string mutation if this >> is easily possible, then my patch implements a proper solution to the> problem. > I didn't say it's better avoided, though of course I will avoid_any_ change if > I can. I said I have identified one drawback with doing it. Then I > have addressed > that drawback. So that's what I said. > > I am unaware of_other_ drawbacks. They might exist, but I am unaware of > them. Perhaps you are, and indeed you state they exist, but you refuse to > let me know about them. Or perhaps others know of them and will let me know. > In my long-running discussion with Dmitry they were not presented (again, > except for the one I identified). I thought I explained the problem with this previously. It's basically this: we cannot mutate what we don't own. Across all of completion functions out there, there will be such that return "shared" strings (meaning, not copied or newly allocated) from their completion tables. And modifying them is bad, with consequences which can present themselves in unexpected, often subtle ways. Since up until now completion-pcm--hilit-commonality copied all strings before modifying, completion tables such as described (with "shared" strings) have all been "legal". Suddenly deciding to stop supporting them would be a major API breakage with consequences that are hard to predict. And while I perhaps agree that it's an inconvenience, I don't think it's a choice we can simply make as this stage in c-a-p-f's development. To give an example of a subtle consequence: 1. (setq s (symbol-name 'car)) 2. (put-text-property 1 3 'face 'error s) 3. Switch to a buffer in fundamental mode 4. (insert (symbol-name 'car)) --> see the error face in the buffer Now imagine that some completion table collects symbol names by passing obarray through #'symbol-name rather than #'all-completions, and voila, if the completion machinery adds properties (any properties, not just face) to those strings, you have just modified a bunch of global values. That's not good. And in the example above, the values are those that the lispref/objects.texi says we should not change (though it gives (symbol-name 'cons) as example). "Not mutable", in its parlance. IIRC the related discussions mentioned that modifying such values could lead to a segfault in some previous Emacs versions. Maybe not anymore, but it's still not a good idea.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 13 Aug 2021 14:37:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 13 10:37:52 2021 Received: from localhost ([127.0.0.1]:42852 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mEYJk-0008N8-0X for submit <at> debbugs.gnu.org; Fri, 13 Aug 2021 10:37:52 -0400 Received: from server.qxqx.de ([178.63.65.180]:42485 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1mEYJh-0008Mn-4w; Fri, 13 Aug 2021 10:37:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=xG1wTRTLJhDNwXgVcJFmihoxCZwFJ4j6Wekup9FM4LM=; b=w8l5uwURr2DI8wfigMtIRnxeqk XJjqcryeSPLognhKMP8t7idXRiybmfBIhfmDcAk0T0QQZ/gs58g/Ava2RVZMTKDabQ26uPZdz8zXQ 5v9yaXw+fkdL9H2JxFxGERF90chAe7wGIpHbtp8F/7pcfLg1OBsYao8/z/z/4FYZ5b4Q=; Subject: Re: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <ea37de5b-909a-6467-a274-df193429dabd@HIDDEN> <CALDnm52eYiC1Hb2+Emj+_a27ODscCq=gM_s0hWY15332-mN2Dw@HIDDEN> From: Daniel Mendler <mail@HIDDEN> Message-ID: <61963a69-1b1c-a635-97dc-a665ecb07a6b@HIDDEN> Date: Fri, 13 Aug 2021 16:37:38 +0200 MIME-Version: 1.0 In-Reply-To: <CALDnm52eYiC1Hb2+Emj+_a27ODscCq=gM_s0hWY15332-mN2Dw@HIDDEN> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: Dmitry Gutov <dgutov@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) On 8/13/21 4:11 PM, João Távora wrote: > On Fri, Aug 13, 2021 at 3:03 PM Daniel Mendler <mail@HIDDEN> wrote: > >>> Without facts to back it up, I have to take this as gratuitous disparagement. >>> Nicht so gut. >> >> João, your whole answers are "nicht so gut" or not useful. What is your >> point? Please give constructive technical feedback instead of such >> empty phrases. > > Look, you disparaged an idea of mine without absolutely any facts. I don't think > that's good. "Nicht so gut" was a lighthearted way of pointing it out. > Lighten up. > Post the benchmarks you say you have and stop the pompous handwaving. João, the way you argue is not in any way "lighthearted". It also depends on what the other party receives as the message. And here you just repeat this style by calling my reasoning "pompous handwaving". This is not a fair way to discuss. In contrast my arguments were generally of a technical nature. I propose we both calm down a bit and let others chime in here. Daniel
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 13 Aug 2021 14:11:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 13 10:11:47 2021 Received: from localhost ([127.0.0.1]:42799 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mEXuU-0005Xf-Q9 for submit <at> debbugs.gnu.org; Fri, 13 Aug 2021 10:11:46 -0400 Received: from mail-pl1-f171.google.com ([209.85.214.171]:36497) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1mEXuT-0005XO-29; Fri, 13 Aug 2021 10:11:45 -0400 Received: by mail-pl1-f171.google.com with SMTP id f3so12149386plg.3; Fri, 13 Aug 2021 07:11:45 -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=eUEMG04mECiWu+Pg/59yRQTqKhWPV24mxZW+MGMR83g=; b=e0f+5n9o+qdDSb6F+N45qk8yKvmMSb2FY0vmM6rOqaQ9Of2rVABsOw2yLQmY1B55RM xHfmICGG/kxNCAEieMkU0QAsM2Unu1ed14G1om4axInaVgwLGIez0yHGwSNFkGRT70ga 1QCFtv5Q+j66S1hQoWh+ZQNoJ0y9xHKXSvisZUZRaavrATVjtkF3TBk14aXrWLqtoBIK mwBpxpbYWzOaaONZjQAbAQhHMD8sKQ9BNiRNVLu7Iz/bpPh04kSvZSXzYE96MdokBnl2 zUY1ALHN61ayUWTMkkqancqmZ/RgHXM9RWdgt+DrbRzKSX17hvauxv+OrR19KcmSUQhx 2mgw== 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=eUEMG04mECiWu+Pg/59yRQTqKhWPV24mxZW+MGMR83g=; b=J/9AhrCpLYmciMdutRi9PDAJajvqL/gilhZdFhaXGr2ADnMBmc9qEAH198VozeP1v4 6XTttn6CRnlPbnKg9UGrAmz9HmSkWUyxTBYkhaK8IIpBsEoNm0FIgEmyt3SR4ZqfLgHq NV32ZrN7xropCfI0xmSz3mitrTJkQ/DMKN5ZzDXkXxvmy6pRIckUTIQ7LWS1EqfHnyRi tAQmT/novzlG9cHZQ5o8HTUWNUuQSclIbEmVplEe0C37yi3vYK6uvyG+ToUK0FjTNGKT ezQ1Xl2R/vxcQv3/U1tsOwAPESkhwj+IKzb1KIQWJ3MkiV+RcfeeNtxtON8zYOelSdLG VAyw== X-Gm-Message-State: AOAM532ALRMS4yIKbKle8NmtPEbllZ4lSqVlD8eB8GWn5LVcVqSbmMv6 s4N9pJUY/0XfYgNwZDAdhiccWf19JhMtTsg1jsM= X-Google-Smtp-Source: ABdhPJwpc22f6+4Nexy2mgyEQcZGioFJ083PVKOOgX27jXzg9BK7q63Zr5o/xaX4+lJyfg9OXQ4JKsxOZ5QXUcxfbR8= X-Received: by 2002:a17:90a:a091:: with SMTP id r17mr2830007pjp.56.1628863899134; Fri, 13 Aug 2021 07:11:39 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> <ea37de5b-909a-6467-a274-df193429dabd@HIDDEN> In-Reply-To: <ea37de5b-909a-6467-a274-df193429dabd@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Fri, 13 Aug 2021 15:11:27 +0100 Message-ID: <CALDnm52eYiC1Hb2+Emj+_a27ODscCq=gM_s0hWY15332-mN2Dw@HIDDEN> Subject: Re: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Daniel Mendler <mail@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Dmitry Gutov <dgutov@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Fri, Aug 13, 2021 at 3:03 PM Daniel Mendler <mail@HIDDEN> wro= te: > > Without facts to back it up, I have to take this as gratuitous disparag= ement. > > Nicht so gut. > > Jo=C3=A3o, your whole answers are "nicht so gut" or not useful. What is = your > point? Please give constructive technical feedback instead of such > empty phrases. Look, you disparaged an idea of mine without absolutely any facts. I don't = think that's good. "Nicht so gut" was a lighthearted way of pointing it out. Lighten up. Post the benchmarks you say you have and stop the pompous handwaving. Bye, Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 13 Aug 2021 14:03:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 13 10:03:44 2021 Received: from localhost ([127.0.0.1]:42776 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mEXme-0005KK-Tz for submit <at> debbugs.gnu.org; Fri, 13 Aug 2021 10:03:44 -0400 Received: from server.qxqx.de ([178.63.65.180]:52349 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1mEXmV-0005Jq-Ns; Fri, 13 Aug 2021 10:03:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=U+7jHgcxqSUV0RHeOu3QFSoRtGe0iLwvU6TC36yrcVI=; b=EcPIMUnEp4uE8O01Mqno6vFAsl rUQgFBQ6At+ydR0XwESZnD/Q1mhooK6GNCJmS6WcUPXOPRR//qIGlTuFIPoxXHXt5ps4KrGh8Fs0W muuQwa8s1CF0tqEG9JJpzW/GomDGoT7mDRug2LZ73hg4xE0AWTjiLc32Ot2ecxPYC9EI=; Subject: Re: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> From: Daniel Mendler <mail@HIDDEN> Message-ID: <ea37de5b-909a-6467-a274-df193429dabd@HIDDEN> Date: Fri, 13 Aug 2021 16:03:21 +0200 MIME-Version: 1.0 In-Reply-To: <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: Dmitry Gutov <dgutov@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) On 8/13/21 3:36 PM, João Távora wrote: >> You are contradicting yourself here. You agree that string mutation is >> better be avoid. If we define "proper" as avoids string mutation if this >> is easily possible, then my patch implements a proper solution to the> problem. > > I didn't say it's better avoided, though of course I will avoid _any_ change if > I can. I said I have identified one drawback with doing it. Then I > have addressed > that drawback. So that's what I said. > > I am unaware of _other_ drawbacks. They might exist, but I am unaware of > them. Perhaps you are, and indeed you state they exist, but you refuse to > let me know about them. Or perhaps others know of them and will let me know. > In my long-running discussion with Dmitry they were not presented (again, > except for the one I identified). In the discussion with Dmitry, I already pointed out that there is an alternative principled approach implemented by my Vertico UI, which is in fact the same approach as implemented in this patch. If there are other useful conclusions from the discussion I will adopt them here for this patch. >>> That's for sure. My patch idea addresses only that single problem. >>> I think this is a good property of patches: to solve one thing, not many. >> No, this is not necessarily true. This is only good if the problem is >> solved in a way which is future proof. > > OK, but what thing of the future, real or academic, do you envision that > would bring back the problem, or create other problems? > >> The idea of mutating the strings is a hack and not a solution. > > Without facts to back it up, I have to take this as gratuitous disparagement. > Nicht so gut. João, your whole answers are "nicht so gut" or not useful. What is your point? Please give constructive technical feedback instead of such empty phrases. >> In contrast, I am presenting a >> future-proof new API as solution which addresses multiple problems. > > That's the issue. The completion system is very complex and there are many > good ideas, different, floated by many people. But if you make a patch to > address "multiple" fuzzily-described problems, it's hard to judge how good > your ideas even are! Maybe they are indeed very good, I never said > they weren't. No need to get worked up about it! > > Again, my proposal is to first focus on the performance problems caused by > string allocation. _That_ problem is well understood, at least by me (but it > would help to settle on convenient benchmarks understood by others, too). > Then we can go from there. No, it is not the correct approach to fix larger issues by applying localized patches. We both have identified the string allocations and highlighting as problem. My patch resolves the problem, by exposing just the right pieces of the already existing completion machinery. More about this below. >> you look at the patch, only 196 new lines are added to minibuffer.el. >> Furthermore the patch adds 213 lines of new tests. > > It's a large patch, over 1000 lines. One does not review a patch > merely by looking at > lines added, when one needs to read much more, to understand implications, etc. > It needs documentation, for one, much more than just docstrings, on > how to use the > new API. I suggest you take a step back here and try to understand the high-level idea first. It seems that you are misjudging the complexity of the patch. The minibuffer completion machinery is already constructed such that filtering and highlighting are separate. If you look at `completion-basic-all-completions` for example, there is first a filtering step and then the highlighting is applied in a second step by the function `completion-hilit-commonality`. This separation exists for all completion styles. My patch does nothing else than separating these two processing steps. The new API `completion-filter-completions` returns the filtered list and a function to apply highlighting afterwards only to the actually displayed candidates where highlighting is needed. In contrast your idea totally misses this. > Maybe others review patches on other aspects that's fine. Maybe > others will. Eli reviewed on minor formatting and documentation aspects. I am looking forward to more reviews by other people. Your desire for benchmarks is understandable, but I doubt that it will lead to progress in the discussion here and I doubt that it will convince you. The outcome of the benchmark is the following - my patch only filters and does not mutate the strings, so it will be slightly faster than your idea where the strings are mutated first and afterwards the mutation has to be undone again. However the mutations are of course not expensive, so the differences will be small. The discussion we should be having here is about technical details and internals and not about the numbers which won't give any guidance in this case regarding the correct API design. You seem to always come back to the "scientific method". Note that there is not only statistics, there is only "scientific reasoning" and mathematics, which allows to reason about transformations and drawing conclusions from that. If you don't do this, you are only doing half of the science. Daniel
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 13 Aug 2021 13:36:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 13 09:36:42 2021 Received: from localhost ([127.0.0.1]:40915 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mEXMX-0008CF-SH for submit <at> debbugs.gnu.org; Fri, 13 Aug 2021 09:36:42 -0400 Received: from mail-pl1-f179.google.com ([209.85.214.179]:43911) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1mEXMV-0008Bw-1X; Fri, 13 Aug 2021 09:36:40 -0400 Received: by mail-pl1-f179.google.com with SMTP id e19so12007291pla.10; Fri, 13 Aug 2021 06:36:38 -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=tvhjGLLU6CrPIl2BruGEyiA2A8Y1z7e+RBKklFm3qaY=; b=WO6Qd/orW+L6sc7R1/ProxKfGtNTRSoLWOpPCBg2HsS4hNQN0IfFCM9vtuwahg7YSc y5j9j8J5pFb7pZXkCmI5hJO73LhiVAQA9zwBpVbTCh5w41gt7X/C7slXlMm8cxfhzZVk t78oUsxDQXpqMBzVTKenBQTnAQC5LAvIUruT4OBagHR7s35sQXBrrAwUqkjHjz6UcyYa uBdIxbgTQ/wP9xejKyFASJfY4Xlvv45tPw55SXPaqn3qXjJ6Q5j4VBnpfDA8GH+Cr+zQ PmvqBJHw0y+T5zUd5debsLzFCMKOAkYZQ+zl8/YuyaW0TUIAetq0n859qgTHbpcNY27E uEAQ== 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=tvhjGLLU6CrPIl2BruGEyiA2A8Y1z7e+RBKklFm3qaY=; b=nr+vEnLGKC33Ilcv1/hcPHgqXiNnUKl+mvSF94J3uwqYpp/Ne2P+cJzvzNwfZpw92k cdfkGO2BM96+oxkMY+QffGxZDEKJXBfG2p/BodDe+Xvl1MrZJMqXQWma0LRdtZ7Ey0GC Va2bOGXHhocqRmn4pGVW8HDObXeOsF2ZXRDZk7ECgiyjMb30j4eGOSJpjTwXF5CHQQ65 HMzjz2e08rrA80Y7LAnOo9IjPlPzimx4FfJVbWaZi2Rfa1HunW5WdhJKVDqiJ8t5UjBP 9P22quEBpM+96aq0KYdjgIK8MvYA7ISrKT80Ujv5wOWJwUhgDcjHNu2MS1ucGLO5gBi1 1nsA== X-Gm-Message-State: AOAM531aKxIK6KX97S4/wGTRppidvp8nrLKDrhYgnZ+xSMX6Vzu5Ulaz ZFeANigcxIyqNHQaoxKIf+cxQsigik5eI8TlwB8= X-Google-Smtp-Source: ABdhPJyqcaYJLJRUlMaexDe0u7Fuq1zPF1MfteXDQLEs+nt9W0IdOoXkavODVEBpwkrwjUcylKHzniBr4TbNfnLRSis= X-Received: by 2002:aa7:9050:0:b029:3af:7e99:f48f with SMTP id n16-20020aa790500000b02903af7e99f48fmr2534645pfo.2.1628861793055; Fri, 13 Aug 2021 06:36:33 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> In-Reply-To: <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Fri, 13 Aug 2021 14:36:21 +0100 Message-ID: <CALDnm508EK5qM+AaOOJiNDm-=ORCuOieYpkjO=OSRas+_WTFwQ@HIDDEN> Subject: Re: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Daniel Mendler <mail@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Dmitry Gutov <dgutov@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) didnOn Fri, Aug 13, 2021 at 1:56 PM Daniel Mendler <mail@HIDDEN> wrote: > > On 8/13/21 2:37 PM, Jo=C3=A3o T=C3=A1vora wrote: > > On Fri, Aug 13, 2021 at 1:22 PM Daniel Mendler <mail@HIDDEN>= wrote: > > > >> It is important to keep this property since this will preclude many bu= gs > >> due to string mutation. > > > > I am aware of this, of course. Can you give examples of these "many bu= gs"? > > Perhaps other than the one I already described and addressed? > > No, Jo=C3=A3o, this is not how it goes. I don't have to prove to you tha= t > your idea introduces bugs. So you just say it and I have to believe it? Then I could say the same to you, right? I won't of course, that would be silly. You have to show that mutation of the > completion table strings (which are not supposed to be mutated) will not > lead to bugs, which are hard to find. > > In contrast with the new API `completion-filter-completions` this entire > class of bugs is avoided by construction of the API. Furthermore the > `completion-filter-completions` API is easy to use in comparison to your > idea, where "compliant" backends have to apply string manipulations to > apply the highlighting and revert the strings back to their old pristine > state. The only thing the API user has to do is to call the `highlight` > function returned in the alist by `completion-filter-completions`. > > >> By separating the filtering and mutation > >> (highlighting, scoring) my patch addresses the problem at hand in the > >> proper way. > >> [ ... ] > >> Mutation would be a reasonable choice here if the problem could not be > >> solved in a proper way. But in fact it can be solved in a proper way > >> without mutating the strings at all as my patch shows. > > > > "proper" is just an reasonably empty adjective. There are different wa= ys to > > go about this, of course. What's "proper" and isn't is hard to debate > > objectively. > > You are contradicting yourself here. You agree that string mutation is > better be avoid. If we define "proper" as avoids string mutation if this > is easily possible, then my patch implements a proper solution to the> pr= oblem. I didn't say it's better avoided, though of course I will avoid _any_ chang= e if I can. I said I have identified one drawback with doing it. Then I have addressed that drawback. So that's what I said. I am unaware of _other_ drawbacks. They might exist, but I am unaware of them. Perhaps you are, and indeed you state they exist, but you refuse to let me know about them. Or perhaps others know of them and will let me kno= w. In my long-running discussion with Dmitry they were not presented (again, except for the one I identified). > > That's for sure. My patch idea addresses only that single problem. > > I think this is a good property of patches: to solve one thing, not man= y. > No, this is not necessarily true. This is only good if the problem is > solved in a way which is future proof. OK, but what thing of the future, real or academic, do you envision that would bring back the problem, or create other problems? > The idea of mutating the strings is a hack and not a solution. Without facts to back it up, I have to take this as gratuitous disparagemen= t. Nicht so gut. > In contrast, I am presenting a > future-proof new API as solution which addresses multiple problems. That's the issue. The completion system is very complex and there are many good ideas, different, floated by many people. But if you make a patch to address "multiple" fuzzily-described problems, it's hard to judge how good your ideas even are! Maybe they are indeed very good, I never said they weren't. No need to get worked up about it! Again, my proposal is to first focus on the performance problems caused by string allocation. _That_ problem is well understood, at least by me (but = it would help to settle on convenient benchmarks understood by others, too). Then we can go from there. > you look at the patch, only 196 new lines are added to minibuffer.el. > Furthermore the patch adds 213 lines of new tests. It's a large patch, over 1000 lines. One does not review a patch merely by looking at lines added, when one needs to read much more, to understand implications, = etc. It needs documentation, for one, much more than just docstrings, on how to use the new API. > Jo=C3=A3o, you don't have to lecture me on these things. Of course I can > provide such numbers. Then please do! Not meaning to lecture you, just that your suggestion that I try Vertico UI as a substitution for these numbers seemed completely misguided. So if you have them (or "can provide them") let's see them. All I'm asking, preferably from Emacs -Q recipe. > You cannot reasonably make the claim that > `copy-sequence` is the problem and at the same time claim that my patch > does not solve the performance issues, when in fact my patch avoids this > exact string copying. I didn't say it didn't solve them! Now, where did I say that? I would like to see a benchmark so that I can witness it _and_ study alternative solutions. With that, there's a better chance that I will be persuaded there are none as elegant, clean, proper, pure, etc as yours! Maybe others review patches on other aspects that's fine. Maybe others will. Eli reviewed on minor formatting and documentation aspects. I review them on substance, using numbers and conducting my own experiments and tests. This takes time and help from the scientist on the other end. Simple and in summary, let's hope your next reply has some benchmarks so we can make progress. Thanks, Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 13 Aug 2021 12:57:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 13 08:57:03 2021 Received: from localhost ([127.0.0.1]:40820 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mEWk6-0002kW-V9 for submit <at> debbugs.gnu.org; Fri, 13 Aug 2021 08:57:03 -0400 Received: from server.qxqx.de ([178.63.65.180]:56345 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1mEWjw-0002k2-Bh; Fri, 13 Aug 2021 08:56:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=a89yZI6TfoUJ6rLAH1MakLAhc71tO9b1C8U/CHdpsC8=; b=N4MIoo3oh97UH6pQB1pEy7f66+ 9sONgkN7OIXHdBdyqVEavbTl7vLSVNa0DJfEcPc+jLn1uMcJhu7xLnmEPYWbWDt0Zjt5Xil5g4Qt5 sgbdZcDkgu7zBVoSKBaf+jKohOVq31IKqv9Yz5dnImPysQjXCqiE1zInTEHWiTn5Mu34=; Subject: Re: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> From: Daniel Mendler <mail@HIDDEN> Message-ID: <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@HIDDEN> Date: Fri, 13 Aug 2021 14:56:38 +0200 MIME-Version: 1.0 In-Reply-To: <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: Dmitry Gutov <dgutov@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) On 8/13/21 2:37 PM, João Távora wrote: > On Fri, Aug 13, 2021 at 1:22 PM Daniel Mendler <mail@HIDDEN> wrote: > >> It is important to keep this property since this will preclude many bugs >> due to string mutation. > > I am aware of this, of course. Can you give examples of these "many bugs"? > Perhaps other than the one I already described and addressed? No, João, this is not how it goes. I don't have to prove to you that your idea introduces bugs. You have to show that mutation of the completion table strings (which are not supposed to be mutated) will not lead to bugs, which are hard to find. In contrast with the new API `completion-filter-completions` this entire class of bugs is avoided by construction of the API. Furthermore the `completion-filter-completions` API is easy to use in comparison to your idea, where "compliant" backends have to apply string manipulations to apply the highlighting and revert the strings back to their old pristine state. The only thing the API user has to do is to call the `highlight` function returned in the alist by `completion-filter-completions`. >> By separating the filtering and mutation >> (highlighting, scoring) my patch addresses the problem at hand in the >> proper way. >> [ ... ] >> Mutation would be a reasonable choice here if the problem could not be >> solved in a proper way. But in fact it can be solved in a proper way >> without mutating the strings at all as my patch shows. > > "proper" is just an reasonably empty adjective. There are different ways to > go about this, of course. What's "proper" and isn't is hard to debate > objectively. You are contradicting yourself here. You agree that string mutation is better be avoid. If we define "proper" as avoids string mutation if this is easily possible, then my patch implements a proper solution to the problem. >>> The advantage that I see is that those adaptations apart, it is a small >>> localized and effective change. >> >> Note that your idea also does not address the other issues which are >> addressed by my patch. > > That's for sure. My patch idea addresses only that single problem. > I think this is a good property of patches: to solve one thing, not many. No, this is not necessarily true. This is only good if the problem is solved in a way which is future proof. The idea of mutating the strings is a hack and not a solution. In contrast, I am presenting a future-proof new API as solution which addresses multiple problems. If you look at the patch, only 196 new lines are added to minibuffer.el. Furthermore the patch adds 213 lines of new tests. > Look, one needs to evaluate things quantitively. Your patch is not > to Vertico, it's to Emacs. I'm concerned with changes to Emacs and their > effect on all completion frontends. So trying Vertico isn't very useful. > > If you're solving a performance problem (and it seems that you are, among > other things) we really need benchmarks, a description of an experiment whose > results can be reproduced independently. It's the normal scientific method. João, you don't have to lecture me on these things. Of course I can provide such numbers. You cannot reasonably make the claim that `copy-sequence` is the problem and at the same time claim that my patch does not solve the performance issues, when in fact my patch avoids this exact string copying. >>>> The second problem addressed by the new API >>>> `completion-filter-completions` is that `completion-all-completions` is >>>> limited in what it can return. For example it cannot return the end >>>> position of the completion. >>> >>> And why is this a problem? Can you post an example of something you'd >>> like to do, but can't? Regardless, it does seem indeed like a "second" problem >>> (as you state) so perhaps something that can be addressed separately. >> >> Please look at the FIXMEs in minibuffer.el which address this. >> Currently only the beginning position of the completion boundary is >> returned, which is only half of the information. > > OK. It does seem like a separate problem, so maybe open a new bug for it? There is already a FIXME in minibuffer.el, so I assume Stefan Monnier is well aware of these issues. It is an additional win of the new API that such open problems can be fixed too. As I see it, a new API is the way to go here. Daniel
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 13 Aug 2021 12:37:58 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 13 08:37:58 2021 Received: from localhost ([127.0.0.1]:40777 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mEWRi-00005M-Ad for submit <at> debbugs.gnu.org; Fri, 13 Aug 2021 08:37:58 -0400 Received: from mail-pj1-f54.google.com ([209.85.216.54]:50968) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1mEWRh-00004t-9k; Fri, 13 Aug 2021 08:37:57 -0400 Received: by mail-pj1-f54.google.com with SMTP id bo18so15156570pjb.0; Fri, 13 Aug 2021 05:37:57 -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=tlFNsJoHhRBkUHPWY4LrARaxXuMGniqUKbtu2G0qdXU=; b=W2jhGqYmQiddIO9xrhNq+mgLhNpZDrXgB7E3Nq9ikxl01hbFX3Xd7DKIjge5nk70Vk TJ6lEut6rRtmflXg2bZWmdKRLTVld535iIGhkPNPkR2iE5mzIBImO16T3hpJMGEAqQv7 Yhr8k8CWpX1DATiwscnuWOKn8mfY2+OzkPrdykjc/3wfXZb8o3M/yKk0NdfzqtI6ymFg 0kPcVTzA66bPapJPUHB8ZIrhZztHJy3tmpAGVeMOUngbv1wGsxMvUTRwlZe1YsLBzK6+ KKaqcpLVT2U+JgodurScZY/iVu9Yzg7kQaUXfr3xSsiXh8bXW9UwtkjVdPzFp2sSSxI8 eG/w== 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=tlFNsJoHhRBkUHPWY4LrARaxXuMGniqUKbtu2G0qdXU=; b=MSUMwNM1xDgUgyDOyycbk6t2dYHgo4sV0XHsatXgNpSvKZ9YH34CNMmfKZKZ19xLfW M7OfsOt3tHBGN3g95s2YqHPo6swiNlHncTqBJrwIhlJcrTT2Yqx8BiHduUuMGrutw5+h VUeHt52P8EcFYZFdgNbtZbLToqq+Mru0MghAtWGYwpI5CyRZYrKB2qesDKpv+vcfIwUs HqVtM54gdxBnGzPgKeGuu/W9kkqKyhdTwRmhsDGfwz8NTTfconxgRhFcjaOOvO6agmaz Y6MlnngG4cM0S3vjLFWM/gIDIcDQBZbxVY3BzPILmCN2m9RRa5DOVhWCY1DpRJ5s9kZN NgPA== X-Gm-Message-State: AOAM533LyFHgkB8NdTtQk9u31KuoZZ2wotSW8j8BVW/NqfHWrsnUup2m aSTQuKFoIbnP+NZEcJXQVbU1f7js7LJI7X9N18w= X-Google-Smtp-Source: ABdhPJydEtmy84BK6Wfd+Bbslze/kSoY9HX0jvqeGGlmCcf/udvaNVKD9YyLf4HvKp8/XJpyzqs4997sPyThwdhiEiE= X-Received: by 2002:a62:5c6:0:b029:341:e0b1:a72c with SMTP id 189-20020a6205c60000b0290341e0b1a72cmr2220586pff.71.1628858271491; Fri, 13 Aug 2021 05:37:51 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> In-Reply-To: <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Fri, 13 Aug 2021 13:37:38 +0100 Message-ID: <CALDnm537=LHAoaGqPpy7=JOPsYn=z+=Q6QW=b9bjrAWOtxqRaQ@HIDDEN> Subject: Re: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Daniel Mendler <mail@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Dmitry Gutov <dgutov@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Fri, Aug 13, 2021 at 1:22 PM Daniel Mendler <mail@HIDDEN> wro= te: > It is important to keep this property since this will preclude many bugs > due to string mutation. I am aware of this, of course. Can you give examples of these "many bugs"? Perhaps other than the one I already described and addressed? > By separating the filtering and mutation > (highlighting, scoring) my patch addresses the problem at hand in the > proper way. >[ ... ] > Mutation would be a reasonable choice here if the problem could not be > solved in a proper way. But in fact it can be solved in a proper way > without mutating the strings at all as my patch shows. "proper" is just an reasonably empty adjective. There are different ways t= o go about this, of course. What's "proper" and isn't is hard to debate objectively. > This solution is much more ad-hoc and you still mutate the string which > is not allowed. It's also difficult to debate "ad-hoc" or not. If you've studied the problem, what makes you say that mutating the string (in this case, adding a 'completion--style-face' property to it) is not allowed? What negative thin= gs would derive from it. > > The advantage that I see is that those adaptations apart, it is a small > > localized and effective change. > > Note that your idea also does not address the other issues which are > addressed by my patch. That's for sure. My patch idea addresses only that single problem. I think this is a good property of patches: to solve one thing, not many. We can make more patches to solve other problems, once we identify them clearly. > The new API `completion-filter-completions` > returns data which hasn't been available before, e.g., the end position, > which cannot be fixed given the existing API. > > >> The main problem is that `completion-all-completions` allocates all th= e > >> strings every time the completions are filtered. This is the same > >> performance issue you encountered in fido-mode/icomplete-mode. > > > > OK. I encountered at least two different performance problems there, wi= th > > quite different causes. So let's stick to the string-allocation problem= . Post > > a code snippet that demonstrates the problem the way you see it/experie= nce it? Look, one needs to evaluate things quantitively. Your patch is not to Vertico, it's to Emacs. I'm concerned with changes to Emacs and their effect on all completion frontends. So trying Vertico isn't very useful. If you're solving a performance problem (and it seems that you are, among other things) we really need benchmarks, a description of an experiment who= se results can be reproduced independently. It's the normal scientific method. Something like: "before my patch, this code takes 123 seconds to run, after my patch it takes 12." > >> The second problem addressed by the new API > >> `completion-filter-completions` is that `completion-all-completions` i= s > >> limited in what it can return. For example it cannot return the end > >> position of the completion. > > > > And why is this a problem? Can you post an example of something you'd > > like to do, but can't? Regardless, it does seem indeed like a "second"= problem > > (as you state) so perhaps something that can be addressed separately. > > Please look at the FIXMEs in minibuffer.el which address this. > Currently only the beginning position of the completion boundary is > returned, which is only half of the information. OK. It does seem like a separate problem, so maybe open a new bug for it? Jo=C3=A3o T=C3=A1vora
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 13 Aug 2021 12:23:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 13 08:23:10 2021 Received: from localhost ([127.0.0.1]:40705 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mEWDK-000850-Qv for submit <at> debbugs.gnu.org; Fri, 13 Aug 2021 08:23:10 -0400 Received: from server.qxqx.de ([178.63.65.180]:52851 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1mEWDB-000847-Ko; Fri, 13 Aug 2021 08:23:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=No8L/5f/jqE7VfR4Zr8RQeJNpAlnovp34dfprC2OpIA=; b=NVDxqieGZDnqxkTN6bD1l5Lybk XKH0kqn8ciZRmZw+/MId68EnF9wrXz5XBq9PW3+NEGcLSSbkH7oZ/LvNHUVkYBB3G2MrmqMEWev05 59CczGWRQCHXazW65/zaniWkgZYzTYafVKgjWRWtqAl9idZuD1K3RAOU5YOdF7dQHWx0=; Subject: Re: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> From: Daniel Mendler <mail@HIDDEN> Message-ID: <38a06f3c-4a7a-755c-c99b-708f91afabfa@HIDDEN> Date: Fri, 13 Aug 2021 14:22:48 +0200 MIME-Version: 1.0 In-Reply-To: <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: Dmitry Gutov <dgutov@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) On 8/13/21 2:05 PM, João Távora wrote: >> The existing API `completion-all-completions` >> necessarily has to allocate all the strings in order to attach >> highlighting and scoring. The new API solves this in a clean way by >> both deferring highlighting and scoring. > > I'm not sure you understand my alternative idea. As far as I > understand (and have actually measured) the lines: > > ;; Don't modify the string itself. > (setq str (copy-sequence str)) > > in minibuffer.el, in the function completion-pcm--hilit-commonality > > Are the cause of the problem that _I am talking about_ and that > I have actually measured. Again you may be referring to a > _different_ problem that I am unaware of. You are right that the call to `copy-sequence` is a major bottleneck in the filtering. However you are wrong that this line can simply be removed/disabled and the candidates can be modified. The API guarantees and has always guaranteed that the candidate strings are not mutated. It is important to keep this property since this will preclude many bugs due to string mutation. By separating the filtering and mutation (highlighting, scoring) my patch addresses the problem at hand in the proper way. Note that the UI also has no possibility to opt-out of the mutation. The UI is actually not the one being concerned about the mutation here, it is the backends (completion tables), which produce the strings. If one starts mutating these strings you will see bugs cropping up throughout Emacs where shared strings suddenly have spurious additional properties due to the completion filtering. Mutation would be a reasonable choice here if the problem could not be solved in a proper way. But in fact it can be solved in a proper way without mutating the strings at all as my patch shows. > If one removes these lines, the process becomes much faster, but there is a > problem with highlighting. My idea is indeed to defer highlighting by not > setting the 'face property directly on that shared string, but some > other property > that is read later from the shared string by compliant frontents. This solution is much more ad-hoc and you still mutate the string which is not allowed. > The advantage that I see is that those adaptations apart, it is a small > localized and effective change. Note that your idea also does not address the other issues which are addressed by my patch. The new API `completion-filter-completions` returns data which hasn't been available before, e.g., the end position, which cannot be fixed given the existing API. >> The main problem is that `completion-all-completions` allocates all the >> strings every time the completions are filtered. This is the same >> performance issue you encountered in fido-mode/icomplete-mode. > > OK. I encountered at least two different performance problems there, with > quite different causes. So let's stick to the string-allocation problem. Post > a code snippet that demonstrates the problem the way you see it/experience it? You can try my Vertico completion UI, which is available on GNU ELPA. It implements deferred highlighting and there the performance difference is perceivable. Currently Vertico uses an advice-based hack to avoid the over-eager string-allocations and the highlighting. >> The second problem addressed by the new API >> `completion-filter-completions` is that `completion-all-completions` is >> limited in what it can return. For example it cannot return the end >> position of the completion. > > And why is this a problem? Can you post an example of something you'd > like to do, but can't? Regardless, it does seem indeed like a "second" problem > (as you state) so perhaps something that can be addressed separately. Please look at the FIXMEs in minibuffer.el which address this. Currently only the beginning position of the completion boundary is returned, which is only half of the information. > I understand you've put time and effort into producing this work. We are > all indebted and I promise to read it. But every API writer in history of > programming has claimed those things and reality often shows otherwise. > So it's not that your work can't be those things you claim, maybe it is, but > generally the larger and broader the work the harder it is to reason about. I stand by my claim and I also stand by the claim that removing/disabling `copy-sequence` is not a proper way to address the issues at hand and will introduce many bugs in the long run. Please take your time to look at the patch in earnest. I would also like to see others chime in here with their opinion. Daniel
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 13 Aug 2021 12:06:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 13 08:06:14 2021 Received: from localhost ([127.0.0.1]:40678 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mEVww-0007ec-H4 for submit <at> debbugs.gnu.org; Fri, 13 Aug 2021 08:06:14 -0400 Received: from mail-pl1-f176.google.com ([209.85.214.176]:36863) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1mEVwr-0007dy-3b; Fri, 13 Aug 2021 08:06:09 -0400 Received: by mail-pl1-f176.google.com with SMTP id f3so11648504plg.3; Fri, 13 Aug 2021 05:06:05 -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=njSiQZeqjhLp38f+q1STdsHcPKVcgTrEHylx+LpFmXQ=; b=mRybdEqQZZnXQ+wU8nuO02C7OgdE70ro+46P0pATdrPTNswOqyV8UJ8PUS9VtW0SPf VzMVuQpMif7UNSR5qytOEKul+S5kzXJw5cRg0YDCVjkJpi7cBM9PcqAplrtBnUCQw3wo NLnASLQXzEy4e6KCvPgVgHnmGImAeETOsALWq5E3R4V1DL/XuzYwwdKoHXJzIm46fikI nEAdAoPQXgB0jaarEGkweITDlYPwhyv2TLda0XFpXP6+UutpTkTXhusniX90baGjkHNV BugikjEx/lXJhnWusr5PLPs6oddB10h+b4g+Hz+GKa0DpV+k5xP7pCNxlLPprpZiBO7a m0kw== 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=njSiQZeqjhLp38f+q1STdsHcPKVcgTrEHylx+LpFmXQ=; b=W/imYrU92wciOyw2t/wJhW/DXkxz4KZI31KIKn0N8EWDDO4Qa/2DY0ZRyWfzxdd2XA vPd8KbhcfWqhhCgaTU4AqniQocifXMsCpcqILOUCFveLitTTKAJkah0bCEfHfNnzBcGZ lrPimWfTG84qiWMykUPaAM3yAINbVI7gVDmC+DZemRiVcb5OjMzH6Pj4rflBrycpYetu koVLblfSjjYwte4sCIY0/8Umw8o1vgkmSuZ1l8DWvz5B33opDq3Gz/F7EkgRJSfk3iqo D8alBpqI2rNfcx7LqGavxxxDsS/xbjJivMNgRqqjNAWv/0xujzpCy8r6YZ/MMKUYpc23 jCZQ== X-Gm-Message-State: AOAM533qhNr1IbKcVGH0kbevY5VqsnO9AGh+bm1INMIzJtDOdesWCtca 9Rjs+vA2DLBrTkkZhbJriucb9ffWcVR31B9ykwc= X-Google-Smtp-Source: ABdhPJyQMdCxprMZ56Ulp2KcbQOQamn6j8Gk84j90A/p0TH9H4ZILhFxlt32JRNgYDIOHmjKvSOaUG0hjQuyC993JyM= X-Received: by 2002:a17:90b:14b:: with SMTP id em11mr2340093pjb.125.1628856359053; Fri, 13 Aug 2021 05:05:59 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> In-Reply-To: <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Fri, 13 Aug 2021 13:05:47 +0100 Message-ID: <CALDnm52XM+S07OPXO3qtfLN4pup-kT2U=WRO9dUo3tv9uYJWXw@HIDDEN> Subject: Re: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Daniel Mendler <mail@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Dmitry Gutov <dgutov@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On Fri, Aug 13, 2021 at 12:21 PM Daniel Mendler <mail@HIDDEN> wr= ote: > No, this is not the case. There is no simple fix of the allocation issue > on the frontend side. I didn't claim that. At all. I claimed that the frontends that would be affected by the (small) backend patch are easy to adapt. I think you completely read past my idea. > The existing API `completion-all-completions` > necessarily has to allocate all the strings in order to attach > highlighting and scoring. The new API solves this in a clean way by > both deferring highlighting and scoring. I'm not sure you understand my alternative idea. As far as I understand (and have actually measured) the lines: ;; Don't modify the string itself. (setq str (copy-sequence str)) in minibuffer.el, in the function completion-pcm--hilit-commonality Are the cause of the problem that _I am talking about_ and that I have actually measured. Again you may be referring to a _different_ problem that I am unaware of. If one removes these lines, the process becomes much faster, but there is a problem with highlighting. My idea is indeed to defer highlighting by not setting the 'face property directly on that shared string, but some other property that is read later from the shared string by compliant frontents. If you have understood this idea, can you comment on it? (Preferably in terms of less adjectification regarding "cleanliness", but i= n terms of actual drawbacks/advantages?) The drawback that I can see in it is that frontends directly relying on 'face are broken by that patch. But according to Dmitry (and I tend to agree), it's quite easy to address those frontends. Most of them live in Emacs core or GNU Elpa. The advantage that I see is that those adaptations apart, it is a small localized and effective change. > I claim that my patch is easy to reason about and refactors the existing > code to address the exact problem we are having. Please take some time > in reviewing it. I am already taking some time. I need your assistance in explaining the problems first. I take into account your claims of cleanliness and elegance= , but in terms of their power of persuasion, they are much more limited than hard material evidence. > The main problem is that `completion-all-completions` allocates all the > strings every time the completions are filtered. This is the same > performance issue you encountered in fido-mode/icomplete-mode. OK. I encountered at least two different performance problems there, with quite different causes. So let's stick to the string-allocation problem. P= ost a code snippet that demonstrates the problem the way you see it/experience = it? Some benchmark code would be very welcome. You can probably grab my benchmarking code from that other bug. Then it becomes easy to study multiple solutions to that problem and choose the best one! > The second problem addressed by the new API > `completion-filter-completions` is that `completion-all-completions` is > limited in what it can return. For example it cannot return the end > position of the completion. And why is this a problem? Can you post an example of something you'd like to do, but can't? Regardless, it does seem indeed like a "second" pro= blem (as you state) so perhaps something that can be addressed separately. Is your particular solution to this second problem instrumental in solving the "main problem" > This is also solved by the new API. The new API is a clean extensible wa= y forward. I understand you've put time and effort into producing this work. We are all indebted and I promise to read it. But every API writer in history of programming has claimed those things and reality often shows otherwise. So it's not that your work can't be those things you claim, maybe it is, bu= t generally the larger and broader the work the harder it is to reason about. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 13 Aug 2021 11:21:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 13 07:21:43 2021 Received: from localhost ([127.0.0.1]:40605 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mEVFu-0004C5-TH for submit <at> debbugs.gnu.org; Fri, 13 Aug 2021 07:21:43 -0400 Received: from server.qxqx.de ([178.63.65.180]:58693 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1mEVFs-0004Bk-QI; Fri, 13 Aug 2021 07:21:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=8hwFNV/aAe3vVUeLSmkDH/7Bo2a4jUM3hyldTTf1mXU=; b=Z0MtMaK/toFejKLtw4dwCcoPv3 YNf2RJn82xqwC1SZfFohhyetqlPs/IpcFa3HdDwI5YKS+gW480ebGSmW/RKlFSpKr28QVEAgSI7l0 N4x0J9Nv6N7kXDletNpixpVp6ik9P4RYvzuI/yqa79S6KsPlVCLjehZWNnB0PA5aAHmA=; Subject: Re: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> From: Daniel Mendler <mail@HIDDEN> Message-ID: <56ab18b1-4348-9b2c-85bb-af9b76cd429a@HIDDEN> Date: Fri, 13 Aug 2021 13:21:32 +0200 MIME-Version: 1.0 In-Reply-To: <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: Dmitry Gutov <dgutov@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) On 8/13/21 12:56 PM, João Távora wrote: > I've read the discussion and am indeed aware of some non-neglibile > performance problems in the flex and pcm completion styles since > they need to copy strings around. Other -- completely different -- > performance problems affect fido-mode specifically (but not > fido-vertical-mode, curiously). > > In some conversation with Dmitry > > bug#48841: fido-mode is slower than ido-mode with similar settings > > We discussed this. I've read the discussion. You are probably aware of my efforts to in Vertico to implement deferred highlighting. The patch I implemented here implements the deferred highlighting in a clean way. > There was also talk of removing the string copying with minimal (but not null) > backward compatibility breakage. I recall Dmitry saying it was easy > to fix on the > completion frontend side. Many such frontends live in Emacs or GNU Elpa. > On the other hand, the patch that we (or at least I) envisioned in > that discussion > was almost certainly much, much simpler than the one being presented here, > and thus much easier to reason about and discuss. No, this is not the case. There is no simple fix of the allocation issue on the frontend side. The existing API `completion-all-completions` necessarily has to allocate all the strings in order to attach highlighting and scoring. The new API solves this in a clean way by both deferring highlighting and scoring. I claim that my patch is easy to reason about and refactors the existing code to address the exact problem we are having. Please take some time in reviewing it. > But to avoid comparing apples to oranges, I would you to summarize exactly, > perhaps in the forms of code snippets, and/or benchmarks exactly what problems > your large patch solves. State the problem(s) first, then the solution > (to each). The main problem is that `completion-all-completions` allocates all the strings every time the completions are filtered. This is the same performance issue you encountered in fido-mode/icomplete-mode. The second problem addressed by the new API `completion-filter-completions` is that `completion-all-completions` is limited in what it can return. For example it cannot return the end position of the completion. This is also solved by the new API. The new API is a clean extensible way forward. Daniel
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 13 Aug 2021 10:57:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 13 06:57:19 2021 Received: from localhost ([127.0.0.1]:40566 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mEUsJ-0001Nz-36 for submit <at> debbugs.gnu.org; Fri, 13 Aug 2021 06:57:19 -0400 Received: from mail-pj1-f53.google.com ([209.85.216.53]:50818) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1mEUsH-0001Nj-0K; Fri, 13 Aug 2021 06:57:17 -0400 Received: by mail-pj1-f53.google.com with SMTP id bo18so14781595pjb.0; Fri, 13 Aug 2021 03:57:16 -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=dSemysIFcr8EOxC+zmRqh0RfmCQlAPXj3PR3O0OqjzY=; b=SqubbkDLKuatuVjfKoJQjDb01671J7SAVkAWFgMGPssDNfl+XOjqCEss4W9U97TluU n1xJdbjlqGJ1Mj1WhF5MN+ma5y3HnwSBQMUEaAOAjuOyqjQAQavfhX7lVdrYQHDS8EXP Gl31ZgY5JLaBP/bQel4FeetOLzBJKAT1ynhYVwIej4H9fOmCtW8yb9dsnRO1ReNForXQ GiQFOPO41g/QwAR85Es4hB2/LPoIDSo5mFPJijI6ptl5uJSNY9IrpQRaw9rxcBk2Fyzs Y6kk0pfHMFXrKQo+XVgkxRoTawnBf8r3xw5U9plE3Shu1T9ME2GkKjAQbo+mjc0V/1YX yR4w== 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=dSemysIFcr8EOxC+zmRqh0RfmCQlAPXj3PR3O0OqjzY=; b=NTQOAVAo1TY2fEroNfNGTntDeXFhg7x7yWweDS2OXVVmtDuuVF28EDOha3kRVMrEqf laGHQhPHesf9JMefAa+1FD2bvqX6L21uVLGLTvhZGUG3FY28r3PoAjXEsuo3NITeatP0 aSReToSpb9CQo+3PaUcKXBLeP1O/z943YGXtjY9dhUdLp8Fp4jAKfkpedlflGw+x75Ex E5bHAqLYnd37uC9K6SBRjOp/8+WhJm2rBM5FhfQvgP9Uloqjk943gW5OP20NWL+Jiy6g 5CkggSl1auOIe20sy4lq72G9S4N6zbIUfclRVbKOlx4DMkCZAsV0V2lIehmd+AjgqWri 8vdA== X-Gm-Message-State: AOAM531XFDNPfEYScjVKT2NWHKrwVe/B05k0HPjP5zzDov/lMVwCXExH D5k3adbNTjhyrthvgFvnZ0DIsRXzcm2Nfjj3aJc= X-Google-Smtp-Source: ABdhPJxe/IE4MLihlfvr0Vhji16fJ+zz8X6GRYFjDtC5ScQ9Kf+7vIgbgXzMBZ7NcW8mfhlhyvK1dz3EAnhzzSNx9hY= X-Received: by 2002:a63:c0a:: with SMTP id b10mr1803467pgl.447.1628852231016; Fri, 13 Aug 2021 03:57:11 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> In-Reply-To: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Fri, 13 Aug 2021 11:56:59 +0100 Message-ID: <CALDnm53xh6boc6T9XSC4jZpkCPS3RB8JFNb12BpkoeGYg3Q9RQ@HIDDEN> Subject: Re: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting To: Daniel Mendler <mail@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: Eli Zaretskii <eliz@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > In comparison to my last patch, the patch is fully backward > compatible and preserves all existing tests. This a very good thing (the fact that the patch is fully backward compatibl= e, I mean). It is quite a large patch that touches many completion internals. I'd like some time to look it over. I've read the discussion and am indeed aware of some non-neglibile performance problems in the flex and pcm completion styles since they need to copy strings around. Other -- completely different -- performance problems affect fido-mode specifically (but not fido-vertical-mode, curiously). In some conversation with Dmitry bug#48841: fido-mode is slower than ido-mode with similar settings We discussed this. There was also talk of removing the string copying with minimal (but not nu= ll) backward compatibility breakage. I recall Dmitry saying it was easy to fix on the completion frontend side. Many such frontends live in Emacs or GNU Elpa. On the other hand, the patch that we (or at least I) envisioned in that discussion was almost certainly much, much simpler than the one being presented here, and thus much easier to reason about and discuss. But to avoid comparing apples to oranges, I would you to summarize exactly, perhaps in the forms of code snippets, and/or benchmarks exactly what probl= ems your large patch solves. State the problem(s) first, then the solution (to each). If there are multiple problems, then there's a good chance that multiple pa= tches that address each of these are preferred. Thank you very much. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 13 Aug 2021 10:38:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 13 06:38:49 2021
Received: from localhost ([127.0.0.1]:40555 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1mEUaN-0007E5-G7
for submit <at> debbugs.gnu.org; Fri, 13 Aug 2021 06:38:49 -0400
Received: from server.qxqx.de ([178.63.65.180]:41947 helo=mail.qxqx.de)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <mail@HIDDEN>)
id 1mEUaD-0007DS-NT; Fri, 13 Aug 2021 06:38:42 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de;
s=mail1392553390; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:
References:Cc:To:From:Subject:Sender:Reply-To:Content-Transfer-Encoding:
Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
List-Subscribe:List-Post:List-Owner:List-Archive;
bh=SOhFQ1wSTJnkfn/KBMxtDxfjGodK9cPP6BpCAVQ3Lfs=; b=IEjg+aZkC1HrwtTiwHLxhnp3JL
JJ35+RmaX6JZqCW3bXdtO3LJrxwz+CsVgnEjjo5GKq6XPoPo4xYp437AFb0l7RscfmEDM4jtCZM+m
ehIxls6ebgDm8mqhfIY5wqjVe4ZmcRKzTR06jd9pMG4FQqNPBK400UfmBk6qrYndGUhM=;
Subject: Re: [PATCH VERSION 2] Add new `completion-filter-completions` API and
deferred highlighting
From: Daniel Mendler <mail@HIDDEN>
To: 47711 <at> debbugs.gnu.org, 48841 <at> debbugs.gnu.org
References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
<f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN>
<fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN>
Message-ID: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@HIDDEN>
Date: Fri, 13 Aug 2021 12:38:28 +0200
MIME-Version: 1.0
In-Reply-To: <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN>
Content-Type: multipart/mixed; boundary="------------E6B7393FF90421271E72F100"
Content-Language: en-US
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47711
Cc: Eli Zaretskii <eliz@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN>,
=?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>,
Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
This is a multi-part message in MIME format.
--------------E6B7393FF90421271E72F100
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
I attached the overhauled patch, which addresses most of the comments by
Eli. In comparison to my last patch, the patch is fully backward
compatible and preserves all existing tests. As before, there are tests
which check the new functionality for each existing completion style.
Daniel
--------------E6B7393FF90421271E72F100
Content-Type: text/x-diff; charset=UTF-8;
name="0001-Add-new-completion-filter-completions-API-and-deferr.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename*0="0001-Add-new-completion-filter-completions-API-and-deferr.pa";
filename*1="tch"
From 30ca42b49d5b5316abb3ebad38b0e9629eb52920 Mon Sep 17 00:00:00 2001
From: Daniel Mendler <mail@HIDDEN>
Date: Mon, 12 Jul 2021 21:40:32 +0200
Subject: [PATCH] Add new 'completion-filter-completions' API and deferred
highlighting
Fix bug#47711.
Add a new 'completion-filter-completions' API, which supersedes
'completion-all-completions'. The new API returns the matching
completion candidates and additional data. The return value is an
alist, with the keys 'completions', 'base', 'end' and 'highlight'.
The API can be extended in a backward compatible way later on thanks
to the use of an alist as return value.
The 'completions' value is the list of completion strings *without*
applied highlighting. The completion strings are returned unmodified,
which avoids allocations and results in performance gains for
continuously updating completion UIs, like Icomplete or Vertico (GNU
ELPA). The value 'base' is the base position of the completion
relative to the beginning of the input string. Correspondingly the
value 'end' specifies the end position of the completion relative to
the beginning of the input string. In comparison, the old function
'completion-all-completions' only returned the base position in the
last cdr of the returned completions list, which complicated usage.
The 'end' position was not provided by 'completion-all-completions'.
Given the new API the 'completion-base-position' can be set
accurately. Finally the 'highlight' value is a function taking a list
of completion strings and returns a new list of new strings with
highlighting applied. A continously updating UI can use the
highlighting function to apply highlighting only to the visible
completions.
* lisp/minibuffer.el:
(completion--adjust-metadata): Rename to 'completion--style-metadata'
due to change of calling convention.
(completion--nth-completion): Call renamed metadata adjustment
function. Ignore the old property 'completion--adjust-metadata'.
(completion--flex-adjust-metadata): Rename function.
(completion--twq-all): Attach 'completion--unquoted' text property to
quoted completion strings.
(completion--flex-score-1): Extract new function from
'completion-pcm--hilit-commonality'.
(completion-pcm--hilit-commonality): Use it. Add SCORE argument.
(completion--flex-score): Use 'completion--flex-score-1'. Use
'completion--unquoted' text property.
(completion--flex-style-metadata): Use it.
(completion--pattern-compiler): New function.
(completion-substring--all-completions)
(completion--flex-score): Use it.
(completion--hilit-commonality): New function.
(completion-hilit-commonality): Use it.
(completion--deferred-hilit): New function.
(completion-basic-all-completions)
(completion-emacs21-all-completions)
(completion-emacs22-all-completions): Use it.
(completion--pcm-deferred-hilit): New function.
(completion-pcm-all-completions)
(completion-flex-all-completions)
(completion-initials-all-completions)
(completion-substring-all-completions): Use it.
(completion--return-alist-flag): New variable to conditionally enable
the new alist completions result format. This variable is for
internal use to preserve the existing calling convention of the
completion style 'all' functions.
(completion-filter-completions): New API which returns the completion
strings and additional data as an an alist. Transparently convert
old list completion style results to the new alist format.
(completion-all-completions): Transparently convert the new
alist completion style result to the old list format.
(minibuffer-completion-help): Use the new API, set
'completion-base-position' correctly.
(completion-try-completion)
(completion-all-completions): Update doc string.
(completion--replace): Fix property removal.
* test/lisp/minibuffer-tests.el:
(completion--test-style)
(completion--test-boundaries): New test helper function.
(completion-emacs22orig-all-completions): New function.
(completion-flex-score-test-*): Add new scoring test functions.
(completion-*-style-test): Add new API tests for each built-in
completion style.
(completion-*-boundaries-test): New boundary tests for each built-in
completion style.
(completion-filter-completions-highlight-test): New API test.
(completion-upgrade-return-type-test): New test of transparent
completion style return value upgrade.
---
lisp/minibuffer.el | 580 +++++++++++++++++++++++-----------
test/lisp/minibuffer-tests.el | 217 ++++++++++++-
2 files changed, 603 insertions(+), 194 deletions(-)
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 9f327df28f..66ac6b3763 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -692,6 +692,10 @@ completion--twq-all
'completions-common-part)
qprefix))))
(qcompletion (concat qprefix qnew)))
+ ;; Attach unquoted completion string, which is needed
+ ;; to score the completion in `completion--flex-score'.
+ (put-text-property 0 1 'completion--unquoted
+ completion qcompletion)
;; FIXME: Similarly here, Cygwin's mapping trips this
;; assertion.
;;(cl-assert
@@ -1035,6 +1039,17 @@ completion--styles
(delete-dups (append (cdr over) (copy-sequence completion-styles)))
completion-styles)))
+(defvar completion--return-alist-flag nil
+ "Non-nil means to return completions in alist format.
+If this variable is non-nil the `all-completions' function of a
+completion style should return the results in the alist format of
+`completion-filter-completions'. This variable is purely needed to
+for backward compatibility of the existing builtin completion style
+functions as of Emacs 28. Newer completion style functions should
+always return their results in the alist format, since
+`completion-all-completions' transparently converts back to a list of
+completions with base size in the last cdr.")
+
(defun completion--nth-completion (n string table pred point metadata)
"Call the Nth method of completion styles."
;; We provide special support for quoting/unquoting here because it cannot
@@ -1061,6 +1076,15 @@ completion--nth-completion
;; the original table, in that case!
(functionp table))
(let ((new (funcall table string point 'completion--unquote)))
+ ;; FIXME For now do not attempt deferred highlighting if
+ ;; quoting is used. Not doing deferred highlighting is
+ ;; not too severe in this case, since
+ ;; `completion--twq-all' is already an expensive
+ ;; function, which allocates all completion strings. In
+ ;; contrast to plain completion tables, the savings of
+ ;; deferred highlighting would be minimal in the case of
+ ;; quoted completion tables.
+ (setq completion--return-alist-flag nil)
(setq string (pop new))
(setq table (pop new))
(setq point (pop new))
@@ -1069,17 +1093,35 @@ completion--nth-completion
(result-and-style
(completion--some
(lambda (style)
- (let ((probe (funcall (nth n (assq style
- completion-styles-alist))
- string table pred point)))
+ (let* ((fun (nth n (assq style completion-styles-alist)))
+ ;; Transparently upgrade the return value for
+ ;; existing built-in styles as of Emacs 28. No
+ ;; new styles should be added here. New completion
+ ;; styles should directly return the new
+ ;; completion format.el
+ (completion--return-alist-flag
+ (and completion--return-alist-flag
+ (memq style '(emacs21 emacs22 basic substring
+ partial-completion initials flex))))
+ (probe (funcall fun string table pred point)))
(and probe (cons probe style))))
(completion--styles md)))
- (adjust-fn (get (cdr result-and-style) 'completion--adjust-metadata)))
- (when (and adjust-fn metadata)
- (setcdr metadata (cdr (funcall adjust-fn metadata))))
+ (style-md (get (cdr result-and-style) 'completion--style-metadata))
+ (result (car result-and-style)))
+ (when (and style-md metadata)
+ (setcdr metadata (cdr (funcall style-md
+ string table pred point metadata))))
+ (when (and (not completion--return-alist-flag) (= n 2) (consp (car result)))
+ ;; Give the completion styles some freedom! If they are
+ ;; targeting Emacs 28 upwards only, they may return a result
+ ;; with deferred highlighting. We convert back to the old
+ ;; format here by applying the highlighting eagerly.
+ (setq result (nconc (funcall (cdr (assq 'highlight result))
+ (cdr (assq 'completions result)))
+ (cdr (assq 'base result)))))
(if requote
- (funcall requote (car result-and-style) n)
- (car result-and-style))))
+ (funcall requote result n)
+ result)))
(defun completion-try-completion (string table pred point &optional metadata)
"Try to complete STRING using completion table TABLE.
@@ -1088,7 +1130,8 @@ completion-try-completion
The return value can be either nil to indicate that there is no completion,
t to indicate that STRING is the only possible completion,
or a pair (NEWSTRING . NEWPOINT) of the completed result string together with
-a new position for point."
+a new position for point.
+The METADATA may be modified by the completion style."
(completion--nth-completion 1 string table pred point metadata))
(defun completion-all-completions (string table pred point &optional metadata)
@@ -1096,10 +1139,47 @@ completion-all-completions
Only the elements of table that satisfy predicate PRED are considered.
POINT is the position of point within STRING.
The return value is a list of completions and may contain the base-size
-in the last `cdr'."
- ;; FIXME: We need to additionally return the info needed for the
- ;; second part of completion-base-position.
- (completion--nth-completion 2 string table pred point metadata))
+in the last `cdr'.
+The METADATA may be modified by the completion style.
+
+This function has been superseded by `completion-filter-completions',
+which returns richer information and supports deferred candidate
+highlighting."
+ (let ((completion--return-alist-flag nil))
+ (completion--nth-completion 2 string table pred point metadata)))
+
+(defun completion-filter-completions (string table pred point metadata)
+ "Filter the possible completions of STRING in completion table TABLE.
+Only the elements of table that satisfy predicate PRED are considered.
+POINT is the position of point within STRING.
+The METADATA may be modified by the completion style.
+The return value is a alist with the keys:
+
+- base: Base position of the completion (from the start of STRING)
+- end: End position of the completion (from the start of STRING)
+- highlight: Highlighting function taking a list of completions and
+ returning a new list of new strings with applied highlighting.
+- completions: The list of completions.
+
+This function supersedes the function `completion-all-completions',
+which does not provide the `end' position of the completion and does
+not support deferred highlighting."
+ (let* ((completion--return-alist-flag t)
+ (result (completion--nth-completion 2 string table
+ pred point metadata)))
+ (if (and result (not (consp (car result))))
+ ;; Deferred highlighting has been requested, but the
+ ;; completion style returned a non-deferred result. Convert
+ ;; the result to the alist format of
+ ;; `completion-filter-completions'.
+ (let* ((last (last result))
+ (base (or (cdr last) 0)))
+ (setcdr last nil)
+ `((base . ,base)
+ (end . ,(length string))
+ (highlight . identity)
+ (completions . ,result)))
+ result)))
(defun minibuffer--bitset (modified completions exact)
(logior (if modified 4 0)
@@ -1115,7 +1195,8 @@ completion--replace
(if minibuffer-allow-text-properties
;; If we're preserving properties, then just remove the faces
;; and other properties added by the completion machinery.
- (remove-text-properties 0 (length newtext) '(face completion-score)
+ (remove-text-properties 0 (length newtext)
+ '(face nil completion-score nil)
newtext)
;; Remove all text properties.
(set-text-properties 0 (length newtext) nil newtext))
@@ -2021,34 +2102,49 @@ completion-hilit-commonality
It returns a list with font-lock properties applied to each element,
and with BASE-SIZE appended as the last element."
(when completions
- (let ((com-str-len (- prefix-len (or base-size 0))))
- (nconc
- (mapcar
- (lambda (elem)
- (let ((str
- ;; Don't modify the string itself, but a copy, since the
- ;; the string may be read-only or used for other purposes.
- ;; Furthermore, since `completions' may come from
- ;; display-completion-list, `elem' may be a list.
- (if (consp elem)
- (car (setq elem (cons (copy-sequence (car elem))
- (cdr elem))))
- (setq elem (copy-sequence elem)))))
- (font-lock-prepend-text-property
- 0
- ;; If completion-boundaries returns incorrect
- ;; values, all-completions may return strings
- ;; that don't contain the prefix.
- (min com-str-len (length str))
- 'face 'completions-common-part str)
- (if (> (length str) com-str-len)
- (font-lock-prepend-text-property com-str-len (1+ com-str-len)
- 'face
- 'completions-first-difference
- str)))
- elem)
- completions)
- base-size))))
+ (nconc
+ (completion--hilit-commonality (- prefix-len (or base-size 0)) completions)
+ base-size)))
+
+(defun completion--hilit-commonality (com-size completions)
+ (mapcar
+ (lambda (elem)
+ (let ((str
+ ;; Don't modify the string itself, but a copy, since the
+ ;; the string may be read-only or used for other purposes.
+ ;; Furthermore, since `completions' may come from
+ ;; display-completion-list, `elem' may be a list.
+ (if (consp elem)
+ (car (setq elem (cons (copy-sequence (car elem))
+ (cdr elem))))
+ (setq elem (copy-sequence elem)))))
+ (font-lock-prepend-text-property
+ 0
+ ;; If completion-boundaries returns incorrect
+ ;; values, all-completions may return strings
+ ;; that don't contain the prefix.
+ (min com-size (length str))
+ 'face 'completions-common-part str)
+ (if (> (length str) com-size)
+ (font-lock-prepend-text-property com-size (1+ com-size)
+ 'face
+ 'completions-first-difference
+ str)))
+ elem)
+ completions))
+
+(defun completion--deferred-hilit (completions prefix-len base end)
+ "Return completions as a list or as an alist.
+If `completion--return-alist-flag' is non-nil use the alist format of
+`completion-filter-completions'."
+ (if completion--return-alist-flag
+ (when completions
+ `((base . ,base)
+ (end . ,end)
+ (highlight . ,(apply-partially #'completion--hilit-commonality
+ (- prefix-len base)))
+ (completions . ,completions)))
+ (completion-hilit-commonality completions prefix-len base)))
(defun display-completion-list (completions &optional common-substring group-fun)
"Display the list of completions, COMPLETIONS, using `standard-output'.
@@ -2163,15 +2259,16 @@ minibuffer-completion-help
(end (or end (point-max)))
(string (buffer-substring start end))
(md (completion--field-metadata start))
- (completions (completion-all-completions
- string
- minibuffer-completion-table
- minibuffer-completion-predicate
- (- (point) start)
- md)))
+ (filtered-completions (completion-filter-completions
+ string
+ minibuffer-completion-table
+ minibuffer-completion-predicate
+ (- (point) start)
+ md))
+ (completions (alist-get 'completions filtered-completions)))
(message nil)
(if (or (null completions)
- (and (not (consp (cdr completions)))
+ (and (not (cdr completions))
(equal (car completions) string)))
(progn
;; If there are no completions, or if the current input is already
@@ -2181,8 +2278,7 @@ minibuffer-completion-help
(completion--message
(if completions "Sole completion" "No completions")))
- (let* ((last (last completions))
- (base-size (or (cdr last) 0))
+ (let* ((base-size (alist-get 'base filtered-completions))
(prefix (unless (zerop base-size) (substring string 0 base-size)))
(all-md (completion--metadata (buffer-substring-no-properties
start (point))
@@ -2226,9 +2322,12 @@ minibuffer-completion-help
(body-function
. ,#'(lambda (_window)
(with-current-buffer mainbuf
- ;; Remove the base-size tail because `sort' requires a properly
- ;; nil-terminated list.
- (when last (setcdr last nil))
+ ;; Apply highlighting using the deferred
+ ;; highlighting function provided by
+ ;; `completion-format-completions'.
+ (setq completions
+ (funcall (alist-get 'highlight filtered-completions)
+ completions))
;; Sort first using the `display-sort-function'.
;; FIXME: This function is for the output of
@@ -2267,13 +2366,10 @@ minibuffer-completion-help
completions))))
(with-current-buffer standard-output
- (setq-local completion-base-position
- (list (+ start base-size)
- ;; FIXME: We should pay attention to completion
- ;; boundaries here, but currently
- ;; completion-all-completions does not give us the
- ;; necessary information.
- end))
+ (setq-local
+ completion-base-position
+ (list (+ start base-size)
+ (+ start (alist-get 'end filtered-completions))))
(setq-local completion-list-insert-choice-function
(let ((ctable minibuffer-completion-table)
(cpred minibuffer-completion-predicate)
@@ -3223,10 +3319,11 @@ completion-emacs21-try-completion
completion)))
(defun completion-emacs21-all-completions (string table pred _point)
- (completion-hilit-commonality
+ (completion--deferred-hilit
(all-completions string table pred)
(length string)
- (car (completion-boundaries string table pred ""))))
+ (car (completion-boundaries string table pred ""))
+ (length string)))
(defun completion-emacs22-try-completion (string table pred point)
(let ((suffix (substring string point))
@@ -3249,11 +3346,12 @@ completion-emacs22-try-completion
(cons (concat completion suffix) (length completion)))))
(defun completion-emacs22-all-completions (string table pred point)
- (let ((beforepoint (substring string 0 point)))
- (completion-hilit-commonality
+ (let* ((beforepoint (substring string 0 point))
+ (afterpoint (substring string point))
+ (bounds (completion-boundaries beforepoint table pred afterpoint)))
+ (completion--deferred-hilit
(all-completions beforepoint table pred)
- point
- (car (completion-boundaries beforepoint table pred "")))))
+ point (car bounds) (+ point (cdr bounds)))))
;;; Basic completion.
@@ -3312,7 +3410,7 @@ completion-basic-all-completions
'point
(substring afterpoint 0 (cdr bounds)))))
(all (completion-pcm--all-completions prefix pattern table pred)))
- (completion-hilit-commonality all point (car bounds))))
+ (completion--deferred-hilit all point (car bounds) (+ point (cdr bounds)))))
;;; Partial-completion-mode style completion.
@@ -3504,13 +3602,26 @@ flex-score-match-tightness
than the latter (which has two \"holes\" and three
one-letter-long matches).")
-(defun completion-pcm--hilit-commonality (pattern completions)
+(defun completion-pcm--deferred-hilit (pattern completions base end)
+ "Return completions as a list or as an alist.
+If `completion--return-alist-flag' is non-nil use the alist format of
+`completion-filter-completions'."
+ (when completions
+ (if completion--return-alist-flag
+ `((base . ,base)
+ (end . ,end)
+ (highlight . ,(apply-partially
+ #'completion-pcm--hilit-commonality
+ pattern))
+ (completions . ,completions))
+ (nconc (completion-pcm--hilit-commonality pattern completions 'score) base))))
+
+(defun completion-pcm--hilit-commonality (pattern completions &optional score)
"Show where and how well PATTERN matches COMPLETIONS.
PATTERN, a list of symbols and strings as seen
`completion-pcm--merge-completions', is assumed to match every
string in COMPLETIONS. Return a deep copy of COMPLETIONS where
-each string is propertized with `completion-score', a number
-between 0 and 1, and with faces `completions-common-part',
+each string is propertized with faces `completions-common-part',
`completions-first-difference' in the relevant segments."
(when completions
(let* ((re (completion-pcm--pattern->regex pattern 'group))
@@ -3527,84 +3638,143 @@ completion-pcm--hilit-commonality
(match-end (match-end 0))
(md (cddr (setq last-md (match-data t last-md))))
(from 0)
- (end (length str))
- ;; To understand how this works, consider these simple
- ;; ascii diagrams showing how the pattern "foo"
- ;; flex-matches "fabrobazo", "fbarbazoo" and
- ;; "barfoobaz":
-
- ;; f abr o baz o
- ;; + --- + --- +
-
- ;; f barbaz oo
- ;; + ------ ++
-
- ;; bar foo baz
- ;; +++
-
- ;; "+" indicates parts where the pattern matched. A
- ;; "hole" in the middle of the string is indicated by
- ;; "-". Note that there are no "holes" near the edges
- ;; of the string. The completion score is a number
- ;; bound by ]0..1]: the higher the better and only a
- ;; perfect match (pattern equals string) will have
- ;; score 1. The formula takes the form of a quotient.
- ;; For the numerator, we use the number of +, i.e. the
- ;; length of the pattern. For the denominator, it
- ;; first computes
- ;;
- ;; hole_i_contrib = 1 + (Li-1)^(1/tightness)
- ;;
- ;; , for each hole "i" of length "Li", where tightness
- ;; is given by `flex-score-match-tightness'. The
- ;; final value for the denominator is then given by:
- ;;
- ;; (SUM_across_i(hole_i_contrib) + 1) * len
- ;;
- ;; , where "len" is the string's length.
- (score-numerator 0)
- (score-denominator 0)
- (last-b 0)
- (update-score-and-face
- (lambda (a b)
- "Update score and face given match range (A B)."
- (add-face-text-property a b
- 'completions-common-part
- nil str)
- (setq
- score-numerator (+ score-numerator (- b a)))
- (unless (or (= a last-b)
- (zerop last-b)
- (= a (length str)))
- (setq
- score-denominator (+ score-denominator
- 1
- (expt (- a last-b 1)
- (/ 1.0
- flex-score-match-tightness)))))
- (setq
- last-b b))))
+ (len (length str)))
+ (when (and score (/= 0 len))
+ (put-text-property
+ 0 1 'completion-score (- (completion--flex-score-1 md match-end len)) str))
(while md
- (funcall update-score-and-face from (pop md))
+ (add-face-text-property from (pop md)
+ 'completions-common-part
+ nil str)
(setq from (pop md)))
;; If `pattern' doesn't have an explicit trailing any, the
;; regex `re' won't produce match data representing the
;; region after the match. We need to account to account
;; for that extra bit of match (bug#42149).
(unless (= from match-end)
- (funcall update-score-and-face from match-end))
- (if (> (length str) pos)
+ (add-face-text-property from match-end
+ 'completions-common-part
+ nil str))
+ (if (> len pos)
(add-face-text-property
pos (1+ pos)
'completions-first-difference
- nil str))
- (unless (zerop (length str))
- (put-text-property
- 0 1 'completion-score
- (/ score-numerator (* end (1+ score-denominator)) 1.0) str)))
+ nil str)))
str)
completions))))
+(defun completion--flex-score-1 (md match-end len)
+ "Compute matching score of completion.
+The score lies in the range between-1 and 0, where -1 corresponds to
+the full match.
+MD is the match data.
+MATCH-END is the end of the match.
+LEN is the length of the completion string."
+ (let* ((from 0)
+ ;; To understand how this works, consider these simple
+ ;; ascii diagrams showing how the pattern "foo"
+ ;; flex-matches "fabrobazo", "fbarbazoo" and
+ ;; "barfoobaz":
+
+ ;; f abr o baz o
+ ;; + --- + --- +
+
+ ;; f barbaz oo
+ ;; + ------ ++
+
+ ;; bar foo baz
+ ;; +++
+
+ ;; "+" indicates parts where the pattern matched. A
+ ;; "hole" in the middle of the string is indicated by
+ ;; "-". Note that there are no "holes" near the edges
+ ;; of the string. The completion score is a number
+ ;; bound by ]0..1]: the higher the better and only a
+ ;; perfect match (pattern equals string) will have
+ ;; score 1. The formula takes the form of a quotient.
+ ;; For the numerator, we use the number of +, i.e. the
+ ;; length of the pattern. For the denominator, it
+ ;; first computes
+ ;;
+ ;; hole_i_contrib = 1 + (Li-1)^(1/tightness)
+ ;;
+ ;; , for each hole "i" of length "Li", where tightness
+ ;; is given by `flex-score-match-tightness'. The
+ ;; final value for the denominator is then given by:
+ ;;
+ ;; (SUM_across_i(hole_i_contrib) + 1) * len
+ ;;
+ ;; , where "len" is the string's length.
+ (score-numerator 0)
+ (score-denominator 0)
+ (last-b 0))
+ (while md
+ (let ((a from)
+ (b (pop md)))
+ (setq
+ score-numerator (+ score-numerator (- b a)))
+ (unless (or (= a last-b)
+ (zerop last-b)
+ (= a len))
+ (setq
+ score-denominator (+ score-denominator
+ 1
+ (expt (- a last-b 1)
+ (/ 1.0
+ flex-score-match-tightness)))))
+ (setq
+ last-b b))
+ (setq from (pop md)))
+ ;; If `pattern' doesn't have an explicit trailing any, the
+ ;; regex `re' won't produce match data representing the
+ ;; region after the match. We need to account to account
+ ;; for that extra bit of match (bug#42149).
+ (unless (= from match-end)
+ (let ((a from)
+ (b match-end))
+ (setq
+ score-numerator (+ score-numerator (- b a)))
+ (unless (or (= a last-b)
+ (zerop last-b)
+ (= a len))
+ (setq
+ score-denominator (+ score-denominator
+ 1
+ (expt (- a last-b 1)
+ (/ 1.0
+ flex-score-match-tightness)))))
+ (setq
+ last-b b)))
+ (- (/ score-numerator (* len (1+ score-denominator)) 1.0))))
+
+(defun completion--flex-score (pattern completions)
+ "Compute how well PATTERN matches COMPLETIONS.
+PATTERN, a pcm pattern is assumed to match every string in the
+COMPLETIONS list. Return a copy of COMPLETIONS where each element is
+a pair of a score and the string. The score lies in the range between
+-1 and 0, where -1 corresponds to the full match."
+ (when completions
+ (let* ((re (completion-pcm--pattern->regex pattern 'group))
+ (case-fold-search completion-ignore-case)
+ last-md)
+ (mapcar
+ (lambda (str)
+ ;; The flex completion style requires the completion to match
+ ;; the pattern to compute the scoring. For quoted completion
+ ;; tables the completions are matched against the *unquoted
+ ;; input string*. However `completion-all-completions' and
+ ;; `completion-filter-completions' return a list of *quoted
+ ;; completions*, which is subsequently sorted. Therefore we
+ ;; obtain the unquoted completion string which is stored in
+ ;; the text property `completion--unquoted'.
+ (let ((unquoted (or (get-text-property 0 'completion--unquoted str) str)))
+ (unless (string-match re unquoted)
+ (error "Internal error: %s does not match %s" re unquoted))
+ (cons (completion--flex-score-1 (cddr (setq last-md (match-data t last-md)))
+ (match-end 0) (length unquoted))
+ str)))
+ completions))))
+
(defun completion-pcm--find-all-completions (string table pred point
&optional filter)
"Find all completions for STRING at POINT in TABLE, satisfying PRED.
@@ -3700,11 +3870,11 @@ completion-pcm--find-all-completions
(list pattern all prefix suffix)))))
(defun completion-pcm-all-completions (string table pred point)
- (pcase-let ((`(,pattern ,all ,prefix ,_suffix)
+ (pcase-let ((`(,pattern ,all ,prefix ,suffix)
(completion-pcm--find-all-completions string table pred point)))
- (when all
- (nconc (completion-pcm--hilit-commonality pattern all)
- (length prefix)))))
+ (completion-pcm--deferred-hilit pattern all
+ (length prefix)
+ (- (length string) (length suffix)))))
(defun completion--common-suffix (strs)
"Return the common suffix of the strings STRS."
@@ -3885,8 +4055,8 @@ completion-pcm-try-completion
;;; Substring completion
;; Mostly derived from the code of `basic' completion.
-(defun completion-substring--all-completions
- (string table pred point &optional transform-pattern-fn)
+(defun completion--pattern-compiler
+ (string table pred point transform-pattern-fn)
"Match the presumed substring STRING to the entries in TABLE.
Respect PRED and POINT. The pattern used is a PCM-style
substring pattern, but it be massaged by TRANSFORM-PATTERN-FN, if
@@ -3904,12 +4074,23 @@ completion-substring--all-completions
(pattern (completion-pcm--optimize-pattern
(if transform-pattern-fn
(funcall transform-pattern-fn pattern)
- pattern)))
- (all (completion-pcm--all-completions prefix pattern table pred)))
- (list all pattern prefix suffix (car bounds))))
+ pattern))))
+ (list pattern prefix suffix)))
+
+(defun completion-substring--all-completions
+ (string table pred point &optional transform-pattern-fn)
+ "Match the presumed substring STRING to the entries in TABLE.
+Respect PRED and POINT. The pattern used is a PCM-style
+substring pattern, but it be massaged by TRANSFORM-PATTERN-FN, if
+that is non-nil."
+ (pcase-let (((and result `(,pattern ,prefix ,_suffix))
+ (completion--pattern-compiler string table pred point
+ transform-pattern-fn)))
+ (cons (completion-pcm--all-completions prefix pattern table pred)
+ result)))
(defun completion-substring-try-completion (string table pred point)
- (pcase-let ((`(,all ,pattern ,prefix ,suffix ,_carbounds)
+ (pcase-let ((`(,all ,pattern ,prefix ,suffix)
(completion-substring--all-completions
string table pred point)))
(if minibuffer-completing-file-name
@@ -3917,12 +4098,12 @@ completion-substring-try-completion
(completion-pcm--merge-try pattern all prefix suffix)))
(defun completion-substring-all-completions (string table pred point)
- (pcase-let ((`(,all ,pattern ,prefix ,_suffix ,_carbounds)
+ (pcase-let ((`(,all ,pattern ,prefix ,suffix)
(completion-substring--all-completions
string table pred point)))
- (when all
- (nconc (completion-pcm--hilit-commonality pattern all)
- (length prefix)))))
+ (completion-pcm--deferred-hilit pattern all
+ (length prefix)
+ (- (length string) (length suffix)))))
;;; "flex" completion, also known as flx/fuzzy/scatter completion
;; Completes "foo" to "frodo" and "farfromsober"
@@ -3932,42 +4113,53 @@ completion-flex-nospace
:version "27.1"
:type 'boolean)
-(put 'flex 'completion--adjust-metadata 'completion--flex-adjust-metadata)
-
-(defun completion--flex-adjust-metadata (metadata)
- (cl-flet
- ((compose-flex-sort-fn
- (existing-sort-fn) ; wish `cl-flet' had proper indentation...
- (lambda (completions)
- (let ((pre-sorted
- (if existing-sort-fn
- (funcall existing-sort-fn completions)
- completions)))
- (cond
- ((or (not (window-minibuffer-p))
- ;; JT@2019-12-23: FIXME: this is still wrong. What
- ;; we need to test here is "some input that actually
- ;; leads to flex filtering", not "something after
- ;; the minibuffer prompt". Among other
- ;; inconsistencies, the latter is always true for
- ;; file searches, meaning the next clauses will be
- ;; ignored.
- (> (point-max) (minibuffer-prompt-end)))
- (sort
- pre-sorted
- (lambda (c1 c2)
- (let ((s1 (get-text-property 0 'completion-score c1))
- (s2 (get-text-property 0 'completion-score c2)))
- (> (or s1 0) (or s2 0))))))
- (t pre-sorted))))))
- `(metadata
- (display-sort-function
- . ,(compose-flex-sort-fn
- (completion-metadata-get metadata 'display-sort-function)))
- (cycle-sort-function
- . ,(compose-flex-sort-fn
- (completion-metadata-get metadata 'cycle-sort-function)))
- ,@(cdr metadata))))
+(put 'flex 'completion--style-metadata 'completion--flex-style-metadata)
+
+(defun completion--flex-style-metadata (string table pred point metadata)
+ ;; Use the modified flex sorting function only for non-empty input.
+ ;; In an older version of `completion--flex-adjust-metadata', the
+ ;; check (> (point-max) (minibuffer-prompt-end))) was used instead.
+ (unless (eq string "")
+ (let ((pattern (car (completion--pattern-compiler
+ string table pred point
+ #'completion-flex--make-flex-pattern))))
+ (cl-flet
+ ((compose-flex-sort-fn
+ (existing-sort-fn) ; wish `cl-flet' had proper indentation...
+ (lambda (completions)
+ (let ((pre-sorted (if existing-sort-fn
+ (funcall existing-sort-fn completions)
+ completions)))
+ ;; If `completion-scores' are already present use
+ ;; those instead of recomputing the scores with
+ ;; `completion--flex-score'. The scores are already
+ ;; present, when the candidates have been computed by
+ ;; `completion-all-completions'. In contrast, the
+ ;; score is not yet present, when the candidates have
+ ;; been computed by `completion-filter-completions'.
+ (if (and (car pre-sorted)
+ (get-text-property 0 'completion-score (car pre-sorted)))
+ (sort
+ pre-sorted
+ (lambda (c1 c2)
+ (> (or (get-text-property 0 'completion-score c1) 0)
+ (or (get-text-property 0 'completion-score c2) 0))))
+ (let* ((sorted (sort (completion--flex-score pattern pre-sorted)
+ #'car-less-than-car))
+ (cell sorted))
+ ;; Remove score decorations, reuse the list to avoid allocations.
+ (while cell
+ (setcar cell (cdar cell))
+ (pop cell))
+ sorted))))))
+ `(metadata
+ (display-sort-function
+ . ,(compose-flex-sort-fn
+ (completion-metadata-get metadata 'display-sort-function)))
+ (cycle-sort-function
+ . ,(compose-flex-sort-fn
+ (completion-metadata-get metadata 'cycle-sort-function)))
+ ,@(cdr metadata))))))
(defun completion-flex--make-flex-pattern (pattern)
"Convert PCM-style PATTERN into PCM-style flex pattern.
@@ -3989,7 +4181,7 @@ completion-flex--make-flex-pattern
(defun completion-flex-try-completion (string table pred point)
"Try to flex-complete STRING in TABLE given PRED and POINT."
(unless (and completion-flex-nospace (string-search " " string))
- (pcase-let ((`(,all ,pattern ,prefix ,suffix ,_carbounds)
+ (pcase-let ((`(,all ,pattern ,prefix ,suffix)
(completion-substring--all-completions
string table pred point
#'completion-flex--make-flex-pattern)))
@@ -4006,13 +4198,13 @@ completion-flex-try-completion
(defun completion-flex-all-completions (string table pred point)
"Get flex-completions of STRING in TABLE, given PRED and POINT."
(unless (and completion-flex-nospace (string-search " " string))
- (pcase-let ((`(,all ,pattern ,prefix ,_suffix ,_carbounds)
+ (pcase-let ((`(,all ,pattern ,prefix ,suffix)
(completion-substring--all-completions
string table pred point
#'completion-flex--make-flex-pattern)))
- (when all
- (nconc (completion-pcm--hilit-commonality pattern all)
- (length prefix))))))
+ (completion-pcm--deferred-hilit pattern all
+ (length prefix)
+ (- (length string) (length suffix))))))
;; Initials completion
;; Complete /ums to /usr/monnier/src or lch to list-command-history.
@@ -4049,7 +4241,11 @@ completion-initials-expand
(defun completion-initials-all-completions (string table pred _point)
(let ((newstr (completion-initials-expand string table pred)))
(when newstr
- (completion-pcm-all-completions newstr table pred (length newstr)))))
+ (pcase-let ((`(,pattern ,all ,prefix ,_suffix)
+ (completion-pcm--find-all-completions newstr table
+ pred (length newstr))))
+ (completion-pcm--deferred-hilit pattern all
+ (length prefix) (length string))))))
(defun completion-initials-try-completion (string table pred _point)
(let ((newstr (completion-initials-expand string table pred)))
diff --git a/test/lisp/minibuffer-tests.el b/test/lisp/minibuffer-tests.el
index c3ba8f9a92..22de3c9ff5 100644
--- a/test/lisp/minibuffer-tests.el
+++ b/test/lisp/minibuffer-tests.el
@@ -28,8 +28,7 @@
(require 'ert)
(require 'ert-x)
-
-(eval-when-compile (require 'cl-lib))
+(require 'cl-lib)
(ert-deftest completion-test1 ()
(with-temp-buffer
@@ -331,5 +330,219 @@ completion-flex-test-3
"custgroup" '("customize-group-other-window") nil 9)))
15)))
+(ert-deftest completion-flex-score-test-1 ()
+ ;; Full match!
+ (should (equal
+ (completion--flex-score '(prefix "R") '("R"))
+ (list (cons -1.0 "R")))))
+
+(ert-deftest completion-flex-score-test-2 ()
+ ;; One third and half of a match!
+ (should (equal
+ (completion--flex-score '(prefix "foo")
+ '("barfoobar" "fooboo"))
+ (list (cons (/ -1.0 3.0) "barfoobar")
+ (cons (/ -1.0 2.0) "fooboo")))))
+
+(ert-deftest completion-flex-score-test-3 ()
+ ;; One fourth of a match
+ (should (eql
+ (caar (completion--flex-score '(prefix "R" point "O")
+ '("RaOb")))
+ (/ -1.0 4.0))))
+
+(ert-deftest completion-flex-score-test-4 ()
+ ;; For quoted completion tables, score the unquoted completion string.
+ (should (equal
+ (completion--flex-score
+ '(prefix "R")
+ (list (propertize "X" 'completion--unquoted "R")))
+ (list (cons -1.0 "X")))))
+
+(defun completion--test-style (style string point table filtered)
+ (let* ((completion-styles (list style))
+ (pred (lambda (x) (not (string-search "!" x))))
+ (result (completion-filter-completions
+ string table pred point nil)))
+ (should (equal (alist-get 'base result) 0))
+ (should (equal (alist-get 'end result) (length string)))
+ (should (equal (alist-get 'completions result) filtered))
+ ;; The highlighting function should be present.
+ (should (not (memq (alist-get 'highlight result) '(nil identity))))
+ ;; Equal results as `completion-all-completions'.
+ (should (equal (completion-all-completions string table pred point)
+ (append filtered 0)))
+ ;; The returned strings should be identical to the original strings.
+ ;; The `completion-filter-completions' function avoids allocations!
+ (should (cl-intersection (alist-get 'completions result)
+ table :test #'eq))))
+
+(ert-deftest completion-basic-style-test-1 ()
+ ;; point at the beginning |foo
+ (completion--test-style 'basic "foo" 0
+ '("foobar" "foo!" "barfoo" "xfooy" "boobar")
+ '("foobar" "barfoo" "xfooy")))
+
+(ert-deftest completion-basic-style-test-2 ()
+ ;; point foo
+ (completion--test-style 'basic "foo" 2
+ '("foobar" "foo!" "fobar" "barfoo" "xfooy" "boobar")
+ '("foobar")))
+
+(ert-deftest completion-substring-style-test ()
+ (completion--test-style 'substring "foo" 1
+ '("foobar" "foo!" "barfoo" "xfooy" "boobar")
+ '("foobar" "barfoo" "xfooy")))
+
+(ert-deftest completion-emacs21-style-test ()
+ (completion--test-style 'emacs21 "foo" 1
+ '("foobar" "foo!" "fobar" "barfoo" "xfooy" "boobar")
+ '("foobar")))
+
+(ert-deftest completion-emacs22-style-test ()
+ (completion--test-style 'emacs22 "fo0" 1
+ '("foobar" "foo!" "fobar" "barfoo" "xfooy" "boobar")
+ '("foobar" "fobar"))) ;; suffix ignored completely
+
+(ert-deftest completion-flex-style-test ()
+ (completion--test-style 'flex "abc" 1
+ '("abc" "abc!" "xaybzc" "xaybz")
+ '("abc" "xaybzc")))
+
+(ert-deftest completion-initials-style-test ()
+ (completion--test-style 'initials "abc" 1
+ '("a-b-c" "a-b-c!" "ax-by-cz" "xax-by-cz")
+ '("a-b-c" "ax-by-cz")))
+
+(ert-deftest completion-pcm-style-test ()
+ (completion--test-style 'partial-completion "ax-b-c" 1
+ '("ax-b-c" "ax-b-c!" "ax-by-cz" "xax-by-cz")
+ '("ax-b-c" "ax-by-cz")))
+
+(ert-deftest completion-filter-completions-highlight-test ()
+ ;; point at the beginning |foo
+ (let* ((completion-styles '(basic))
+ (result (completion-filter-completions
+ "foo" '("foobar" "fbarfoo" "fxfooy" "bar")
+ nil 1 nil)))
+ (should (equal
+ (format "%S" (alist-get 'completions result))
+ (format "%S" '("foobar" "fbarfoo" "fxfooy"))))
+ (should (equal
+ (format "%S" (funcall (alist-get 'highlight result)
+ (alist-get 'completions result)))
+ (format "%S"
+ '(#("foobar" 0 1 (face (completions-common-part))
+ 1 2 (face (completions-first-difference)))
+ #("fbarfoo" 0 1 (face (completions-common-part))
+ 1 2 (face (completions-first-difference)))
+ #("fxfooy" 0 1 (face (completions-common-part))
+ 1 2 (face (completions-first-difference)))))))))
+
+(defun completion--test-boundaries (style string table result)
+ (let ((table
+ (lambda (str pred action)
+ (pcase action
+ (`(boundaries . ,suffix) `(boundaries
+ ,(1+ (string-match-p "<\\|/" str))
+ . ,(or (string-search ">" suffix) (length suffix))))
+ (_ (complete-with-action action table
+ (replace-regexp-in-string ".*[</]" "" str)
+ pred)))))
+ (point (string-search "|" string))
+ (string (string-replace "|" "" string))
+ (completion-styles (list style)))
+ (should (equal
+ (assq-delete-all
+ (if (assq 'highlight result) '-does-not-exist 'highlight)
+ (completion-filter-completions
+ string table nil point nil))
+ result))
+ (should (equal
+ (completion-all-completions
+ string table nil point)
+ (append (alist-get 'completions result)
+ (alist-get 'base result))))))
+
+(ert-deftest completion-emacs21-boundaries-test ()
+ (completion--test-boundaries 'emacs21 "before<in|put>after"
+ '("other") nil)
+ (completion--test-boundaries 'emacs21 "before<in|put>after"
+ '("ainput>after" "input>after" "inpux>after"
+ "inxputy>after" "input>after2")
+ '((base . 7)
+ (end . 18)
+ (completions "input>after" "input>after2"))))
+
+(ert-deftest completion-emacs22-boundaries-test ()
+ (completion--test-boundaries 'emacs22 "before<in|put>after"
+ '("other") nil)
+ (completion--test-boundaries 'emacs22 "before<in|put>after"
+ '("ainxxx" "inyy" "inzzz")
+ '((base . 7)
+ (end . 12)
+ (completions "inyy" "inzzz"))))
+
+(ert-deftest completion-basic-boundaries-test ()
+ (completion--test-boundaries 'basic "before<in|put>after"
+ '("other") nil)
+ (completion--test-boundaries 'basic "before<in|put>after"
+ '("ainput" "input" "inpux" "inxputy")
+ '((base . 7)
+ (end . 12)
+ (completions "input" "inxputy"))))
+
+(ert-deftest completion-substring-boundaries-test ()
+ (completion--test-boundaries 'substring "before<in|puts>after"
+ '("other") nil)
+ (completion--test-boundaries 'substring "before<in|puts>after"
+ '("ainputs" "inputs" "inpux" "inxputsy")
+ '((base . 7)
+ (end . 13)
+ (completions "ainputs" "inputs" "inxputsy"))))
+
+(ert-deftest completion-pcm-boundaries-test ()
+ (completion--test-boundaries 'partial-completion "before<in-p|t>after"
+ '("other") nil)
+ (completion--test-boundaries 'partial-completion "before<in-p|t>after"
+ '("ain-pu-ts" "in-pts" "in-pu-ts" "in-px" "inx-ptsy")
+ '((base . 7)
+ (end . 12)
+ (completions "in-pts" "in-pu-ts" "inx-ptsy"))))
+
+(ert-deftest completion-initials-boundaries-test ()
+ (completion--test-boundaries 'initials "/ip|t"
+ '("other") nil)
+ (completion--test-boundaries 'initials "/ip|t"
+ '("ain/pu/ts" "in/pts" "in/pu/ts" "a/in/pu/ts"
+ "in/pu/ts/foo" "in/px" "inx/ptsy")
+ '((base . 1)
+ (end . 4)
+ (completions "in/pu/ts" "in/pu/ts/foo"))))
+
+(defun completion-emacs22orig-all-completions (string table pred point)
+ (let ((beforepoint (substring string 0 point)))
+ (completion-hilit-commonality
+ (all-completions beforepoint table pred)
+ point
+ (car (completion-boundaries beforepoint table pred "")))))
+
+(ert-deftest completion-upgrade-return-type-test ()
+ ;; Test transparent upgrade of list completion style return value
+ ;; to the alist return value format of `completion-format-completions'.
+ (let ((completion-styles-alist
+ '((emacs22orig completion-emacs22-try-completion
+ completion-emacs22orig-all-completions nil))))
+ (completion--test-boundaries 'emacs22orig "before<in|put>after"
+ '("ainxxx" "inyy" "inzzz")
+ '((base . 7)
+ ;; 18 is incorrect, should be 12!
+ ;; But the information is not available
+ ;; due to the completion-style upgrade.
+ (end . 18)
+ ;; Identity highlighting function.
+ (highlight . identity)
+ (completions "inyy" "inzzz")))))
+
(provide 'minibuffer-tests)
;;; minibuffer-tests.el ends here
--
2.20.1
--------------E6B7393FF90421271E72F100--
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 12 Aug 2021 09:24:34 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 12 05:24:34 2021 Received: from localhost ([127.0.0.1]:37605 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mE6wz-0001M5-RB for submit <at> debbugs.gnu.org; Thu, 12 Aug 2021 05:24:34 -0400 Received: from server.qxqx.de ([178.63.65.180]:51191 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1mE6ww-0001Lj-MB; Thu, 12 Aug 2021 05:24:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID: References:Cc:To:Subject:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=1/NAMhdhCAQoAwSar/mnKa6p1gF9Kj9u70aQDXXvs/I=; b=Vz2rFSIR3R1syGGK8FyEjXXWQk /aE6HFJOEWGlR1lQj9n4TNnRltNSdvbHCDMhnPaAq8IYEUTYFvj1uDQnlDzsqR3DpSF4PTU0XrafO MGImMuwtL/NgyHisj+6aeYwg6SVQd9IpELjau6Kfk7qpXv1X4HMtV13SIwadGtDQjPaQ=; From: Daniel Mendler <mail@HIDDEN> Subject: Re: [PATCH] Add new `completion-filter-completions` API and deferred highlighting To: 47711 <at> debbugs.gnu.org, 48841 <at> debbugs.gnu.org References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> Message-ID: <fff6e291-bbcc-93e3-92e7-00af4664b8d4@HIDDEN> Date: Thu, 12 Aug 2021 11:24:22 +0200 MIME-Version: 1.0 In-Reply-To: <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> Content-Type: multipart/mixed; boundary="------------4B3E2A198290BEF506AC64C4" Content-Language: en-US X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: Eli Zaretskii <eliz@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN>, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------4B3E2A198290BEF506AC64C4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 8/11/21 6:11 PM, Daniel Mendler wrote: > 2. In `completion--nth-completion' set `completion--filter-completions' > to nil, unless `(memq style '(emacs21 emacs22 basic > partial-completion initials flex))' such that custom completion > styles which wrap the completion functions don't see the new return > value format, except if the custom style opts in explicitly by > binding `completion--filter-completions'. An alternative criterion is > `(memq fun '(completion-emacs22-all-completions) ...)'. Unfortunately > this approach will still not work if the user has advised a > `completion-x-all-completions' function. The only 100% safe approach > seems to transparently redirect calls to > `completion-x-all-completions' to `completion--x-filter-completions', > which returns the results in the new format. I attached two patch variants which can be placed on top of my previous patch to improve the backward compatibility of the internal API. Variant 1: Set 'completion--return-alist-flag' only for the existing completion styles, such that they transparently upgrade to the alist return format. If the variable is not set, the completion styles return the result as plain list retaining backward compatibility. The variable is purely for internal use, new completion styles should return their results as an alist on Emacs 28 and newer. Variant 2: Add an optional argument FILTER to each of the completion styles 'all' functions, e.g., 'completion-basic-all-completions'. In 'completion--nth-completion' try to call the function with the additional FILTER argument to upgrade to the alist return format. If this fails with a 'wrong-number-of-arguments' error, retry again without the argument. Daniel --------------4B3E2A198290BEF506AC64C4 Content-Type: text/plain; charset=UTF-8; name="variant1-restrict.el" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="variant1-restrict.el" RnJvbSA1NTM5ZWVhN2RmMTU3MGI2YjUwNDViZTJiMzgzZDJiZmJkNDQ3ODllIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBEYW5pZWwgTWVuZGxlciA8bWFpbEBkYW5pZWwtbWVu ZGxlci5kZT4KRGF0ZTogVGh1LCAxMiBBdWcgMjAyMSAxMDoyMDoxMCArMDIwMApTdWJqZWN0 OiBbUEFUQ0hdIFNldCAnY29tcGxldGlvbi0tcmV0dXJuLWFsaXN0LWZsYWcnIG9ubHkgZm9y IHRoZSBleGlzdGluZwogc3R5bGVzCgpUaGlzIGF2b2lkcyBwcm9ibGVtcyBpZiBhIHBhY2th Z2Ugd3JhcHMgYW4gZXhpc3RpbmcgY29tcGxldGlvbgpzdHlsZSBmdW5jdGlvbiBpbiBhIGN1 c3RvbSBjb21wbGV0aW9uIHN0eWxlLgotLS0KIGxpc3AvbWluaWJ1ZmZlci5lbCB8IDY2ICsr KysrKysrKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0KIDEgZmlsZSBj aGFuZ2VkLCAzNiBpbnNlcnRpb25zKCspLCAzMCBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQg YS9saXNwL21pbmlidWZmZXIuZWwgYi9saXNwL21pbmlidWZmZXIuZWwKaW5kZXggYmE4ODU1 YzRlYS4uMzI1NzM0OWExYSAxMDA2NDQKLS0tIGEvbGlzcC9taW5pYnVmZmVyLmVsCisrKyBi L2xpc3AvbWluaWJ1ZmZlci5lbApAQCAtMTAzOSwxNiArMTAzOSwxNiBAQCBjb21wbGV0aW9u LS1zdHlsZXMKICAgICAgICAgKGRlbGV0ZS1kdXBzIChhcHBlbmQgKGNkciBvdmVyKSAoY29w eS1zZXF1ZW5jZSBjb21wbGV0aW9uLXN0eWxlcykpKQogICAgICAgIGNvbXBsZXRpb24tc3R5 bGVzKSkpCiAKLShkZWZ2YXIgY29tcGxldGlvbi0tZmlsdGVyLWNvbXBsZXRpb25zIG5pbAor KGRlZnZhciBjb21wbGV0aW9uLS1yZXR1cm4tYWxpc3QtZmxhZyBuaWwKICAgIkVuYWJsZSB0 aGUgbmV3IGNvbXBsZXRpb25zIHJldHVybiB2YWx1ZSBmb3JtYXQuCiBJZiB0aGlzIHZhcmlh YmxlIGlzIG5vbi1uaWwgdGhlIGBhbGwtY29tcGxldGlvbnMnIGZ1bmN0aW9uIG9mIGEKIGNv bXBsZXRpb24gc3R5bGUgc2hvdWxkIHJldHVybiB0aGUgcmVzdWx0cyBpbiB0aGUgbmV3IGFs aXN0IGZvcm1hdCBvZgogYGNvbXBsZXRpb24tZmlsdGVyLWNvbXBsZXRpb25zJy4gIFRoaXMg dmFyaWFibGUgaXMgcHVyZWx5IG5lZWRlZCB0bwogZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxp dHkgb2YgdGhlIGV4aXN0aW5nIGJ1aWx0aW4gY29tcGxldGlvbiBzdHlsZQotZnVuY3Rpb25z LiAgTmV3IGNvbXBsZXRpb24gc3R5bGUgZnVuY3Rpb25zIG1heSBhbHdheXMgcmV0dXJuIHRo ZWlyCi1yZXN1bHRzIGluIHRoZSBuZXcgYWxpc3QgZm9ybWF0LCBzaW5jZSBgY29tcGxldGlv bi1hbGwtY29tcGxldGlvbnMnCi10cmFuc3BhcmVudGx5IGNvbnZlcnRzIGJhY2sgdG8gdGhl IG9sZCBpbXByb3BlciBsaXN0IG9mIGNvbXBsZXRpb25zCi13aXRoIGJhc2Ugc2l6ZSBpbiB0 aGUgbGFzdCBjZHIuIikKK2Z1bmN0aW9ucyBhcyBvZiBFbWFjcyAyOC4gIE5ldyBjb21wbGV0 aW9uIHN0eWxlIGZ1bmN0aW9ucyBzaG91bGQKK2Fsd2F5cyByZXR1cm4gdGhlaXIgcmVzdWx0 cyBpbiB0aGUgbmV3IGFsaXN0IGZvcm1hdCwgc2luY2UKK2Bjb21wbGV0aW9uLWFsbC1jb21w bGV0aW9ucycgdHJhbnNwYXJlbnRseSBjb252ZXJ0cyBiYWNrIHRvIHRoZSBvbGQKK2ltcHJv cGVyIGxpc3Qgb2YgY29tcGxldGlvbnMgd2l0aCBiYXNlIHNpemUgaW4gdGhlIGxhc3QgY2Ry LiIpCiAKIChkZWZ1biBjb21wbGV0aW9uLS1udGgtY29tcGxldGlvbiAobiBzdHJpbmcgdGFi bGUgcHJlZCBwb2ludCBtZXRhZGF0YSkKICAgIkNhbGwgdGhlIE50aCBtZXRob2Qgb2YgY29t cGxldGlvbiBzdHlsZXMuIgpAQCAtMTA4NCw3ICsxMDg0LDcgQEAgY29tcGxldGlvbi0tbnRo LWNvbXBsZXRpb24KICAgICAgICAgICAgICAgOzsgY29udHJhc3QgdG8gcGxhaW4gY29tcGxl dGlvbiB0YWJsZXMsIHRoZSBzYXZpbmdzIG9mCiAgICAgICAgICAgICAgIDs7IGRlZmVycmVk IGhpZ2hsaWdodGluZyB3b3VsZCBiZSBtaW5pbWFsIGluIHRoZSBjYXNlIG9mCiAgICAgICAg ICAgICAgIDs7IHF1b3RlZCBjb21wbGV0aW9uIHRhYmxlcy4KLSAgICAgICAgICAgICAgKHNl dHEgY29tcGxldGlvbi0tZmlsdGVyLWNvbXBsZXRpb25zIG5pbCkKKyAgICAgICAgICAgICAg KHNldHEgY29tcGxldGlvbi0tcmV0dXJuLWFsaXN0LWZsYWcgbmlsKQogICAgICAgICAgICAg ICAoc2V0cSBzdHJpbmcgKHBvcCBuZXcpKQogICAgICAgICAgICAgICAoc2V0cSB0YWJsZSAo cG9wIG5ldykpCiAgICAgICAgICAgICAgIChzZXRxIHBvaW50IChwb3AgbmV3KSkKQEAgLTEw OTMsMTggKzEwOTMsMzUgQEAgY29tcGxldGlvbi0tbnRoLWNvbXBsZXRpb24KICAgICAgICAg IChyZXN1bHQtYW5kLXN0eWxlCiAgICAgICAgICAgKGNvbXBsZXRpb24tLXNvbWUKICAgICAg ICAgICAgKGxhbWJkYSAoc3R5bGUpCi0gICAgICAgICAgICAgKGxldCAoKHByb2JlIChmdW5j YWxsIChudGggbiAoYXNzcSBzdHlsZQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgY29tcGxldGlvbi1zdHlsZXMtYWxpc3QpKQotICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJpbmcgdGFibGUgcHJlZCBwb2ludCkpKQor ICAgICAgICAgICAgIChsZXQqICgoZnVuIChudGggbiAoYXNzcSBzdHlsZSBjb21wbGV0aW9u LXN0eWxlcy1hbGlzdCkpKQorICAgICAgICAgICAgICAgICAgICA7OyBUcmFuc3BhcmVudGx5 IHVwZ3JhZGUgdGhlIHJldHVybiB2YWx1ZSBmb3IKKyAgICAgICAgICAgICAgICAgICAgOzsg ZXhpc3RpbmcgYnVpbHQtaW4gc3R5bGVzIGFzIG9mIEVtYWNzIDI4LiAgTm8KKyAgICAgICAg ICAgICAgICAgICAgOzsgbmV3IHN0eWxlcyBzaG91bGQgYmUgYWRkZWQgaGVyZS4gTmV3IGNv bXBsZXRpb24KKyAgICAgICAgICAgICAgICAgICAgOzsgc3R5bGVzIHNob3VsZCBkaXJlY3Rs eSByZXR1cm4gdGhlIG5ldworICAgICAgICAgICAgICAgICAgICA7OyBjb21wbGV0aW9uIGZv cm1hdC5lbAorICAgICAgICAgICAgICAgICAgICAoY29tcGxldGlvbi0tcmV0dXJuLWFsaXN0 LWZsYWcKKyAgICAgICAgICAgICAgICAgICAgIChhbmQgY29tcGxldGlvbi0tcmV0dXJuLWFs aXN0LWZsYWcKKyAgICAgICAgICAgICAgICAgICAgICAgICAgKG1lbXEgc3R5bGUgJyhlbWFj czIxIGVtYWNzMjIgYmFzaWMgc3Vic3RyaW5nCisgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcGFydGlhbC1jb21wbGV0aW9uIGluaXRpYWxzIGZsZXgpKSkpCisg ICAgICAgICAgICAgICAgICAgIChwcm9iZSAoZnVuY2FsbCBmdW4gc3RyaW5nIHRhYmxlIHBy ZWQgcG9pbnQpKSkKICAgICAgICAgICAgICAgIChhbmQgcHJvYmUgKGNvbnMgcHJvYmUgc3R5 bGUpKSkpCiAgICAgICAgICAgIChjb21wbGV0aW9uLS1zdHlsZXMgbWQpKSkKLSAgICAgICAg IChzdHlsZS1tZCAoZ2V0IChjZHIgcmVzdWx0LWFuZC1zdHlsZSkgJ2NvbXBsZXRpb24tLXN0 eWxlLW1ldGFkYXRhKSkpCisgICAgICAgICAoc3R5bGUtbWQgKGdldCAoY2RyIHJlc3VsdC1h bmQtc3R5bGUpICdjb21wbGV0aW9uLS1zdHlsZS1tZXRhZGF0YSkpCisgICAgICAgICAocmVz dWx0IChjYXIgcmVzdWx0LWFuZC1zdHlsZSkpKQogICAgICh3aGVuIChhbmQgc3R5bGUtbWQg bWV0YWRhdGEpCiAgICAgICAoc2V0Y2RyIG1ldGFkYXRhIChjZHIgKGZ1bmNhbGwgc3R5bGUt bWQKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJpbmcgdGFibGUg cHJlZCBwb2ludCBtZXRhZGF0YSkpKSkKKyAgICAod2hlbiAoYW5kIChub3QgY29tcGxldGlv bi0tcmV0dXJuLWFsaXN0LWZsYWcpICg9IG4gMikgKGNvbnNwIChjYXIgcmVzdWx0KSkpCisg ICAgICA7OyBHaXZlIHRoZSBjb21wbGV0aW9uIHN0eWxlcyBzb21lIGZyZWVkb20hICBJZiB0 aGV5IGFyZQorICAgICAgOzsgdGFyZ2V0aW5nIEVtYWNzIDI4IHVwd2FyZHMgb25seSwgdGhl eSBtYXkgcmV0dXJuIGEgcmVzdWx0CisgICAgICA7OyB3aXRoIGRlZmVycmVkIGhpZ2hsaWdo dGluZy4gIFdlIGNvbnZlcnQgYmFjayB0byB0aGUgb2xkCisgICAgICA7OyBmb3JtYXQgaGVy ZSBieSBhcHBseWluZyB0aGUgaGlnaGxpZ2h0aW5nIGVhZ2VybHkuCisgICAgICAoc2V0cSBy ZXN1bHQgKG5jb25jIChmdW5jYWxsIChjZHIgKGFzc3EgJ2hpZ2hsaWdodCByZXN1bHQpKQor ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoY2RyIChhc3NxICdjb21wbGV0 aW9ucyByZXN1bHQpKSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgKGNkciAoYXNzcSAn YmFzZSByZXN1bHQpKSkpKQogICAgIChpZiByZXF1b3RlCi0gICAgICAgIChmdW5jYWxsIHJl cXVvdGUgKGNhciByZXN1bHQtYW5kLXN0eWxlKSBuKQotICAgICAgKGNhciByZXN1bHQtYW5k LXN0eWxlKSkpKQorICAgICAgICAoZnVuY2FsbCByZXF1b3RlIHJlc3VsdCBuKQorICAgICAg cmVzdWx0KSkpCiAKIChkZWZ1biBjb21wbGV0aW9uLXRyeS1jb21wbGV0aW9uIChzdHJpbmcg dGFibGUgcHJlZCBwb2ludCAmb3B0aW9uYWwgbWV0YWRhdGEpCiAgICJUcnkgdG8gY29tcGxl dGUgU1RSSU5HIHVzaW5nIGNvbXBsZXRpb24gdGFibGUgVEFCTEUuCkBAIC0xMTI0LDE5ICsx MTQxLDggQEAgY29tcGxldGlvbi1hbGwtY29tcGxldGlvbnMKIFRoZSBNRVRBREFUQSBtYXkg YmUgbW9kaWZpZWQgYnkgdGhlIGNvbXBsZXRpb24gc3R5bGUuICBUaGlzIGZ1bmN0aW9uCiBo YXMgYmVlbiBzdXBlcnNlZGVkIGJ5IGBjb21wbGV0aW9uLWZpbHRlci1jb21wbGV0aW9ucycs IHdoaWNoIHJldHVybnMKIHJpY2hlciBpbmZvcm1hdGlvbiBhbmQgc3VwcG9ydHMgZGVmZXJy ZWQgY2FuZGlkYXRlIGhpZ2hsaWdodGluZy4iCi0gIChsZXQgKChjb21wbGV0aW9uLS1maWx0 ZXItY29tcGxldGlvbnMgbmlsKQotICAgICAgICAocmVzdWx0IChjb21wbGV0aW9uLS1udGgt Y29tcGxldGlvbiAyIHN0cmluZyB0YWJsZQotICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBwcmVkIHBvaW50IG1ldGFkYXRhKSkpCi0gICAgKGlmIChhbmQg cmVzdWx0IChjb25zcCAoY2FyIHJlc3VsdCkpKQotICAgICAgICA7OyBHaXZlIHRoZSBjb21w bGV0aW9uIHN0eWxlcyBzb21lIGZyZWVkb20hCi0gICAgICAgIDs7IElmIHRoZXkgYXJlIHRh cmdldGluZyBFbWFjcyAyOCB1cHdhcmRzIG9ubHksIHRoZXkKLSAgICAgICAgOzsgbWF5IGFs d2F5cyByZXR1cm4gYSByZXN1bHQgd2l0aCBkZWZlcnJlZAotICAgICAgICA7OyBoaWdobGln aHRpbmcuICBXZSBjb252ZXJ0IGJhY2sgdG8gdGhlIG9sZCBmb3JtYXQKLSAgICAgICAgOzsg aGVyZSBieSBhcHBseWluZyB0aGUgaGlnaGxpZ2h0aW5nIGVhZ2VybHkuCi0gICAgICAgIChu Y29uYyAoZnVuY2FsbCAoY2RyIChhc3NxICdoaWdobGlnaHQgcmVzdWx0KSkKLSAgICAgICAg ICAgICAgICAgICAgICAgIChjZHIgKGFzc3EgJ2NvbXBsZXRpb25zIHJlc3VsdCkpKQotICAg ICAgICAgICAgICAgKGNkciAoYXNzcSAnYmFzZSByZXN1bHQpKSkKLSAgICAgIHJlc3VsdCkp KQorICAobGV0ICgoY29tcGxldGlvbi0tcmV0dXJuLWFsaXN0LWZsYWcgbmlsKSkKKyAgICAo Y29tcGxldGlvbi0tbnRoLWNvbXBsZXRpb24gMiBzdHJpbmcgdGFibGUgcHJlZCBwb2ludCBt ZXRhZGF0YSkpKQogCiAoZGVmdW4gY29tcGxldGlvbi1maWx0ZXItY29tcGxldGlvbnMgKHN0 cmluZyB0YWJsZSBwcmVkIHBvaW50IG1ldGFkYXRhKQogICAiRmlsdGVyIHRoZSBwb3NzaWJs ZSBjb21wbGV0aW9ucyBvZiBTVFJJTkcgaW4gY29tcGxldGlvbiB0YWJsZSBUQUJMRS4KQEAg LTExNTIsNyArMTE1OCw3IEBAIGNvbXBsZXRpb24tZmlsdGVyLWNvbXBsZXRpb25zCiAtIGNv bXBsZXRpb25zOiBUaGUgbGlzdCBvZiBjb21wbGV0aW9ucy4KIAogVGhpcyBmdW5jdGlvbiBz dXBlcnNlZGVzIHRoZSBmdW5jdGlvbiBgY29tcGxldGlvbi1hbGwtY29tcGxldGlvbnMnLiIK LSAgKGxldCogKChjb21wbGV0aW9uLS1maWx0ZXItY29tcGxldGlvbnMgdCkKKyAgKGxldCog KChjb21wbGV0aW9uLS1yZXR1cm4tYWxpc3QtZmxhZyB0KQogICAgICAgICAgKHJlc3VsdCAo Y29tcGxldGlvbi0tbnRoLWNvbXBsZXRpb24gMiBzdHJpbmcgdGFibGUKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByZWQgcG9pbnQgbWV0YWRhdGEp KSkKICAgICAoaWYgKGFuZCByZXN1bHQgKG5vdCAoY29uc3AgKGNhciByZXN1bHQpKSkpCkBA IC0yMTIwLDggKzIxMjYsOCBAQCBjb21wbGV0aW9uLS1oaWxpdC1jb21tb25hbGl0eQogCiAo ZGVmdW4gY29tcGxldGlvbi0tZGVmZXJyZWQtaGlsaXQgKGNvbXBsZXRpb25zIHByZWZpeC1s ZW4gYmFzZSBlbmQpCiAgICJSZXR1cm4gY29tcGxldGlvbnMgaW4gb2xkIGZvcm1hdCBvciBu ZXcgYWxpc3QgZm9ybWF0LgotSWYgYGNvbXBsZXRpb24tLWZpbHRlci1jb21wbGV0aW9ucycg aXMgbm9uLW5pbCB1c2UgdGhlIG5ldyBmb3JtYXQuIgotICAoaWYgY29tcGxldGlvbi0tZmls dGVyLWNvbXBsZXRpb25zCitJZiBgY29tcGxldGlvbi0tcmV0dXJuLWFsaXN0LWZsYWcnIGlz IG5vbi1uaWwgdXNlIHRoZSBuZXcgZm9ybWF0LiIKKyAgKGlmIGNvbXBsZXRpb24tLXJldHVy bi1hbGlzdC1mbGFnCiAgICAgICAod2hlbiBjb21wbGV0aW9ucwogICAgICAgICBgKChiYXNl IC4gLGJhc2UpCiAgICAgICAgICAgKGVuZCAuICxlbmQpCkBAIC0zNTg2LDkgKzM1OTIsOSBA QCBmbGV4LXNjb3JlLW1hdGNoLXRpZ2h0bmVzcwogCiAoZGVmdW4gY29tcGxldGlvbi1wY20t LWRlZmVycmVkLWhpbGl0IChwYXR0ZXJuIGNvbXBsZXRpb25zIGJhc2UgZW5kKQogICAiUmV0 dXJuIGNvbXBsZXRpb25zIGluIG9sZCBmb3JtYXQgb3IgbmV3IGFsaXN0IGZvcm1hdC4KLUlm IGBjb21wbGV0aW9uLS1maWx0ZXItY29tcGxldGlvbnMnIGlzIG5vbi1uaWwgdXNlIHRoZSBu ZXcgZm9ybWF0LiIKK0lmIGBjb21wbGV0aW9uLS1yZXR1cm4tYWxpc3QtZmxhZycgaXMgbm9u LW5pbCB1c2UgdGhlIG5ldyBmb3JtYXQuIgogICAod2hlbiBjb21wbGV0aW9ucwotICAgIChp ZiBjb21wbGV0aW9uLS1maWx0ZXItY29tcGxldGlvbnMKKyAgICAoaWYgY29tcGxldGlvbi0t cmV0dXJuLWFsaXN0LWZsYWcKICAgICAgICAgYCgoYmFzZSAuICxiYXNlKQogICAgICAgICAg IChlbmQgLiAsZW5kKQogICAgICAgICAgIChoaWdobGlnaHQgLiAsKGFwcGx5LXBhcnRpYWxs eQotLSAKMi4yMC4xCgo= --------------4B3E2A198290BEF506AC64C4 Content-Type: text/plain; charset=UTF-8; name="variant2-argument.el" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="variant2-argument.el" RnJvbSBmMGRhMWYxZDkyZjIwZGY3ZDkyZDk3NjIyOTVhYzUxMzkwZmNlZTgzIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBEYW5pZWwgTWVuZGxlciA8bWFpbEBkYW5pZWwtbWVu ZGxlci5kZT4KRGF0ZTogVGh1LCAxMiBBdWcgMjAyMSAxMDoxMDowMiArMDIwMApTdWJqZWN0 OiBbUEFUQ0hdIFVzZSBGSUxURVIgYXJndW1lbnQgaW5zdGVhZCBvZiBnbG9iYWwKIGBjb21w bGV0aW9uLS1maWx0ZXItY29tcGxldGlvbnNgCgotLS0KIGxpc3AvbWluaWJ1ZmZlci5lbCB8 IDExOSArKysrKysrKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0KIDEg ZmlsZSBjaGFuZ2VkLCA2NCBpbnNlcnRpb25zKCspLCA1NSBkZWxldGlvbnMoLSkKCmRpZmYg LS1naXQgYS9saXNwL21pbmlidWZmZXIuZWwgYi9saXNwL21pbmlidWZmZXIuZWwKaW5kZXgg YmE4ODU1YzRlYS4uMGY4Yjg1ZGRkNCAxMDA2NDQKLS0tIGEvbGlzcC9taW5pYnVmZmVyLmVs CisrKyBiL2xpc3AvbWluaWJ1ZmZlci5lbApAQCAtMTAzOSwxOCArMTAzOSw3IEBAIGNvbXBs ZXRpb24tLXN0eWxlcwogICAgICAgICAoZGVsZXRlLWR1cHMgKGFwcGVuZCAoY2RyIG92ZXIp IChjb3B5LXNlcXVlbmNlIGNvbXBsZXRpb24tc3R5bGVzKSkpCiAgICAgICAgY29tcGxldGlv bi1zdHlsZXMpKSkKIAotKGRlZnZhciBjb21wbGV0aW9uLS1maWx0ZXItY29tcGxldGlvbnMg bmlsCi0gICJFbmFibGUgdGhlIG5ldyBjb21wbGV0aW9ucyByZXR1cm4gdmFsdWUgZm9ybWF0 LgotSWYgdGhpcyB2YXJpYWJsZSBpcyBub24tbmlsIHRoZSBgYWxsLWNvbXBsZXRpb25zJyBm dW5jdGlvbiBvZiBhCi1jb21wbGV0aW9uIHN0eWxlIHNob3VsZCByZXR1cm4gdGhlIHJlc3Vs dHMgaW4gdGhlIG5ldyBhbGlzdCBmb3JtYXQgb2YKLWBjb21wbGV0aW9uLWZpbHRlci1jb21w bGV0aW9ucycuICBUaGlzIHZhcmlhYmxlIGlzIHB1cmVseSBuZWVkZWQgdG8KLWZvciBiYWNr d2FyZCBjb21wYXRpYmlsaXR5IG9mIHRoZSBleGlzdGluZyBidWlsdGluIGNvbXBsZXRpb24g c3R5bGUKLWZ1bmN0aW9ucy4gIE5ldyBjb21wbGV0aW9uIHN0eWxlIGZ1bmN0aW9ucyBtYXkg YWx3YXlzIHJldHVybiB0aGVpcgotcmVzdWx0cyBpbiB0aGUgbmV3IGFsaXN0IGZvcm1hdCwg c2luY2UgYGNvbXBsZXRpb24tYWxsLWNvbXBsZXRpb25zJwotdHJhbnNwYXJlbnRseSBjb252 ZXJ0cyBiYWNrIHRvIHRoZSBvbGQgaW1wcm9wZXIgbGlzdCBvZiBjb21wbGV0aW9ucwotd2l0 aCBiYXNlIHNpemUgaW4gdGhlIGxhc3QgY2RyLiIpCi0KLShkZWZ1biBjb21wbGV0aW9uLS1u dGgtY29tcGxldGlvbiAobiBzdHJpbmcgdGFibGUgcHJlZCBwb2ludCBtZXRhZGF0YSkKKyhk ZWZ1biBjb21wbGV0aW9uLS1udGgtY29tcGxldGlvbiAobiBzdHJpbmcgdGFibGUgcHJlZCBw b2ludCBtZXRhZGF0YSAmb3B0aW9uYWwgZmlsdGVyKQogICAiQ2FsbCB0aGUgTnRoIG1ldGhv ZCBvZiBjb21wbGV0aW9uIHN0eWxlcy4iCiAgIDs7IFdlIHByb3ZpZGUgc3BlY2lhbCBzdXBw b3J0IGZvciBxdW90aW5nL3VucXVvdGluZyBoZXJlIGJlY2F1c2UgaXQgY2Fubm90CiAgIDs7 IHJlbGlhYmx5IGJlIGRvbmUgd2l0aGluIHRoZSBub3JtYWwgY29tcGxldGlvbi10YWJsZSBy b3V0aW5lczogQ29tcGxldGlvbgpAQCAtMTA4NCw3ICsxMDczLDcgQEAgY29tcGxldGlvbi0t bnRoLWNvbXBsZXRpb24KICAgICAgICAgICAgICAgOzsgY29udHJhc3QgdG8gcGxhaW4gY29t cGxldGlvbiB0YWJsZXMsIHRoZSBzYXZpbmdzIG9mCiAgICAgICAgICAgICAgIDs7IGRlZmVy cmVkIGhpZ2hsaWdodGluZyB3b3VsZCBiZSBtaW5pbWFsIGluIHRoZSBjYXNlIG9mCiAgICAg ICAgICAgICAgIDs7IHF1b3RlZCBjb21wbGV0aW9uIHRhYmxlcy4KLSAgICAgICAgICAgICAg KHNldHEgY29tcGxldGlvbi0tZmlsdGVyLWNvbXBsZXRpb25zIG5pbCkKKyAgICAgICAgICAg ICAgKHNldHEgZmlsdGVyIG5pbCkKICAgICAgICAgICAgICAgKHNldHEgc3RyaW5nIChwb3Ag bmV3KSkKICAgICAgICAgICAgICAgKHNldHEgdGFibGUgKHBvcCBuZXcpKQogICAgICAgICAg ICAgICAoc2V0cSBwb2ludCAocG9wIG5ldykpCkBAIC0xMDkzLDE4ICsxMDgyLDM3IEBAIGNv bXBsZXRpb24tLW50aC1jb21wbGV0aW9uCiAgICAgICAgICAocmVzdWx0LWFuZC1zdHlsZQog ICAgICAgICAgIChjb21wbGV0aW9uLS1zb21lCiAgICAgICAgICAgIChsYW1iZGEgKHN0eWxl KQotICAgICAgICAgICAgIChsZXQgKChwcm9iZSAoZnVuY2FsbCAobnRoIG4gKGFzc3Egc3R5 bGUKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNv bXBsZXRpb24tc3R5bGVzLWFsaXN0KSkKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgc3RyaW5nIHRhYmxlIHByZWQgcG9pbnQpKSkKKyAgICAgICAgICAgICAobGV0KiAo KGZ1biAobnRoIG4gKGFzc3Egc3R5bGUgY29tcGxldGlvbi1zdHlsZXMtYWxpc3QpKSkKKyAg ICAgICAgICAgICAgICAgICAgKHByb2JlCisgICAgICAgICAgICAgICAgICAgICAoaWYgZmls dGVyCisgICAgICAgICAgICAgICAgICAgICAgICAgOzsgSW4gb3JkZXIgdG8gcmV0YWluIGJh Y2t3YXJkIGNvbXBhdGliaWxpdHkKKyAgICAgICAgICAgICAgICAgICAgICAgICA7OyBvZiB0 aGUgY2FsbGluZyBjb252ZW50aW9uIG9mIHRoZSBleGlzaXRpbmcKKyAgICAgICAgICAgICAg ICAgICAgICAgICA7OyBjb21wbGV0aW9uIHN0eWxlcywgYWRkIGEgZm91cnRoIEZJTFRFUgor ICAgICAgICAgICAgICAgICAgICAgICAgIDs7IGFyZ3VtZW50IHRvIG9wdC1pbiB0byB0aGUg bmV3IHJldHVybiB2YWx1ZQorICAgICAgICAgICAgICAgICAgICAgICAgIDs7IGZvcm1hdC4K KyAgICAgICAgICAgICAgICAgICAgICAgICAoY29uZGl0aW9uLWNhc2UgbmlsCisgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIChmdW5jYWxsIGZ1biBzdHJpbmcgdGFibGUgcHJlZCBw b2ludCBmaWx0ZXIpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAod3JvbmctbnVtYmVy LW9mLWFyZ3VtZW50cworICAgICAgICAgICAgICAgICAgICAgICAgICAgIChmdW5jYWxsIGZ1 biBzdHJpbmcgdGFibGUgcHJlZCBwb2ludCkpKQorICAgICAgICAgICAgICAgICAgICAgICAo ZnVuY2FsbCBmdW4gc3RyaW5nIHRhYmxlIHByZWQgcG9pbnQpKSkpCiAgICAgICAgICAgICAg ICAoYW5kIHByb2JlIChjb25zIHByb2JlIHN0eWxlKSkpKQogICAgICAgICAgICAoY29tcGxl dGlvbi0tc3R5bGVzIG1kKSkpCi0gICAgICAgICAoc3R5bGUtbWQgKGdldCAoY2RyIHJlc3Vs dC1hbmQtc3R5bGUpICdjb21wbGV0aW9uLS1zdHlsZS1tZXRhZGF0YSkpKQorICAgICAgICAg KHN0eWxlLW1kIChnZXQgKGNkciByZXN1bHQtYW5kLXN0eWxlKSAnY29tcGxldGlvbi0tc3R5 bGUtbWV0YWRhdGEpKQorICAgICAgICAgKHJlc3VsdCAoY2FyIHJlc3VsdC1hbmQtc3R5bGUp KSkKICAgICAod2hlbiAoYW5kIHN0eWxlLW1kIG1ldGFkYXRhKQogICAgICAgKHNldGNkciBt ZXRhZGF0YSAoY2RyIChmdW5jYWxsIHN0eWxlLW1kCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgc3RyaW5nIHRhYmxlIHByZWQgcG9pbnQgbWV0YWRhdGEpKSkpCisg ICAgKHdoZW4gKGFuZCAobm90IGZpbHRlcikgKD0gbiAyKSAoY29uc3AgKGNhciByZXN1bHQp KSkKKyAgICAgIDs7IEdpdmUgdGhlIGNvbXBsZXRpb24gc3R5bGVzIHNvbWUgZnJlZWRvbSEg IElmIHRoZXkgYXJlCisgICAgICA7OyB0YXJnZXRpbmcgRW1hY3MgMjggdXB3YXJkcyBvbmx5 LCB0aGV5IG1heSByZXR1cm4gYSByZXN1bHQKKyAgICAgIDs7IHdpdGggZGVmZXJyZWQgaGln aGxpZ2h0aW5nLiAgV2UgY29udmVydCBiYWNrIHRvIHRoZSBvbGQKKyAgICAgIDs7IGZvcm1h dCBoZXJlIGJ5IGFwcGx5aW5nIHRoZSBoaWdobGlnaHRpbmcgZWFnZXJseS4KKyAgICAgIChz ZXRxIHJlc3VsdCAobmNvbmMgKGZ1bmNhbGwgKGNkciAoYXNzcSAnaGlnaGxpZ2h0IHJlc3Vs dCkpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjZHIgKGFzc3EgJ2Nv bXBsZXRpb25zIHJlc3VsdCkpKQorICAgICAgICAgICAgICAgICAgICAgICAgICAoY2RyIChh c3NxICdiYXNlIHJlc3VsdCkpKSkpCiAgICAgKGlmIHJlcXVvdGUKLSAgICAgICAgKGZ1bmNh bGwgcmVxdW90ZSAoY2FyIHJlc3VsdC1hbmQtc3R5bGUpIG4pCi0gICAgICAoY2FyIHJlc3Vs dC1hbmQtc3R5bGUpKSkpCisgICAgICAgIChmdW5jYWxsIHJlcXVvdGUgcmVzdWx0IG4pCisg ICAgICByZXN1bHQpKSkKIAogKGRlZnVuIGNvbXBsZXRpb24tdHJ5LWNvbXBsZXRpb24gKHN0 cmluZyB0YWJsZSBwcmVkIHBvaW50ICZvcHRpb25hbCBtZXRhZGF0YSkKICAgIlRyeSB0byBj b21wbGV0ZSBTVFJJTkcgdXNpbmcgY29tcGxldGlvbiB0YWJsZSBUQUJMRS4KQEAgLTExMjQs MTkgKzExMzIsNyBAQCBjb21wbGV0aW9uLWFsbC1jb21wbGV0aW9ucwogVGhlIE1FVEFEQVRB IG1heSBiZSBtb2RpZmllZCBieSB0aGUgY29tcGxldGlvbiBzdHlsZS4gIFRoaXMgZnVuY3Rp b24KIGhhcyBiZWVuIHN1cGVyc2VkZWQgYnkgYGNvbXBsZXRpb24tZmlsdGVyLWNvbXBsZXRp b25zJywgd2hpY2ggcmV0dXJucwogcmljaGVyIGluZm9ybWF0aW9uIGFuZCBzdXBwb3J0cyBk ZWZlcnJlZCBjYW5kaWRhdGUgaGlnaGxpZ2h0aW5nLiIKLSAgKGxldCAoKGNvbXBsZXRpb24t LWZpbHRlci1jb21wbGV0aW9ucyBuaWwpCi0gICAgICAgIChyZXN1bHQgKGNvbXBsZXRpb24t LW50aC1jb21wbGV0aW9uIDIgc3RyaW5nIHRhYmxlCi0gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHByZWQgcG9pbnQgbWV0YWRhdGEpKSkKLSAgICAoaWYg KGFuZCByZXN1bHQgKGNvbnNwIChjYXIgcmVzdWx0KSkpCi0gICAgICAgIDs7IEdpdmUgdGhl IGNvbXBsZXRpb24gc3R5bGVzIHNvbWUgZnJlZWRvbSEKLSAgICAgICAgOzsgSWYgdGhleSBh cmUgdGFyZ2V0aW5nIEVtYWNzIDI4IHVwd2FyZHMgb25seSwgdGhleQotICAgICAgICA7OyBt YXkgYWx3YXlzIHJldHVybiBhIHJlc3VsdCB3aXRoIGRlZmVycmVkCi0gICAgICAgIDs7IGhp Z2hsaWdodGluZy4gIFdlIGNvbnZlcnQgYmFjayB0byB0aGUgb2xkIGZvcm1hdAotICAgICAg ICA7OyBoZXJlIGJ5IGFwcGx5aW5nIHRoZSBoaWdobGlnaHRpbmcgZWFnZXJseS4KLSAgICAg ICAgKG5jb25jIChmdW5jYWxsIChjZHIgKGFzc3EgJ2hpZ2hsaWdodCByZXN1bHQpKQotICAg ICAgICAgICAgICAgICAgICAgICAgKGNkciAoYXNzcSAnY29tcGxldGlvbnMgcmVzdWx0KSkp Ci0gICAgICAgICAgICAgICAoY2RyIChhc3NxICdiYXNlIHJlc3VsdCkpKQotICAgICAgcmVz dWx0KSkpCisgIChjb21wbGV0aW9uLS1udGgtY29tcGxldGlvbiAyIHN0cmluZyB0YWJsZSBw cmVkIHBvaW50IG1ldGFkYXRhKSkKIAogKGRlZnVuIGNvbXBsZXRpb24tZmlsdGVyLWNvbXBs ZXRpb25zIChzdHJpbmcgdGFibGUgcHJlZCBwb2ludCBtZXRhZGF0YSkKICAgIkZpbHRlciB0 aGUgcG9zc2libGUgY29tcGxldGlvbnMgb2YgU1RSSU5HIGluIGNvbXBsZXRpb24gdGFibGUg VEFCTEUuCkBAIC0xMTUyLDkgKzExNDgsOCBAQCBjb21wbGV0aW9uLWZpbHRlci1jb21wbGV0 aW9ucwogLSBjb21wbGV0aW9uczogVGhlIGxpc3Qgb2YgY29tcGxldGlvbnMuCiAKIFRoaXMg ZnVuY3Rpb24gc3VwZXJzZWRlcyB0aGUgZnVuY3Rpb24gYGNvbXBsZXRpb24tYWxsLWNvbXBs ZXRpb25zJy4iCi0gIChsZXQqICgoY29tcGxldGlvbi0tZmlsdGVyLWNvbXBsZXRpb25zIHQp Ci0gICAgICAgICAocmVzdWx0IChjb21wbGV0aW9uLS1udGgtY29tcGxldGlvbiAyIHN0cmlu ZyB0YWJsZQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg cHJlZCBwb2ludCBtZXRhZGF0YSkpKQorICAobGV0KiAoKHJlc3VsdCAoY29tcGxldGlvbi0t bnRoLWNvbXBsZXRpb24gMiBzdHJpbmcgdGFibGUKKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHByZWQgcG9pbnQgbWV0YWRhdGEgJ2ZpbHRlcikpKQog ICAgIChpZiAoYW5kIHJlc3VsdCAobm90IChjb25zcCAoY2FyIHJlc3VsdCkpKSkKICAgICAg ICAgOzsgRGVmZXJyZWQgaGlnaGxpZ2h0aW5nIGhhcyBiZWVuIHJlcXVlc3RlZCwgYnV0IHRo ZSBjb21wbGV0aW9uCiAgICAgICAgIDs7IHN0eWxlIHJldHVybmVkIGEgbm9uLWRlZmVycmVk IHJlc3VsdC4gQ29udmVydCB0aGUgcmVzdWx0IHRvIHRoZQpAQCAtMjExOCwxMCArMjExMywx MCBAQCBjb21wbGV0aW9uLS1oaWxpdC1jb21tb25hbGl0eQogICAgICBlbGVtKQogICAgY29t cGxldGlvbnMpKQogCi0oZGVmdW4gY29tcGxldGlvbi0tZGVmZXJyZWQtaGlsaXQgKGNvbXBs ZXRpb25zIHByZWZpeC1sZW4gYmFzZSBlbmQpCisoZGVmdW4gY29tcGxldGlvbi0tZGVmZXJy ZWQtaGlsaXQgKGNvbXBsZXRpb25zIHByZWZpeC1sZW4gYmFzZSBlbmQgZmlsdGVyKQogICAi UmV0dXJuIGNvbXBsZXRpb25zIGluIG9sZCBmb3JtYXQgb3IgbmV3IGFsaXN0IGZvcm1hdC4K LUlmIGBjb21wbGV0aW9uLS1maWx0ZXItY29tcGxldGlvbnMnIGlzIG5vbi1uaWwgdXNlIHRo ZSBuZXcgZm9ybWF0LiIKLSAgKGlmIGNvbXBsZXRpb24tLWZpbHRlci1jb21wbGV0aW9ucwor SWYgRklMVEVSIGlzIG5vbi1uaWwgdXNlIHRoZSBuZXcgZm9ybWF0LiIKKyAgKGlmIGZpbHRl cgogICAgICAgKHdoZW4gY29tcGxldGlvbnMKICAgICAgICAgYCgoYmFzZSAuICxiYXNlKQog ICAgICAgICAgIChlbmQgLiAsZW5kKQpAQCAtMzMwMCwxMiArMzI5NSwxNCBAQCBjb21wbGV0 aW9uLWVtYWNzMjEtdHJ5LWNvbXBsZXRpb24KICAgICAgICAgKGNvbnMgY29tcGxldGlvbiAo bGVuZ3RoIGNvbXBsZXRpb24pKQogICAgICAgY29tcGxldGlvbikpKQogCi0oZGVmdW4gY29t cGxldGlvbi1lbWFjczIxLWFsbC1jb21wbGV0aW9ucyAoc3RyaW5nIHRhYmxlIHByZWQgX3Bv aW50KQorKGRlZnVuIGNvbXBsZXRpb24tZW1hY3MyMS1hbGwtY29tcGxldGlvbnMgKHN0cmlu ZyB0YWJsZSBwcmVkIF9wb2ludAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAmb3B0aW9uYWwgZmlsdGVyKQogICAoY29tcGxldGlvbi0tZGVm ZXJyZWQtaGlsaXQKICAgIChhbGwtY29tcGxldGlvbnMgc3RyaW5nIHRhYmxlIHByZWQpCiAg ICAobGVuZ3RoIHN0cmluZykKICAgIChjYXIgKGNvbXBsZXRpb24tYm91bmRhcmllcyBzdHJp bmcgdGFibGUgcHJlZCAiIikpCi0gICAobGVuZ3RoIHN0cmluZykpKQorICAgKGxlbmd0aCBz dHJpbmcpCisgICBmaWx0ZXIpKQogCiAoZGVmdW4gY29tcGxldGlvbi1lbWFjczIyLXRyeS1j b21wbGV0aW9uIChzdHJpbmcgdGFibGUgcHJlZCBwb2ludCkKICAgKGxldCAoKHN1ZmZpeCAo c3Vic3RyaW5nIHN0cmluZyBwb2ludCkpCkBAIC0zMzI3LDEzICszMzI0LDE0IEBAIGNvbXBs ZXRpb24tZW1hY3MyMi10cnktY29tcGxldGlvbgogICAgICAgICAgIChzZXRxIHN1ZmZpeCAo c3Vic3RyaW5nIHN1ZmZpeCAxKSkpCiAgICAgICAoY29ucyAoY29uY2F0IGNvbXBsZXRpb24g c3VmZml4KSAobGVuZ3RoIGNvbXBsZXRpb24pKSkpKQogCi0oZGVmdW4gY29tcGxldGlvbi1l bWFjczIyLWFsbC1jb21wbGV0aW9ucyAoc3RyaW5nIHRhYmxlIHByZWQgcG9pbnQpCisoZGVm dW4gY29tcGxldGlvbi1lbWFjczIyLWFsbC1jb21wbGV0aW9ucyAoc3RyaW5nIHRhYmxlIHBy ZWQgcG9pbnQKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgJm9wdGlvbmFsIGZpbHRlcikKICAgKGxldCogKChiZWZvcmVwb2ludCAoc3Vic3Ry aW5nIHN0cmluZyAwIHBvaW50KSkKICAgICAgICAgIChhZnRlcnBvaW50IChzdWJzdHJpbmcg c3RyaW5nIHBvaW50KSkKICAgICAgICAgIChib3VuZHMgKGNvbXBsZXRpb24tYm91bmRhcmll cyBiZWZvcmVwb2ludCB0YWJsZSBwcmVkIGFmdGVycG9pbnQpKSkKICAgICAoY29tcGxldGlv bi0tZGVmZXJyZWQtaGlsaXQKICAgICAgKGFsbC1jb21wbGV0aW9ucyBiZWZvcmVwb2ludCB0 YWJsZSBwcmVkKQotICAgICBwb2ludCAoY2FyIGJvdW5kcykgKCsgcG9pbnQgKGNkciBib3Vu ZHMpKSkpKQorICAgICBwb2ludCAoY2FyIGJvdW5kcykgKCsgcG9pbnQgKGNkciBib3VuZHMp KSBmaWx0ZXIpKSkKIAogOzs7IEJhc2ljIGNvbXBsZXRpb24uCiAKQEAgLTMzODEsNyArMzM3 OSw4IEBAIGNvbXBsZXRpb24tYmFzaWMtdHJ5LWNvbXBsZXRpb24KICAgICAgICAgICAgIChz ZXRxIGFsbCAoY29tcGxldGlvbi1wY20tLWZpbGVuYW1lLXRyeS1maWx0ZXIgYWxsKSkpCiAg ICAgICAgIChjb21wbGV0aW9uLXBjbS0tbWVyZ2UtdHJ5IHBhdHRlcm4gYWxsIHByZWZpeCBz dWZmaXgpKSkpKQogCi0oZGVmdW4gY29tcGxldGlvbi1iYXNpYy1hbGwtY29tcGxldGlvbnMg KHN0cmluZyB0YWJsZSBwcmVkIHBvaW50KQorKGRlZnVuIGNvbXBsZXRpb24tYmFzaWMtYWxs LWNvbXBsZXRpb25zIChzdHJpbmcgdGFibGUgcHJlZCBwb2ludAorICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJm9wdGlvbmFsIGZpbHRlcikKICAg KGxldCogKChiZWZvcmVwb2ludCAoc3Vic3RyaW5nIHN0cmluZyAwIHBvaW50KSkKICAgICAg ICAgIChhZnRlcnBvaW50IChzdWJzdHJpbmcgc3RyaW5nIHBvaW50KSkKICAgICAgICAgIChi b3VuZHMgKGNvbXBsZXRpb24tYm91bmRhcmllcyBiZWZvcmVwb2ludCB0YWJsZSBwcmVkIGFm dGVycG9pbnQpKQpAQCAtMzM5Miw3ICszMzkxLDkgQEAgY29tcGxldGlvbi1iYXNpYy1hbGwt Y29tcGxldGlvbnMKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAncG9pbnQKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAoc3Vic3RyaW5nIGFmdGVycG9pbnQgMCAoY2RyIGJv dW5kcykpKSkpCiAgICAgICAgICAoYWxsIChjb21wbGV0aW9uLXBjbS0tYWxsLWNvbXBsZXRp b25zIHByZWZpeCBwYXR0ZXJuIHRhYmxlIHByZWQpKSkKLSAgICAoY29tcGxldGlvbi0tZGVm ZXJyZWQtaGlsaXQgYWxsIHBvaW50IChjYXIgYm91bmRzKSAoKyBwb2ludCAoY2RyIGJvdW5k cykpKSkpCisgICAgKGNvbXBsZXRpb24tLWRlZmVycmVkLWhpbGl0IGFsbCBwb2ludAorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoY2FyIGJvdW5kcykgKCsgcG9pbnQgKGNk ciBib3VuZHMpKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmaWx0ZXIpKSkK IAogOzs7IFBhcnRpYWwtY29tcGxldGlvbi1tb2RlIHN0eWxlIGNvbXBsZXRpb24uCiAKQEAg LTM1ODQsMTEgKzM1ODUsMTEgQEAgZmxleC1zY29yZS1tYXRjaC10aWdodG5lc3MKIHRoYW4g dGhlIGxhdHRlciAod2hpY2ggaGFzIHR3byBcImhvbGVzXCIgYW5kIHRocmVlCiBvbmUtbGV0 dGVyLWxvbmcgbWF0Y2hlcykuIikKIAotKGRlZnVuIGNvbXBsZXRpb24tcGNtLS1kZWZlcnJl ZC1oaWxpdCAocGF0dGVybiBjb21wbGV0aW9ucyBiYXNlIGVuZCkKKyhkZWZ1biBjb21wbGV0 aW9uLXBjbS0tZGVmZXJyZWQtaGlsaXQgKHBhdHRlcm4gY29tcGxldGlvbnMgYmFzZSBlbmQg ZmlsdGVyKQogICAiUmV0dXJuIGNvbXBsZXRpb25zIGluIG9sZCBmb3JtYXQgb3IgbmV3IGFs aXN0IGZvcm1hdC4KLUlmIGBjb21wbGV0aW9uLS1maWx0ZXItY29tcGxldGlvbnMnIGlzIG5v bi1uaWwgdXNlIHRoZSBuZXcgZm9ybWF0LiIKK0lmIEZJTFRFUiBpcyBub24tbmlsIHVzZSB0 aGUgbmV3IGZvcm1hdC4iCiAgICh3aGVuIGNvbXBsZXRpb25zCi0gICAgKGlmIGNvbXBsZXRp b24tLWZpbHRlci1jb21wbGV0aW9ucworICAgIChpZiBmaWx0ZXIKICAgICAgICAgYCgoYmFz ZSAuICxiYXNlKQogICAgICAgICAgIChlbmQgLiAsZW5kKQogICAgICAgICAgIChoaWdobGln aHQgLiAsKGFwcGx5LXBhcnRpYWxseQpAQCAtMzgzOSwxMiArMzg0MCwxNCBAQCBjb21wbGV0 aW9uLXBjbS0tZmluZC1hbGwtY29tcGxldGlvbnMKICAgICAgICAgICAoc2lnbmFsIChjYXIg Zmlyc3RlcnJvcikgKGNkciBmaXJzdGVycm9yKSkKICAgICAgICAgKGxpc3QgcGF0dGVybiBh bGwgcHJlZml4IHN1ZmZpeCkpKSkpCiAKLShkZWZ1biBjb21wbGV0aW9uLXBjbS1hbGwtY29t cGxldGlvbnMgKHN0cmluZyB0YWJsZSBwcmVkIHBvaW50KQorKGRlZnVuIGNvbXBsZXRpb24t cGNtLWFsbC1jb21wbGV0aW9ucyAoc3RyaW5nIHRhYmxlIHByZWQgcG9pbnQKKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmb3B0aW9uYWwgZmlsdGVy KQogICAocGNhc2UtbGV0ICgoYCgscGF0dGVybiAsYWxsICxwcmVmaXggLHN1ZmZpeCkKICAg ICAgICAgICAgICAgIChjb21wbGV0aW9uLXBjbS0tZmluZC1hbGwtY29tcGxldGlvbnMgc3Ry aW5nIHRhYmxlIHByZWQgcG9pbnQpKSkKICAgICAoY29tcGxldGlvbi1wY20tLWRlZmVycmVk LWhpbGl0IHBhdHRlcm4gYWxsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAobGVuZ3RoIHByZWZpeCkKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICgtIChsZW5ndGggc3RyaW5nKSAobGVuZ3RoIHN1ZmZpeCkpKSkpCisgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAoLSAobGVuZ3RoIHN0cmluZykgKGxlbmd0aCBzdWZm aXgpKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZmlsdGVyKSkpCiAK IChkZWZ1biBjb21wbGV0aW9uLS1jb21tb24tc3VmZml4IChzdHJzKQogICAiUmV0dXJuIHRo ZSBjb21tb24gc3VmZml4IG9mIHRoZSBzdHJpbmdzIFNUUlMuIgpAQCAtNDA2NywxMyArNDA3 MCwxNSBAQCBjb21wbGV0aW9uLXN1YnN0cmluZy10cnktY29tcGxldGlvbgogICAgICAgICAo c2V0cSBhbGwgKGNvbXBsZXRpb24tcGNtLS1maWxlbmFtZS10cnktZmlsdGVyIGFsbCkpKQog ICAgIChjb21wbGV0aW9uLXBjbS0tbWVyZ2UtdHJ5IHBhdHRlcm4gYWxsIHByZWZpeCBzdWZm aXgpKSkKIAotKGRlZnVuIGNvbXBsZXRpb24tc3Vic3RyaW5nLWFsbC1jb21wbGV0aW9ucyAo c3RyaW5nIHRhYmxlIHByZWQgcG9pbnQpCisoZGVmdW4gY29tcGxldGlvbi1zdWJzdHJpbmct YWxsLWNvbXBsZXRpb25zIChzdHJpbmcgdGFibGUgcHJlZCBwb2ludAorICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZvcHRpb25hbCBmaWx0 ZXIpCiAgIChwY2FzZS1sZXQgKChgKCxhbGwgLHBhdHRlcm4gLHByZWZpeCAsc3VmZml4KQog ICAgICAgICAgICAgICAgKGNvbXBsZXRpb24tc3Vic3RyaW5nLS1hbGwtY29tcGxldGlvbnMK ICAgICAgICAgICAgICAgICBzdHJpbmcgdGFibGUgcHJlZCBwb2ludCkpKQogICAgIChjb21w bGV0aW9uLXBjbS0tZGVmZXJyZWQtaGlsaXQgcGF0dGVybiBhbGwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIChsZW5ndGggcHJlZml4KQotICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKC0gKGxlbmd0aCBzdHJpbmcpIChsZW5ndGggc3VmZml4 KSkpKSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICgtIChsZW5ndGgg c3RyaW5nKSAobGVuZ3RoIHN1ZmZpeCkpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBmaWx0ZXIpKSkKIAogOzs7ICJmbGV4IiBjb21wbGV0aW9uLCBhbHNvIGtub3du IGFzIGZseC9mdXp6eS9zY2F0dGVyIGNvbXBsZXRpb24KIDs7IENvbXBsZXRlcyAiZm9vIiB0 byAiZnJvZG8iIGFuZCAiZmFyZnJvbXNvYmVyIgpAQCAtNDE1Miw3ICs0MTU3LDggQEAgY29t cGxldGlvbi1mbGV4LXRyeS1jb21wbGV0aW9uCiAgICAgICA7OyAiZmFyZnJvbXNvYmVyIi4K ICAgICAgIChjb21wbGV0aW9uLXBjbS0tbWVyZ2UtdHJ5IHBhdHRlcm4gYWxsIHByZWZpeCBz dWZmaXgpKSkpCiAKLShkZWZ1biBjb21wbGV0aW9uLWZsZXgtYWxsLWNvbXBsZXRpb25zIChz dHJpbmcgdGFibGUgcHJlZCBwb2ludCkKKyhkZWZ1biBjb21wbGV0aW9uLWZsZXgtYWxsLWNv bXBsZXRpb25zIChzdHJpbmcgdGFibGUgcHJlZCBwb2ludAorICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmb3B0aW9uYWwgZmlsdGVyKQogICAiR2V0 IGZsZXgtY29tcGxldGlvbnMgb2YgU1RSSU5HIGluIFRBQkxFLCBnaXZlbiBQUkVEIGFuZCBQ T0lOVC4iCiAgICh1bmxlc3MgKGFuZCBjb21wbGV0aW9uLWZsZXgtbm9zcGFjZSAoc3RyaW5n LXNlYXJjaCAiICIgc3RyaW5nKSkKICAgICAocGNhc2UtbGV0ICgoYCgsYWxsICxwYXR0ZXJu ICxwcmVmaXggLHN1ZmZpeCkKQEAgLTQxNjEsNyArNDE2Nyw4IEBAIGNvbXBsZXRpb24tZmxl eC1hbGwtY29tcGxldGlvbnMKICAgICAgICAgICAgICAgICAgICMnY29tcGxldGlvbi1mbGV4 LS1tYWtlLWZsZXgtcGF0dGVybikpKQogICAgICAgKGNvbXBsZXRpb24tcGNtLS1kZWZlcnJl ZC1oaWxpdCBwYXR0ZXJuIGFsbAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKGxlbmd0aCBwcmVmaXgpCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAoLSAobGVuZ3RoIHN0cmluZykgKGxlbmd0aCBzdWZmaXgpKSkpKSkKKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICgtIChsZW5ndGggc3RyaW5nKSAobGVuZ3RoIHN1 ZmZpeCkpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmaWx0ZXIpKSkp CiAKIDs7IEluaXRpYWxzIGNvbXBsZXRpb24KIDs7IENvbXBsZXRlIC91bXMgdG8gL3Vzci9t b25uaWVyL3NyYyBvciBsY2ggdG8gbGlzdC1jb21tYW5kLWhpc3RvcnkuCkBAIC00MTk1LDE0 ICs0MjAyLDE2IEBAIGNvbXBsZXRpb24taW5pdGlhbHMtZXhwYW5kCiAgICAgICAgICAgICAo Y29uY2F0IChzdWJzdHJpbmcgc3RyIDAgKGNhciBib3VuZHMpKQogICAgICAgICAgICAgICAg ICAgICAobWFwY29uY2F0ICdzdHJpbmcgKHN1YnN0cmluZyBzdHIgKGNhciBib3VuZHMpKSBz ZXApKSkpKSkpKQogCi0oZGVmdW4gY29tcGxldGlvbi1pbml0aWFscy1hbGwtY29tcGxldGlv bnMgKHN0cmluZyB0YWJsZSBwcmVkIF9wb2ludCkKKyhkZWZ1biBjb21wbGV0aW9uLWluaXRp YWxzLWFsbC1jb21wbGV0aW9ucyAoc3RyaW5nIHRhYmxlIHByZWQgX3BvaW50CisgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmb3B0aW9uYWwg ZmlsdGVyKQogICAobGV0ICgobmV3c3RyIChjb21wbGV0aW9uLWluaXRpYWxzLWV4cGFuZCBz dHJpbmcgdGFibGUgcHJlZCkpKQogICAgICh3aGVuIG5ld3N0cgogICAgICAgKHBjYXNlLWxl dCAoKGAoLHBhdHRlcm4gLGFsbCAscHJlZml4ICxfc3VmZml4KQogICAgICAgICAgICAgICAg ICAgIChjb21wbGV0aW9uLXBjbS0tZmluZC1hbGwtY29tcGxldGlvbnMgbmV3c3RyIHRhYmxl CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBwcmVkIChsZW5ndGggbmV3c3RyKSkpKQogICAgICAgICAoY29tcGxldGlvbi1wY20t LWRlZmVycmVkLWhpbGl0IHBhdHRlcm4gYWxsCi0gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKGxlbmd0aCBwcmVmaXgpIChsZW5ndGggc3RyaW5nKSkpKSkpCisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGxlbmd0aCBwcmVmaXgp IChsZW5ndGggc3RyaW5nKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGZpbHRlcikpKSkpCiAKIChkZWZ1biBjb21wbGV0aW9uLWluaXRpYWxzLXRyeS1jb21w bGV0aW9uIChzdHJpbmcgdGFibGUgcHJlZCBfcG9pbnQpCiAgIChsZXQgKChuZXdzdHIgKGNv bXBsZXRpb24taW5pdGlhbHMtZXhwYW5kIHN0cmluZyB0YWJsZSBwcmVkKSkpCi0tIAoyLjIw LjEKCg== --------------4B3E2A198290BEF506AC64C4--
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 12 Aug 2021 08:47:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 12 04:47:28 2021 Received: from localhost ([127.0.0.1]:37522 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mE6N6-0000Oh-CB for submit <at> debbugs.gnu.org; Thu, 12 Aug 2021 04:47:28 -0400 Received: from server.qxqx.de ([178.63.65.180]:51005 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1mE6N5-0000OR-Aa; Thu, 12 Aug 2021 04:47:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=i2BeI1W5p4ITvwSsYZbpZMP46bquNh7WtZnDbLxnDTs=; b=CkXnzKP04T4dpOSSH2ZJ+E38aD YyMJjNahZq7mYM0sODxvUmJLg0HxHEwRzrUnlWF+2rHz9e1q7O4WlG8pPrsbBCyJ/2rOY5IXaMZy5 AtgefXe2+civGL9/WP4+huRNqrnjQtnWrWEvRL+u+OnHMqHcrVrd8SGqA5EUYts6Zv/8=; Subject: Re: bug#48841: [PATCH] Add new `completion-filter-completions` API and deferred highlighting To: Eli Zaretskii <eliz@HIDDEN> References: <f94541d3-5f93-9a23-8256-3bbc453f127a@HIDDEN> <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <837dgrdrec.fsf@HIDDEN> From: Daniel Mendler <mail@HIDDEN> Message-ID: <aff2bd3a-ea3e-1ac6-cf0d-2785c6591c84@HIDDEN> Date: Thu, 12 Aug 2021 10:47:17 +0200 MIME-Version: 1.0 In-Reply-To: <837dgrdrec.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: 47711 <at> debbugs.gnu.org, monnier@HIDDEN, joaotavora@HIDDEN, 48841 <at> debbugs.gnu.org, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli, thank you for your feedback and for pointing me to the mode which helps with the formatting. I will address the documentation and formatting issues as soon as the discussion has concluded. In the following I answer to a few of your questions about technical details. >> The `completions` value is the list of completion strings *without* >> applied highlighting. The completion strings are returned unmodified, >> which avoids allocations and results in performance gains for > > This is unclear: how can you return a list of strings which you > produce without allocating the strings? The function 'completion-filter-completions' receives a completion table as argument. The strings produced by this table are returned unmodified, but of course the completion table has to produce them. For a static completion table (e.g., in the simplest case a list of strings) the completion table itself will not allocate strings. In this scenario 'completion-filter-completions' will not perform any string allocations, only the list will be allocated. This is what leads to major performance gains. >> +(defvar completion--filter-completions nil >> + "Enable the new completions return value format. > > Btw, why is this an internal variable? Shouldn't all completion > styles ideally support it? If so, it should be a public variable, > documented in the ELisp manual. And the name should also end with -p, > since it's a boolean. How about completion-filter-completions-format-p? (As I understood the style guide '-p' is not a good idea for boolean variables, since a value is not a predicate in a strict sense.) To address your technical comment - this variable is precisely what one of the technical difficulties mentioned in my other mail is about. The question is how we can retain backward compatibility of the completion style 'all' functions, e.g., 'completion-basic-all-completions', while still allowing the function to return the newly introduced alist format with more data, which enables 'completion-filter-completions' to perform the efficient deferred highlighting. > Also, the "This function has been superseded..." part should be a new > paragraph, so that it stands out. (And I'm not yet sure we indeed > want to say "superseded" here, but that's part of the on-going > discussion. maybe use a more neutral language here, like "See also".) The new API 'completion-filter-completions' will substitute the existing API 'completion-all-completions'. I only didn't go as far as deprecating the 'completion-all-completions' API right away, but we could also do this. > Is "filter" really the right word here (in the doc string)? "Filer" > means you take a sequence and produce another sequence with some > members removed. That's not what this API does, is it? Suggest to > use a different name, like completion-completions-alist or > completion-all-completions-as-alist. "Filter" seems like exactly the right word to me. The function takes a list of strings (or a completion table) and returns a subset of matching completion strings without further modifications to the strings. See above what I wrote about allocations. >> +Only the elements of table that satisfy predicate PRED are considered. >> +POINT is the position of point within STRING. The METADATA may be >> +modified by the completion style. The return value is a alist with >> +the keys: >> + >> +- base: Base position of the completion (from the start of STRING) > > "Base" here means the beginning? If so, why not call it "beg" or > somesuch? Base position is a fixed term which is already used in minibuffer.el for completions. See also 'completion-base-position' for example. > Are we really losing the completion-score property here? If so, why? Yes, the property is removed in the current patch. It is not actually used for anything in the new implementation. But it is possible to restore the property such that 'completion-all-completions' always returns scored candidates as it does now. See my other mail regarding the caveats of the current patch. Daniel
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 12 Aug 2021 08:00:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 12 04:00:40 2021
Received: from localhost ([127.0.0.1]:37404 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1mE5do-0007UR-3t
for submit <at> debbugs.gnu.org; Thu, 12 Aug 2021 04:00:40 -0400
Received: from eggs.gnu.org ([209.51.188.92]:46316)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>)
id 1mE5dl-0007U9-G8; Thu, 12 Aug 2021 04:00:38 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:58862)
by eggs.gnu.org with esmtp (Exim 4.90_1)
(envelope-from <eliz@HIDDEN>)
id 1mE5dd-0002GC-RB; Thu, 12 Aug 2021 04:00:29 -0400
Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3162
helo=home-c4e4a596f7)
by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1mE5dd-0008LK-Eb; Thu, 12 Aug 2021 04:00:29 -0400
Date: Thu, 12 Aug 2021 11:00:11 +0300
Message-Id: <837dgrdrec.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Daniel Mendler <mail@HIDDEN>
In-Reply-To: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> (message
from Daniel Mendler on Wed, 11 Aug 2021 16:16:57 +0200)
Subject: Re: bug#48841: [PATCH] Add new `completion-filter-completions` API and
deferred highlighting
References: <f94541d3-5f93-9a23-8256-3bbc453f127a@HIDDEN>
<aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47711
Cc: 47711 <at> debbugs.gnu.org, monnier@HIDDEN, joaotavora@HIDDEN,
48841 <at> debbugs.gnu.org, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
[I removed emacs-devel from the CC list, please don't cross-post to
both emacs-devel and the bug tracker.]
> From: Daniel Mendler <mail@HIDDEN>
> Date: Wed, 11 Aug 2021 16:16:57 +0200
> Cc: 48841 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>,
> João Távora <joaotavora@HIDDEN>,
> Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org
>
> I prepared a patch which provides the API
> `completion-filter-completions`. This function supports deferred
> highlighting and returns additional data with the list of matching
> completion candidates. The API supersedes the existing function
> `completion-all-completions`.
Thanks. The discussion of this is still going on, and I don't
consider myself an expert in this area of Emacs, so below please find
only comments for minor formatting and documentation aspects.
> Add a new `completion-filter-completions` API, which supersedes
> `completion-all-completions`. The new API returns the matching
> completion candidates and additional data. The return value is an
> alist, with the keys `completions`, `base`, `end` and `highlight`.
> The API can be extended in a backward compatible way later on thanks
> to the use of an alist as return value.
Please don't use Markdown-style quoting `like this` in our comments
and log messages. We quote 'like this' in these places.
> The `completions` value is the list of completion strings *without*
> applied highlighting. The completion strings are returned unmodified,
> which avoids allocations and results in performance gains for
This is unclear: how can you return a list of strings which you
produce without allocating the strings?
> The value `base` is the base position of the completion.
"Base position" where, or relative to what object?
> Correspondingly the value `end` specifies the end position of the
> completion counted from the beginning of the input strng.
So the base position is also relative to the beginning of the input
string? If so, please say so explicitly.
> Finally the
> `highlight` value is a function taking a list of completion strings
> and returns a new list of new strings with highlighting applied.
If you say "taking a list...", then for consistent style please also
say "...and returning a new list...".
> A continously updating UI can use the highlighting function to apply
> highlighting only to the visible completions.
Not, "visible", but "displayed", right? So I'd rephrase
...to apply highlighting only to the completions that are actually
displayed.
> (completion-basic-all-completions,
> completion-emacs21-all-completions,
> completion-emacs22-all-completions): Use it.
That's incorrect format, I guess you did it by hand rather than
letting change-log-mode do it for you? The correct format looks like
this:
(completion-basic-all-completions)
(completion-emacs21-all-completions)
(completion-emacs22-all-completions): use it.
IOW, each line ends with a closing parentheses, not a comma.
> +(defvar completion--filter-completions nil
> + "Enable the new completions return value format.
Using genitive construction should be limited to just 2 words. Here
you have 4, which produces an awkward, hard to interpret phrase.
Suggest to reword:
If non-nil, return completions in `completion-filter-completions' format.
Note that I also dropped the "new" part (which generally doesn't stand
the test of time), and instead gave a hint as to what that format is.
Btw, why is this an internal variable? Shouldn't all completion
styles ideally support it? If so, it should be a public variable,
documented in the ELisp manual. And the name should also end with -p,
since it's a boolean. How about completion-filter-completions-format-p?
> + New completion style functions may always return their
> +results in the new alist format, since `completion-all-completions'
> +transparently converts back to the old improper list of completions
> +with base size in the last cdr.")
"may" and "always" are a kind of contradiction.
Also, I'd drop the "improper" part, as it sounds like a derogatory
adjective.
> (defun completion-try-completion (string table pred point &optional metadata)
> "Try to complete STRING using completion table TABLE.
> Only the elements of table that satisfy predicate PRED are considered.
> -POINT is the position of point within STRING.
> -The return value can be either nil to indicate that there is no completion,
> -t to indicate that STRING is the only possible completion,
> -or a pair (NEWSTRING . NEWPOINT) of the completed result string together with
> -a new position for point."
> +POINT is the position of point within STRING. The return value can be
> +either nil to indicate that there is no completion, t to indicate that
> +STRING is the only possible completion, or a pair (NEWSTRING . NEWPOINT)
> +of the completed result string together with a new position for point.
> +The METADATA may be modified by the completion style."
Here you changed whitespace by filling, and that ruined the
intentionally formatted doc string, which made it easy to find the
various forms of the return value and the important parts of the doc
string. Please keep the original formatting.
> (defun completion-all-completions (string table pred point &optional metadata)
> "List the possible completions of STRING in completion table TABLE.
> Only the elements of table that satisfy predicate PRED are considered.
> -POINT is the position of point within STRING.
> -The return value is a list of completions and may contain the base-size
> -in the last `cdr'."
> - ;; FIXME: We need to additionally return the info needed for the
> - ;; second part of completion-base-position.
> - (completion--nth-completion 2 string table pred point metadata))
> +POINT is the position of point within STRING. The return value is a
> +list of completions and may contain the base-size in the last `cdr'.
> +The METADATA may be modified by the completion style. This function
> +has been superseded by `completion-filter-completions', which returns
> +richer information and supports deferred candidate highlighting."
Likewise here.
Also, the "This function has been superseded..." part should be a new
paragraph, so that it stands out. (And I'm not yet sure we indeed
want to say "superseded" here, but that's part of the on-going
discussion. maybe use a more neutral language here, like "See also".)
> + (if (and result (consp (car result)))
> + ;; Give the completion styles some freedom!
> + ;; If they are targeting Emacs 28 upwards only, they
> + ;; may always return a result with deferred
> + ;; highlighting. We convert back to the old format
> + ;; here by applying the highlighting eagerly.
"May always" again. How about "can always" instead?
> + (nconc (funcall (cdr (assq 'highlight result))
> + (cdr (assq 'completions result)))
> + (cdr (assq 'base result)))
> + result)))
> +
> +(defun completion-filter-completions (string table pred point metadata)
> + "Filter the possible completions of STRING in completion table TABLE.
Is "filter" really the right word here (in the doc string)? "Filer"
means you take a sequence and produce another sequence with some
members removed. That's not what this API does, is it? Suggest to
use a different name, like completion-completions-alist or
completion-all-completions-as-alist.
> +Only the elements of table that satisfy predicate PRED are considered.
> +POINT is the position of point within STRING. The METADATA may be
> +modified by the completion style. The return value is a alist with
> +the keys:
> +
> +- base: Base position of the completion (from the start of STRING)
"Base" here means the beginning? If so, why not call it "beg" or
somesuch?
> +This function supersedes the function `completion-all-completions'."
Again, "supersedes" is too strong, IMO. I would say "is a variant of"
instead, and explain why this variant could be better suited to some
use cases. IOW, explain the upsides (and downsides, if any), and let
the programmers decide whether they want this, instead of more-or-less
forcing them to use it.
> + ;; Deferred highlighting has been requested, but the completion
> + ;; style returned a non-deferred result. Convert the result to the
^^
two spaces between sentences, please.
> + ;; new alist format.
"New" is not a good word here.
> + ;; added by the completion machinery.
Please start comments with a capital letter.
> +(defun completion--deferred-hilit (completions prefix-len base end)
> + "Return completions in old format or new alist format.
> +If `completion--filter-completions' is non-nil use the new format."
Again, please don't use "old" and "new" here, but instead describe
explicitly the differences between them, or provide a hyperlink to
where that is described.
> + ;; Apply highlighting
Please end each sentence in a comment with a period.
> +(defun completion-pcm--deferred-hilit (pattern completions base end)
> + "Return completions in old format or new alist format.
> +If `completion--filter-completions' is non-nil use the new format."
"Old" and "new" again.
> (defun completion-pcm--hilit-commonality (pattern completions)
> "Show where and how well PATTERN matches COMPLETIONS.
> PATTERN, a list of symbols and strings as seen
> `completion-pcm--merge-completions', is assumed to match every
> string in COMPLETIONS. Return a deep copy of COMPLETIONS where
> -each string is propertized with `completion-score', a number
> -between 0 and 1, and with faces `completions-common-part',
> +each string is propertized with faces `completions-common-part',
> `completions-first-difference' in the relevant segments."
Are we really losing the completion-score property here? If so, why?
> + ;; If `pattern' doesn't have an explicit trailing any,
This is confusing: what do you mean by "explicit trailing any" in the
context of patterns?
> +(defun completion--flex-score (pattern completions)
> + "Compute how well PATTERN matches COMPLETIONS.
> +PATTERN, a list of strings is assumed to match every string in
> +COMPLETIONS.
Is PATTERN really a list? It would be strange for a list to be called
PATTERN, and how can a list "match every string in COMPLETIONS"?
> Return a copy of COMPLETIONS where each element is
> +a pair of a score and the completion string.
What is "the completion string" in this case? is it the same string
from COMPLETIONS, or is it something else? The doc string leaves that
unclear.
> The score lies in
> +the range between -1 and 0, where -1 corresponds to the full
> +match."
What score could a partial match have, and what is the meaning of the
numerical value for a partial match?
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 11 Aug 2021 16:17:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 11 12:17:28 2021 Received: from localhost ([127.0.0.1]:36392 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mDqv1-0005ei-S7 for submit <at> debbugs.gnu.org; Wed, 11 Aug 2021 12:17:28 -0400 Received: from mail-pj1-f52.google.com ([209.85.216.52]:42550) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1mDquz-0005ZI-D2; Wed, 11 Aug 2021 12:17:26 -0400 Received: by mail-pj1-f52.google.com with SMTP id mq2-20020a17090b3802b0290178911d298bso5839129pjb.1; Wed, 11 Aug 2021 09:17:25 -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=jA8E40VtlAuX0iMEkWlyJ13M+vYAfR9CULGNzYrMWuw=; b=nqcIq4vOrpqIwPVP+7LOt4OpWbiWWrogS1eHgcHDa+vtPH3Ha0L1qzKb8X4HN7V5s9 YZ0gwitcOOhmL8STj5M8Z+dbTpuziDlwrWH6eWNnp75JcAKnCAD+/Vh2y+yBNgzr3a10 YhROHr/KYUsOIcV/5Auj+FMbg2InwANm0FFPpUXlOktGbLo1376Vm2WL8kBg6PLjoUgX 3HEkWQg3QGPpF0tkSrmYTnchgUFZKmkaZOEXuJE/+qDE0cpoVjOaE2bzNLGJiX+iMQac lZNhoyzC7vgfvHed3pwZIAxGNM+hp5J29mlwnpKLsgpdGXVgOm2HtDlQonDhXSLUMuKs FduQ== 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=jA8E40VtlAuX0iMEkWlyJ13M+vYAfR9CULGNzYrMWuw=; b=SOA8e6x4uRSrmAteCOOcUkm3Wc//TKG1aUAO0VpyNZo23J9oLGpXKmrO4CwiWzawqq oMzOmbDbZwvpxK2fht4BSlDfbVlMVT5A4ResIlgi9MokNykxQJ83ObqmYUSrUayD9B/1 QdNn1r9/JhDMqAJAxod8u10v4bpt4OUDSLg/pm6c8eM+2Ogj4psMkTdfGlAyzHABjrFx dhg1Dt0hGftCHeyZ5qtbYX1RWkZwGaQnBeboDpBmkG5kwEHn7jeUFpkH0VDD7wqtypWk tk1mkGfjpL16Yu398Z8Oi6jf0W/p87EmReZnuO1tJaflpo/nnWtaAHAXDM3p3gIhxXyj 3bIg== X-Gm-Message-State: AOAM533lMhyMxqZtgJ6+NSfSSwwNOHnH5JlHjTOqTWHT4jh7pBDSCOAJ urUK93eFKxO3eU+2okNK5X1/EUPTFArte+8c/rw= X-Google-Smtp-Source: ABdhPJyP0fKKy0TCf0MVCKV4sAlwqv6ZxwwQMS5d//O3nf4QoGUYY3eWz0YesAADm/rqyracNgAd497dBs1yi5ai1Rg= X-Received: by 2002:aa7:9050:0:b029:3af:7e99:f48f with SMTP id n16-20020aa790500000b02903af7e99f48fmr29318366pfo.2.1628698639473; Wed, 11 Aug 2021 09:17:19 -0700 (PDT) MIME-Version: 1.0 References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> In-Reply-To: <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Wed, 11 Aug 2021 17:17:07 +0100 Message-ID: <CALDnm52AFkHT7UwncetuK6mzzz0wD2QxAM-zNBG0qLfYQ284Ng@HIDDEN> Subject: Re: [PATCH] Add new `completion-filter-completions` API and deferred highlighting To: Daniel Mendler <mail@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 47711 Cc: 47711 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, "emacs-devel@HIDDEN" <emacs-devel@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Perhaps you should first provide a patch with these 2 "little effort" chang= es, (that are presumably also backward compatible and don't affect the API) by themselves. Reading about these complex ideas isn't as clear as seeing them in actual code. Then it'll be easier to evaluate the merits of the patch you proposed in your first email. Jo=C3=A3o On Wed, Aug 11, 2021 at 5:11 PM Daniel Mendler <mail@HIDDEN> wro= te: > > On 8/11/21 4:16 PM, Daniel Mendler wrote: > > I prepared a patch which provides the API > > `completion-filter-completions`. This function supports deferred > > highlighting and returns additional data with the list of matching > > completion candidates. The API supersedes the existing function > > `completion-all-completions`. > > > > The main goal of the new API is to avoid expensive string allocations > > and highlighting during completion. This is particularly relevant for > > continuously updating completion UIs like Icomplete or Vertico. > > Furthermore the end position of the completion boundaries is returned > > with the completion results. This information is not provided by the > > existing `completion-all-completions` API. > > > > See also the relevant bugs bug#47711 and bug#48841. I am looking forwar= d > > to your feedback. Thank you! > > There are currently two issues with the patch with regards to backward > compatibility. Fortunately they are fixable with a little effort. > > 1. I would like to deprecate `completion-score' or remove it altogether, > but unfortunately `completion-score' is used in the wild. In order to > preserve `completion-score', bind `completion--filter-completions' in > the highlighting functions. Add `completion-score' in > `completion-pcm--hilit-commonality' when > `completion--filter-completions' is nil. > > 2. In `completion--nth-completion' set `completion--filter-completions' > to nil, unless `(memq style '(emacs21 emacs22 basic > partial-completion initials flex))' such that custom completion > styles which wrap the completion functions don't see the new return > value format, except if the custom style opts in explicitly by > binding `completion--filter-completions'. An alternative criterion is > `(memq fun '(completion-emacs22-all-completions) ...)'. Unfortunately > this approach will still not work if the user has advised a > `completion-x-all-completions' function. The only 100% safe approach > seems to transparently redirect calls to > `completion-x-all-completions' to `completion--x-filter-completions', > which returns the results in the new format. > > With these changes the patch should be 100% backward compatible. > > Daniel --=20 Jo=C3=A3o T=C3=A1vora
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 11 Aug 2021 16:11:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 11 12:11:31 2021 Received: from localhost ([127.0.0.1]:36386 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1mDqpH-0003Uv-46 for submit <at> debbugs.gnu.org; Wed, 11 Aug 2021 12:11:31 -0400 Received: from server.qxqx.de ([178.63.65.180]:60351 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1mDqpF-0003UZ-3i; Wed, 11 Aug 2021 12:11:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:References:Cc:To:From:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=L9YD2Rbs2yUeev3cPOFCPRt64IqdN05dDBBAfML4R0Y=; b=PYVBp5sBBCAoJ4YvgPqbbwiiXL IuVLkgk+39f09D7qa9siQeSn5VpG+WNb4+9wvgzxTMubp8aXRfRL9GfhgFqd7ORoZhAwiv0T5G5KC i2ckBeXWHmESGnVZ3uZ7cQ/fP1vXU8fQja7S3gO1j634WEiBrgFDUNflZQz1n2BV8CGc=; Subject: Re: [PATCH] Add new `completion-filter-completions` API and deferred highlighting From: Daniel Mendler <mail@HIDDEN> To: "emacs-devel@HIDDEN" <emacs-devel@HIDDEN> References: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> Message-ID: <f8c4419a-7e83-b8a9-347c-0221a2052376@HIDDEN> Date: Wed, 11 Aug 2021 18:11:21 +0200 MIME-Version: 1.0 In-Reply-To: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: 48841 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) On 8/11/21 4:16 PM, Daniel Mendler wrote: > I prepared a patch which provides the API > `completion-filter-completions`. This function supports deferred > highlighting and returns additional data with the list of matching > completion candidates. The API supersedes the existing function > `completion-all-completions`. > > The main goal of the new API is to avoid expensive string allocations > and highlighting during completion. This is particularly relevant for > continuously updating completion UIs like Icomplete or Vertico. > Furthermore the end position of the completion boundaries is returned > with the completion results. This information is not provided by the > existing `completion-all-completions` API. > > See also the relevant bugs bug#47711 and bug#48841. I am looking forward > to your feedback. Thank you! There are currently two issues with the patch with regards to backward compatibility. Fortunately they are fixable with a little effort. 1. I would like to deprecate `completion-score' or remove it altogether, but unfortunately `completion-score' is used in the wild. In order to preserve `completion-score', bind `completion--filter-completions' in the highlighting functions. Add `completion-score' in `completion-pcm--hilit-commonality' when `completion--filter-completions' is nil. 2. In `completion--nth-completion' set `completion--filter-completions' to nil, unless `(memq style '(emacs21 emacs22 basic partial-completion initials flex))' such that custom completion styles which wrap the completion functions don't see the new return value format, except if the custom style opts in explicitly by binding `completion--filter-completions'. An alternative criterion is `(memq fun '(completion-emacs22-all-completions) ...)'. Unfortunately this approach will still not work if the user has advised a `completion-x-all-completions' function. The only 100% safe approach seems to transparently redirect calls to `completion-x-all-completions' to `completion--x-filter-completions', which returns the results in the new format. With these changes the patch should be 100% backward compatible. Daniel
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at 47711) by debbugs.gnu.org; 11 Aug 2021 14:17:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 11 10:17:13 2021
Received: from localhost ([127.0.0.1]:36222 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1mDp2d-0006Yh-4Z
for submit <at> debbugs.gnu.org; Wed, 11 Aug 2021 10:17:13 -0400
Received: from server.qxqx.de ([178.63.65.180]:59847 helo=mail.qxqx.de)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <mail@HIDDEN>)
id 1mDp2X-0006Xz-HJ; Wed, 11 Aug 2021 10:17:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de;
s=mail1392553390; h=Content-Type:MIME-Version:Date:Message-ID:Subject:From:Cc
:To:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:
Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:
In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
List-Post:List-Owner:List-Archive;
bh=jI1hVGefRnIqqV63epya37LbCwXprNTn1ArIfYVUC30=; b=yxBwqrKs8WqUGCKrekohWXbjMR
m08SIThso/uGJtkcBilQwb/05lPWJ9HN8PxrQOP6eiiT7fsug3Re7hkbNRdqo6Unt9xIxRfl70zp3
NsowJoPS7ZMi4mClGdJmTb33/gve/EMaHQ/WkjdJpco+1za1E/Y8Z0vV91g0rWb0eXh8=;
To: "emacs-devel@HIDDEN" <emacs-devel@HIDDEN>
From: Daniel Mendler <mail@HIDDEN>
Subject: [PATCH] Add new `completion-filter-completions` API and deferred
highlighting
Message-ID: <aa52bb9b-2adb-e579-6da1-d784e57e3c68@HIDDEN>
Date: Wed, 11 Aug 2021 16:16:57 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------3147CDE26CD3C1A11006A179"
Content-Language: en-US
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 47711
Cc: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>,
47711 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>,
48841 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
This is a multi-part message in MIME format.
--------------3147CDE26CD3C1A11006A179
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
I prepared a patch which provides the API
`completion-filter-completions`. This function supports deferred
highlighting and returns additional data with the list of matching
completion candidates. The API supersedes the existing function
`completion-all-completions`.
The main goal of the new API is to avoid expensive string allocations
and highlighting during completion. This is particularly relevant for
continuously updating completion UIs like Icomplete or Vertico.
Furthermore the end position of the completion boundaries is returned
with the completion results. This information is not provided by the
existing `completion-all-completions` API.
See also the relevant bugs bug#47711 and bug#48841. I am looking forward
to your feedback. Thank you!
Daniel Mendler
--------------3147CDE26CD3C1A11006A179
Content-Type: text/x-diff; charset=UTF-8;
name="0001-Add-new-completion-filter-completions-API-and-deferr.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename*0="0001-Add-new-completion-filter-completions-API-and-deferr.pa";
filename*1="tch"
From e7f26abc520ac36cc154a92bfb4744837d9f7e5e Mon Sep 17 00:00:00 2001
From: Daniel Mendler <mail@HIDDEN>
Date: Mon, 12 Jul 2021 21:40:32 +0200
Subject: [PATCH] Add new `completion-filter-completions` API and deferred
highlighting
Fix bug#47711.
Add a new `completion-filter-completions` API, which supersedes
`completion-all-completions`. The new API returns the matching
completion candidates and additional data. The return value is an
alist, with the keys `completions`, `base`, `end` and `highlight`.
The API can be extended in a backward compatible way later on thanks
to the use of an alist as return value.
The `completions` value is the list of completion strings *without*
applied highlighting. The completion strings are returned unmodified,
which avoids allocations and results in performance gains for
continuously updating completion UIs, like Icomplete or Vertico (GNU
ELPA). The value `base` is the base position of the completion.
Correspondingly the value `end` specifies the end position of the
completion counted from the beginning of the input strng. In
comparison, the old function `completion-all-completions` only
returned the base position in the last cdr of the returned completions
list, which complicated usage. The `end` position was not provided by
`completion-all-completions`. Given the new API the
`completion-base-position` can be set accurately. Finally the
`highlight` value is a function taking a list of completion strings
and returns a new list of new strings with highlighting applied. A
continously updating UI can use the highlighting function to apply
highlighting only to the visible completions.
* lisp/minibuffer.el:
(completion-pcm--hilit-commonality): Remove scoring computation.
(completion--adjust-metadata): Rename to `completion--style-metadata`
due to change of calling convention.
(completion--nth-completion): Call renamed metadata adjustment
function. Ignore the old property `completion--adjust-metadata`.
(completion--flex-adjust-metadata): Rename function.
(completion--twq-all): Attach `completion--unquoted` text property to
quoted completion strings.
(completion--flex-score): New optimized scoring function. Use
`completion--unquoted` text property.
(completion--flex-style-metadata): Use it.
(completion--pattern-compiler): New function.
(completion-substring--all-completions,
completion--flex-score): Use it.
(completion--hilit-commonality): New function.
(completion-hilit-commonality): Use it.
(completion--deferred-hilit): New function.
(completion-basic-all-completions,
completion-emacs21-all-completions,
completion-emacs22-all-completions): Use it.
(completion--pcm-deferred-hilit): New function.
(completion-pcm-all-completions,
completion-flex-all-completions,
completion-initials-all-completions,
completion-substring-all-completions): Use it.
(completion--filter-completions): New variable to conditionally enable
the new alist completions result format. This variable is for
internal use to preserve the existing calling convention of the
completion style `all` functions.
(completion-filter-completions): New API which returns the completion
strings and additional data as an an alist. Transparently convert
old-fashioned completion style results to the new format.
(completion-all-completions): Transparently downgrade the
new-fashioned completion style result to the old list format.
(minibuffer-completion-help): Use the new API, set
`completion-base-position` correctly.
(completion-try-completion,
completion-all-completions): Update doc string.
(completion--replace): Remove unnecessary property removal.
* test/lisp/minibuffer-tests.el:
(completion--pcm-score): Remove obsolete function.
(completion-*-test-*): Remove obsolete functions, rename.
(completion-flex-score-test-*): Add new scoring test functions.
(completion--test-style): New test helper function.
(completion-*-style-test): Add new API tests for each built-in
completion style.
(completion--test-boundaries): New test helper function.
(completion-*-boundaries-test): New boundary tests for each built-in
completion style.
(completion-filter-completions-highlight-test): New API test.
(completion-emacs22orig-all-completions): New function.
(completion-upgrade-return-type-test): New test of transparent
completion style return value upgrade.
---
lisp/minibuffer.el | 453 +++++++++++++++++++++++-----------
test/lisp/minibuffer-tests.el | 257 +++++++++++++++----
2 files changed, 516 insertions(+), 194 deletions(-)
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 9f327df28f..ba8855c4ea 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -692,6 +692,10 @@ completion--twq-all
'completions-common-part)
qprefix))))
(qcompletion (concat qprefix qnew)))
+ ;; Attach unquoted completion string, which is needed
+ ;; to score the completion in `completion--flex-score'.
+ (put-text-property 0 1 'completion--unquoted
+ completion qcompletion)
;; FIXME: Similarly here, Cygwin's mapping trips this
;; assertion.
;;(cl-assert
@@ -1035,6 +1039,17 @@ completion--styles
(delete-dups (append (cdr over) (copy-sequence completion-styles)))
completion-styles)))
+(defvar completion--filter-completions nil
+ "Enable the new completions return value format.
+If this variable is non-nil the `all-completions' function of a
+completion style should return the results in the new alist format of
+`completion-filter-completions'. This variable is purely needed to
+for backward compatibility of the existing builtin completion style
+functions. New completion style functions may always return their
+results in the new alist format, since `completion-all-completions'
+transparently converts back to the old improper list of completions
+with base size in the last cdr.")
+
(defun completion--nth-completion (n string table pred point metadata)
"Call the Nth method of completion styles."
;; We provide special support for quoting/unquoting here because it cannot
@@ -1061,6 +1076,15 @@ completion--nth-completion
;; the original table, in that case!
(functionp table))
(let ((new (funcall table string point 'completion--unquote)))
+ ;; FIXME For now do not attempt deferred highlighting if
+ ;; quoting is used. Not doing deferred highlighting is
+ ;; not too severe in this case, since
+ ;; `completion--twq-all' is already an expensive
+ ;; function, which allocates all completion strings. In
+ ;; contrast to plain completion tables, the savings of
+ ;; deferred highlighting would be minimal in the case of
+ ;; quoted completion tables.
+ (setq completion--filter-completions nil)
(setq string (pop new))
(setq table (pop new))
(setq point (pop new))
@@ -1074,9 +1098,10 @@ completion--nth-completion
string table pred point)))
(and probe (cons probe style))))
(completion--styles md)))
- (adjust-fn (get (cdr result-and-style) 'completion--adjust-metadata)))
- (when (and adjust-fn metadata)
- (setcdr metadata (cdr (funcall adjust-fn metadata))))
+ (style-md (get (cdr result-and-style) 'completion--style-metadata)))
+ (when (and style-md metadata)
+ (setcdr metadata (cdr (funcall style-md
+ string table pred point metadata))))
(if requote
(funcall requote (car result-and-style) n)
(car result-and-style))))
@@ -1084,22 +1109,64 @@ completion--nth-completion
(defun completion-try-completion (string table pred point &optional metadata)
"Try to complete STRING using completion table TABLE.
Only the elements of table that satisfy predicate PRED are considered.
-POINT is the position of point within STRING.
-The return value can be either nil to indicate that there is no completion,
-t to indicate that STRING is the only possible completion,
-or a pair (NEWSTRING . NEWPOINT) of the completed result string together with
-a new position for point."
+POINT is the position of point within STRING. The return value can be
+either nil to indicate that there is no completion, t to indicate that
+STRING is the only possible completion, or a pair (NEWSTRING . NEWPOINT)
+of the completed result string together with a new position for point.
+The METADATA may be modified by the completion style."
(completion--nth-completion 1 string table pred point metadata))
(defun completion-all-completions (string table pred point &optional metadata)
"List the possible completions of STRING in completion table TABLE.
Only the elements of table that satisfy predicate PRED are considered.
-POINT is the position of point within STRING.
-The return value is a list of completions and may contain the base-size
-in the last `cdr'."
- ;; FIXME: We need to additionally return the info needed for the
- ;; second part of completion-base-position.
- (completion--nth-completion 2 string table pred point metadata))
+POINT is the position of point within STRING. The return value is a
+list of completions and may contain the base-size in the last `cdr'.
+The METADATA may be modified by the completion style. This function
+has been superseded by `completion-filter-completions', which returns
+richer information and supports deferred candidate highlighting."
+ (let ((completion--filter-completions nil)
+ (result (completion--nth-completion 2 string table
+ pred point metadata)))
+ (if (and result (consp (car result)))
+ ;; Give the completion styles some freedom!
+ ;; If they are targeting Emacs 28 upwards only, they
+ ;; may always return a result with deferred
+ ;; highlighting. We convert back to the old format
+ ;; here by applying the highlighting eagerly.
+ (nconc (funcall (cdr (assq 'highlight result))
+ (cdr (assq 'completions result)))
+ (cdr (assq 'base result)))
+ result)))
+
+(defun completion-filter-completions (string table pred point metadata)
+ "Filter the possible completions of STRING in completion table TABLE.
+Only the elements of table that satisfy predicate PRED are considered.
+POINT is the position of point within STRING. The METADATA may be
+modified by the completion style. The return value is a alist with
+the keys:
+
+- base: Base position of the completion (from the start of STRING)
+- end: End position of the completion (from the start of STRING)
+- highlight: Highlighting function taking a list of completions and
+ returning a new list of new strings with applied highlighting.
+- completions: The list of completions.
+
+This function supersedes the function `completion-all-completions'."
+ (let* ((completion--filter-completions t)
+ (result (completion--nth-completion 2 string table
+ pred point metadata)))
+ (if (and result (not (consp (car result))))
+ ;; Deferred highlighting has been requested, but the completion
+ ;; style returned a non-deferred result. Convert the result to the
+ ;; new alist format.
+ (let* ((last (last result))
+ (base (or (cdr last) 0)))
+ (setcdr last nil)
+ `((base . ,base)
+ (end . ,(length string))
+ (highlight . identity)
+ (completions . ,result)))
+ result)))
(defun minibuffer--bitset (modified completions exact)
(logior (if modified 4 0)
@@ -1114,9 +1181,8 @@ completion--replace
;; include upon insertion.
(if minibuffer-allow-text-properties
;; If we're preserving properties, then just remove the faces
- ;; and other properties added by the completion machinery.
- (remove-text-properties 0 (length newtext) '(face completion-score)
- newtext)
+ ;; added by the completion machinery.
+ (remove-text-properties 0 (length newtext) '(face nil) newtext)
;; Remove all text properties.
(set-text-properties 0 (length newtext) nil newtext))
;; Maybe this should be in subr.el.
@@ -2021,34 +2087,48 @@ completion-hilit-commonality
It returns a list with font-lock properties applied to each element,
and with BASE-SIZE appended as the last element."
(when completions
- (let ((com-str-len (- prefix-len (or base-size 0))))
- (nconc
- (mapcar
- (lambda (elem)
- (let ((str
- ;; Don't modify the string itself, but a copy, since the
- ;; the string may be read-only or used for other purposes.
- ;; Furthermore, since `completions' may come from
- ;; display-completion-list, `elem' may be a list.
- (if (consp elem)
- (car (setq elem (cons (copy-sequence (car elem))
- (cdr elem))))
- (setq elem (copy-sequence elem)))))
- (font-lock-prepend-text-property
- 0
- ;; If completion-boundaries returns incorrect
- ;; values, all-completions may return strings
- ;; that don't contain the prefix.
- (min com-str-len (length str))
- 'face 'completions-common-part str)
- (if (> (length str) com-str-len)
- (font-lock-prepend-text-property com-str-len (1+ com-str-len)
- 'face
- 'completions-first-difference
- str)))
- elem)
- completions)
- base-size))))
+ (nconc
+ (completion--hilit-commonality (- prefix-len (or base-size 0)) completions)
+ base-size)))
+
+(defun completion--hilit-commonality (com-size completions)
+ (mapcar
+ (lambda (elem)
+ (let ((str
+ ;; Don't modify the string itself, but a copy, since the
+ ;; the string may be read-only or used for other purposes.
+ ;; Furthermore, since `completions' may come from
+ ;; display-completion-list, `elem' may be a list.
+ (if (consp elem)
+ (car (setq elem (cons (copy-sequence (car elem))
+ (cdr elem))))
+ (setq elem (copy-sequence elem)))))
+ (font-lock-prepend-text-property
+ 0
+ ;; If completion-boundaries returns incorrect
+ ;; values, all-completions may return strings
+ ;; that don't contain the prefix.
+ (min com-size (length str))
+ 'face 'completions-common-part str)
+ (if (> (length str) com-size)
+ (font-lock-prepend-text-property com-size (1+ com-size)
+ 'face
+ 'completions-first-difference
+ str)))
+ elem)
+ completions))
+
+(defun completion--deferred-hilit (completions prefix-len base end)
+ "Return completions in old format or new alist format.
+If `completion--filter-completions' is non-nil use the new format."
+ (if completion--filter-completions
+ (when completions
+ `((base . ,base)
+ (end . ,end)
+ (highlight . ,(apply-partially #'completion--hilit-commonality
+ (- prefix-len base)))
+ (completions . ,completions)))
+ (completion-hilit-commonality completions prefix-len base)))
(defun display-completion-list (completions &optional common-substring group-fun)
"Display the list of completions, COMPLETIONS, using `standard-output'.
@@ -2163,15 +2243,16 @@ minibuffer-completion-help
(end (or end (point-max)))
(string (buffer-substring start end))
(md (completion--field-metadata start))
- (completions (completion-all-completions
- string
- minibuffer-completion-table
- minibuffer-completion-predicate
- (- (point) start)
- md)))
+ (filtered-completions (completion-filter-completions
+ string
+ minibuffer-completion-table
+ minibuffer-completion-predicate
+ (- (point) start)
+ md))
+ (completions (alist-get 'completions filtered-completions)))
(message nil)
(if (or (null completions)
- (and (not (consp (cdr completions)))
+ (and (not (cdr completions))
(equal (car completions) string)))
(progn
;; If there are no completions, or if the current input is already
@@ -2181,8 +2262,7 @@ minibuffer-completion-help
(completion--message
(if completions "Sole completion" "No completions")))
- (let* ((last (last completions))
- (base-size (or (cdr last) 0))
+ (let* ((base-size (alist-get 'base filtered-completions))
(prefix (unless (zerop base-size) (substring string 0 base-size)))
(all-md (completion--metadata (buffer-substring-no-properties
start (point))
@@ -2226,9 +2306,10 @@ minibuffer-completion-help
(body-function
. ,#'(lambda (_window)
(with-current-buffer mainbuf
- ;; Remove the base-size tail because `sort' requires a properly
- ;; nil-terminated list.
- (when last (setcdr last nil))
+ ;; Apply highlighting
+ (setq completions
+ (funcall (alist-get 'highlight filtered-completions)
+ completions))
;; Sort first using the `display-sort-function'.
;; FIXME: This function is for the output of
@@ -2267,13 +2348,10 @@ minibuffer-completion-help
completions))))
(with-current-buffer standard-output
- (setq-local completion-base-position
- (list (+ start base-size)
- ;; FIXME: We should pay attention to completion
- ;; boundaries here, but currently
- ;; completion-all-completions does not give us the
- ;; necessary information.
- end))
+ (setq-local
+ completion-base-position
+ (list (+ start base-size)
+ (+ start (alist-get 'end filtered-completions))))
(setq-local completion-list-insert-choice-function
(let ((ctable minibuffer-completion-table)
(cpred minibuffer-completion-predicate)
@@ -3223,10 +3301,11 @@ completion-emacs21-try-completion
completion)))
(defun completion-emacs21-all-completions (string table pred _point)
- (completion-hilit-commonality
+ (completion--deferred-hilit
(all-completions string table pred)
(length string)
- (car (completion-boundaries string table pred ""))))
+ (car (completion-boundaries string table pred ""))
+ (length string)))
(defun completion-emacs22-try-completion (string table pred point)
(let ((suffix (substring string point))
@@ -3249,11 +3328,12 @@ completion-emacs22-try-completion
(cons (concat completion suffix) (length completion)))))
(defun completion-emacs22-all-completions (string table pred point)
- (let ((beforepoint (substring string 0 point)))
- (completion-hilit-commonality
+ (let* ((beforepoint (substring string 0 point))
+ (afterpoint (substring string point))
+ (bounds (completion-boundaries beforepoint table pred afterpoint)))
+ (completion--deferred-hilit
(all-completions beforepoint table pred)
- point
- (car (completion-boundaries beforepoint table pred "")))))
+ point (car bounds) (+ point (cdr bounds)))))
;;; Basic completion.
@@ -3312,7 +3392,7 @@ completion-basic-all-completions
'point
(substring afterpoint 0 (cdr bounds)))))
(all (completion-pcm--all-completions prefix pattern table pred)))
- (completion-hilit-commonality all point (car bounds))))
+ (completion--deferred-hilit all point (car bounds) (+ point (cdr bounds)))))
;;; Partial-completion-mode style completion.
@@ -3504,13 +3584,25 @@ flex-score-match-tightness
than the latter (which has two \"holes\" and three
one-letter-long matches).")
+(defun completion-pcm--deferred-hilit (pattern completions base end)
+ "Return completions in old format or new alist format.
+If `completion--filter-completions' is non-nil use the new format."
+ (when completions
+ (if completion--filter-completions
+ `((base . ,base)
+ (end . ,end)
+ (highlight . ,(apply-partially
+ #'completion-pcm--hilit-commonality
+ pattern))
+ (completions . ,completions))
+ (nconc (completion-pcm--hilit-commonality pattern completions) base))))
+
(defun completion-pcm--hilit-commonality (pattern completions)
"Show where and how well PATTERN matches COMPLETIONS.
PATTERN, a list of symbols and strings as seen
`completion-pcm--merge-completions', is assumed to match every
string in COMPLETIONS. Return a deep copy of COMPLETIONS where
-each string is propertized with `completion-score', a number
-between 0 and 1, and with faces `completions-common-part',
+each string is propertized with faces `completions-common-part',
`completions-first-difference' in the relevant segments."
(when completions
(let* ((re (completion-pcm--pattern->regex pattern 'group))
@@ -3525,6 +3617,54 @@ completion-pcm--hilit-commonality
(error "Internal error: %s does not match %s" re str))
(let* ((pos (if point-idx (match-beginning point-idx) (match-end 0)))
(match-end (match-end 0))
+ (md (cddr (setq last-md (match-data t last-md))))
+ (from 0))
+ (while md
+ (add-face-text-property from (pop md)
+ 'completions-common-part
+ nil str)
+ (setq from (pop md)))
+ ;; If `pattern' doesn't have an explicit trailing any, the
+ ;; regex `re' won't produce match data representing the
+ ;; region after the match. We need to account to account
+ ;; for that extra bit of match (bug#42149).
+ (unless (= from match-end)
+ (add-face-text-property from match-end
+ 'completions-common-part
+ nil str))
+ (if (> (length str) pos)
+ (add-face-text-property
+ pos (1+ pos)
+ 'completions-first-difference
+ nil str)))
+ str)
+ completions))))
+
+(defun completion--flex-score (pattern completions)
+ "Compute how well PATTERN matches COMPLETIONS.
+PATTERN, a list of strings is assumed to match every string in
+COMPLETIONS. Return a copy of COMPLETIONS where each element is
+a pair of a score and the completion string. The score lies in
+the range between -1 and 0, where -1 corresponds to the full
+match."
+ (when completions
+ (let* ((re (completion-pcm--pattern->regex pattern 'group))
+ (case-fold-search completion-ignore-case)
+ last-md)
+ (mapcar
+ (lambda (str)
+ ;; The flex completion style requires the completion to match
+ ;; the pattern to compute the scoring. For quoted completion
+ ;; tables the completions are matched against the *unquoted
+ ;; input string*. However `completion-all-completions' and
+ ;; `completion-filter-completions' return a list of *quoted
+ ;; completions*, which is subsequently sorted. Therefore we
+ ;; obtain the unquoted completion string which is stored in
+ ;; the text property `completion--unquoted'.
+ (setq str (or (get-text-property 0 'completion--unquoted str) str))
+ (unless (string-match re str)
+ (error "Internal error: %s does not match %s" re str))
+ (let* ((match-end (match-end 0))
(md (cddr (setq last-md (match-data t last-md))))
(from 0)
(end (length str))
@@ -3564,13 +3704,10 @@ completion-pcm--hilit-commonality
;; , where "len" is the string's length.
(score-numerator 0)
(score-denominator 0)
- (last-b 0)
- (update-score-and-face
- (lambda (a b)
- "Update score and face given match range (A B)."
- (add-face-text-property a b
- 'completions-common-part
- nil str)
+ (last-b 0))
+ (while md
+ (let ((a from)
+ (b (pop md)))
(setq
score-numerator (+ score-numerator (- b a)))
(unless (or (= a last-b)
@@ -3583,26 +3720,29 @@ completion-pcm--hilit-commonality
(/ 1.0
flex-score-match-tightness)))))
(setq
- last-b b))))
- (while md
- (funcall update-score-and-face from (pop md))
+ last-b b))
(setq from (pop md)))
;; If `pattern' doesn't have an explicit trailing any, the
;; regex `re' won't produce match data representing the
;; region after the match. We need to account to account
;; for that extra bit of match (bug#42149).
(unless (= from match-end)
- (funcall update-score-and-face from match-end))
- (if (> (length str) pos)
- (add-face-text-property
- pos (1+ pos)
- 'completions-first-difference
- nil str))
- (unless (zerop (length str))
- (put-text-property
- 0 1 'completion-score
- (/ score-numerator (* end (1+ score-denominator)) 1.0) str)))
- str)
+ (let ((a from)
+ (b match-end))
+ (setq
+ score-numerator (+ score-numerator (- b a)))
+ (unless (or (= a last-b)
+ (zerop last-b)
+ (= a (length str)))
+ (setq
+ score-denominator (+ score-denominator
+ 1
+ (expt (- a last-b 1)
+ (/ 1.0
+ flex-score-match-tightness)))))
+ (setq
+ last-b b)))
+ (cons (- (/ score-numerator (* end (1+ score-denominator)) 1.0)) str)))
completions))))
(defun completion-pcm--find-all-completions (string table pred point
@@ -3700,11 +3840,11 @@ completion-pcm--find-all-completions
(list pattern all prefix suffix)))))
(defun completion-pcm-all-completions (string table pred point)
- (pcase-let ((`(,pattern ,all ,prefix ,_suffix)
+ (pcase-let ((`(,pattern ,all ,prefix ,suffix)
(completion-pcm--find-all-completions string table pred point)))
- (when all
- (nconc (completion-pcm--hilit-commonality pattern all)
- (length prefix)))))
+ (completion-pcm--deferred-hilit pattern all
+ (length prefix)
+ (- (length string) (length suffix)))))
(defun completion--common-suffix (strs)
"Return the common suffix of the strings STRS."
@@ -3885,8 +4025,8 @@ completion-pcm-try-completion
;;; Substring completion
;; Mostly derived from the code of `basic' completion.
-(defun completion-substring--all-completions
- (string table pred point &optional transform-pattern-fn)
+(defun completion--pattern-compiler
+ (string table pred point transform-pattern-fn)
"Match the presumed substring STRING to the entries in TABLE.
Respect PRED and POINT. The pattern used is a PCM-style
substring pattern, but it be massaged by TRANSFORM-PATTERN-FN, if
@@ -3904,12 +4044,23 @@ completion-substring--all-completions
(pattern (completion-pcm--optimize-pattern
(if transform-pattern-fn
(funcall transform-pattern-fn pattern)
- pattern)))
- (all (completion-pcm--all-completions prefix pattern table pred)))
- (list all pattern prefix suffix (car bounds))))
+ pattern))))
+ (list pattern prefix suffix)))
+
+(defun completion-substring--all-completions
+ (string table pred point &optional transform-pattern-fn)
+ "Match the presumed substring STRING to the entries in TABLE.
+Respect PRED and POINT. The pattern used is a PCM-style
+substring pattern, but it be massaged by TRANSFORM-PATTERN-FN, if
+that is non-nil."
+ (pcase-let (((and result `(,pattern ,prefix ,_suffix))
+ (completion--pattern-compiler string table pred point
+ transform-pattern-fn)))
+ (cons (completion-pcm--all-completions prefix pattern table pred)
+ result)))
(defun completion-substring-try-completion (string table pred point)
- (pcase-let ((`(,all ,pattern ,prefix ,suffix ,_carbounds)
+ (pcase-let ((`(,all ,pattern ,prefix ,suffix)
(completion-substring--all-completions
string table pred point)))
(if minibuffer-completing-file-name
@@ -3917,12 +4068,12 @@ completion-substring-try-completion
(completion-pcm--merge-try pattern all prefix suffix)))
(defun completion-substring-all-completions (string table pred point)
- (pcase-let ((`(,all ,pattern ,prefix ,_suffix ,_carbounds)
+ (pcase-let ((`(,all ,pattern ,prefix ,suffix)
(completion-substring--all-completions
string table pred point)))
- (when all
- (nconc (completion-pcm--hilit-commonality pattern all)
- (length prefix)))))
+ (completion-pcm--deferred-hilit pattern all
+ (length prefix)
+ (- (length string) (length suffix)))))
;;; "flex" completion, also known as flx/fuzzy/scatter completion
;; Completes "foo" to "frodo" and "farfromsober"
@@ -3932,42 +4083,40 @@ completion-flex-nospace
:version "27.1"
:type 'boolean)
-(put 'flex 'completion--adjust-metadata 'completion--flex-adjust-metadata)
-
-(defun completion--flex-adjust-metadata (metadata)
- (cl-flet
- ((compose-flex-sort-fn
- (existing-sort-fn) ; wish `cl-flet' had proper indentation...
- (lambda (completions)
- (let ((pre-sorted
- (if existing-sort-fn
- (funcall existing-sort-fn completions)
- completions)))
- (cond
- ((or (not (window-minibuffer-p))
- ;; JT@2019-12-23: FIXME: this is still wrong. What
- ;; we need to test here is "some input that actually
- ;; leads to flex filtering", not "something after
- ;; the minibuffer prompt". Among other
- ;; inconsistencies, the latter is always true for
- ;; file searches, meaning the next clauses will be
- ;; ignored.
- (> (point-max) (minibuffer-prompt-end)))
- (sort
- pre-sorted
- (lambda (c1 c2)
- (let ((s1 (get-text-property 0 'completion-score c1))
- (s2 (get-text-property 0 'completion-score c2)))
- (> (or s1 0) (or s2 0))))))
- (t pre-sorted))))))
- `(metadata
- (display-sort-function
- . ,(compose-flex-sort-fn
- (completion-metadata-get metadata 'display-sort-function)))
- (cycle-sort-function
- . ,(compose-flex-sort-fn
- (completion-metadata-get metadata 'cycle-sort-function)))
- ,@(cdr metadata))))
+(put 'flex 'completion--style-metadata 'completion--flex-style-metadata)
+
+(defun completion--flex-style-metadata (string table pred point metadata)
+ ;; Use the modified flex sorting function only for non-empty input.
+ ;; In an older version of `completion--flex-adjust-metadata', the
+ ;; check (> (point-max) (minibuffer-prompt-end))) was used instead.
+ (unless (eq string "")
+ (let ((pattern (car (completion--pattern-compiler
+ string table pred point
+ #'completion-flex--make-flex-pattern))))
+ (cl-flet
+ ((compose-flex-sort-fn
+ (existing-sort-fn) ; wish `cl-flet' had proper indentation...
+ (lambda (completions)
+ (let* ((sorted (sort (completion--flex-score
+ pattern
+ (if existing-sort-fn
+ (funcall existing-sort-fn completions)
+ completions))
+ #'car-less-than-car))
+ (cell sorted))
+ ;; Remove score decorations, reuse the list to avoid allocations.
+ (while cell
+ (setcar cell (cdar cell))
+ (pop cell))
+ sorted))))
+ `(metadata
+ (display-sort-function
+ . ,(compose-flex-sort-fn
+ (completion-metadata-get metadata 'display-sort-function)))
+ (cycle-sort-function
+ . ,(compose-flex-sort-fn
+ (completion-metadata-get metadata 'cycle-sort-function)))
+ ,@(cdr metadata))))))
(defun completion-flex--make-flex-pattern (pattern)
"Convert PCM-style PATTERN into PCM-style flex pattern.
@@ -3989,7 +4138,7 @@ completion-flex--make-flex-pattern
(defun completion-flex-try-completion (string table pred point)
"Try to flex-complete STRING in TABLE given PRED and POINT."
(unless (and completion-flex-nospace (string-search " " string))
- (pcase-let ((`(,all ,pattern ,prefix ,suffix ,_carbounds)
+ (pcase-let ((`(,all ,pattern ,prefix ,suffix)
(completion-substring--all-completions
string table pred point
#'completion-flex--make-flex-pattern)))
@@ -4006,13 +4155,13 @@ completion-flex-try-completion
(defun completion-flex-all-completions (string table pred point)
"Get flex-completions of STRING in TABLE, given PRED and POINT."
(unless (and completion-flex-nospace (string-search " " string))
- (pcase-let ((`(,all ,pattern ,prefix ,_suffix ,_carbounds)
+ (pcase-let ((`(,all ,pattern ,prefix ,suffix)
(completion-substring--all-completions
string table pred point
#'completion-flex--make-flex-pattern)))
- (when all
- (nconc (completion-pcm--hilit-commonality pattern all)
- (length prefix))))))
+ (completion-pcm--deferred-hilit pattern all
+ (length prefix)
+ (- (length string) (length suffix))))))
;; Initials completion
;; Complete /ums to /usr/monnier/src or lch to list-command-history.
@@ -4049,7 +4198,11 @@ completion-initials-expand
(defun completion-initials-all-completions (string table pred _point)
(let ((newstr (completion-initials-expand string table pred)))
(when newstr
- (completion-pcm-all-completions newstr table pred (length newstr)))))
+ (pcase-let ((`(,pattern ,all ,prefix ,_suffix)
+ (completion-pcm--find-all-completions newstr table
+ pred (length newstr))))
+ (completion-pcm--deferred-hilit pattern all
+ (length prefix) (length string))))))
(defun completion-initials-try-completion (string table pred _point)
(let ((newstr (completion-initials-expand string table pred)))
diff --git a/test/lisp/minibuffer-tests.el b/test/lisp/minibuffer-tests.el
index c3ba8f9a92..4ebf27fd1d 100644
--- a/test/lisp/minibuffer-tests.el
+++ b/test/lisp/minibuffer-tests.el
@@ -188,10 +188,6 @@ completion-all-sorted-completions
'("some/alpha" "base/epsilon" "base/delta"))
`("epsilon" "delta" "beta" "alpha" "gamma" . 5))))
-(defun completion--pcm-score (comp)
- "Get `completion-score' from COMP."
- (get-text-property 0 'completion-score comp))
-
(defun completion--pcm-first-difference-pos (comp)
"Get `completions-first-difference' from COMP."
(cl-loop for pos = (next-single-property-change 0 'face comp)
@@ -215,25 +211,12 @@ completion-pcm-test-2
"barfoobar")))
(ert-deftest completion-pcm-test-3 ()
- ;; Full match!
- (should (eql
- (completion--pcm-score
- (car (completion-pcm-all-completions
- "R" '("R" "hello") nil 1)))
- 1.0)))
-
-(ert-deftest completion-pcm-test-4 ()
- ;; One fourth of a match and no match due to point being at the end
- (should (eql
- (completion--pcm-score
- (car (completion-pcm-all-completions
- "RO" '("RaOb") nil 1)))
- (/ 1.0 4.0)))
+ ;; No match due to point being at the end
(should (null
(completion-pcm-all-completions
"RO" '("RaOb") nil 2))))
-(ert-deftest completion-pcm-test-5 ()
+(ert-deftest completion-pcm-test-4 ()
;; Since point is at the beginning, there is nothing that can really
;; be typed anymore
(should (null
@@ -241,7 +224,7 @@ completion-pcm-test-5
(car (completion-pcm-all-completions
"f" '("few" "many") nil 0))))))
-(ert-deftest completion-pcm-test-6 ()
+(ert-deftest completion-pcm-test-5 ()
;; Wildcards and delimiters work
(should (equal
(car (completion-pcm-all-completions
@@ -252,26 +235,12 @@ completion-pcm-test-6
"li-pac*" '("do-not-list-packages") nil 7)))))
(ert-deftest completion-substring-test-1 ()
- ;; One third of a match!
(should (equal
(car (completion-substring-all-completions
"foo" '("hello" "world" "barfoobar") nil 3))
- "barfoobar"))
- (should (eql
- (completion--pcm-score
- (car (completion-substring-all-completions
- "foo" '("hello" "world" "barfoobar") nil 3)))
- (/ 1.0 3.0))))
+ "barfoobar")))
(ert-deftest completion-substring-test-2 ()
- ;; Full match!
- (should (eql
- (completion--pcm-score
- (car (completion-substring-all-completions
- "R" '("R" "hello") nil 1)))
- 1.0)))
-
-(ert-deftest completion-substring-test-3 ()
;; Substring match
(should (equal
(car (completion-substring-all-completions
@@ -281,7 +250,7 @@ completion-substring-test-3
(car (completion-substring-all-completions
"custgroup" '("customize-group") nil 5)))))
-(ert-deftest completion-substring-test-4 ()
+(ert-deftest completion-substring-test-3 ()
;; `completions-first-difference' should be at the right place
(should (eql
(completion--pcm-first-difference-pos
@@ -306,14 +275,6 @@ completion-flex-test-1
"fabrobazo")))
(ert-deftest completion-flex-test-2 ()
- ;; Full match!
- (should (eql
- (completion--pcm-score
- (car (completion-flex-all-completions
- "R" '("R" "hello") nil 1)))
- 1.0)))
-
-(ert-deftest completion-flex-test-3 ()
;; Another fuzzy match, but more of a "substring" one
(should (equal
(car (completion-flex-all-completions
@@ -331,5 +292,213 @@ completion-flex-test-3
"custgroup" '("customize-group-other-window") nil 9)))
15)))
+(ert-deftest completion-flex-score-test-1 ()
+ ;; Full match!
+ (should (equal
+ (completion--flex-score '(prefix "R") '("R"))
+ (list (cons -1.0 "R")))))
+
+(ert-deftest completion-flex-score-test-2 ()
+ ;; One third and half of a match!
+ (should (equal
+ (completion--flex-score '(prefix "foo")
+ '("barfoobar" "fooboo"))
+ (list (cons (/ -1.0 3.0) "barfoobar")
+ (cons (/ -1.0 2.0) "fooboo")))))
+
+(ert-deftest completion-flex-score-test-3 ()
+ ;; One fourth of a match
+ (should (eql
+ (caar (completion--flex-score '(prefix "R" point "O")
+ '("RaOb")))
+ (/ -1.0 4.0))))
+
+(ert-deftest completion-flex-score-test-4 ()
+ ;; For quoted completion tables, score the unquoted completion string.
+ (should (equal
+ (completion--flex-score
+ '(prefix "R")
+ (list (propertize "X" 'completion--unquoted "R")))
+ (list (cons -1.0 "R")))))
+
+(defun completion--test-style (style string point table filtered)
+ (let* ((completion-styles (list style))
+ (pred (lambda (x) (not (string-search "!" x))))
+ (result (completion-filter-completions
+ string table pred point nil)))
+ (should (equal (alist-get 'base result) 0))
+ (should (equal (alist-get 'end result) (length string)))
+ (should (equal (alist-get 'completions result) filtered))
+ (should (not (memq (alist-get 'highlight result) '(nil identity))))
+ (should (equal (completion-all-completions string table pred point)
+ (append filtered 0)))))
+
+(ert-deftest completion-basic-style-test-1 ()
+ ;; point at the beginning |foo
+ (completion--test-style 'basic "foo" 0
+ '("foobar" "foo!" "barfoo" "xfooy" "boobar")
+ '("foobar" "barfoo" "xfooy")))
+
+(ert-deftest completion-basic-style-test-2 ()
+ ;; point foo
+ (completion--test-style 'basic "foo" 2
+ '("foobar" "foo!" "fobar" "barfoo" "xfooy" "boobar")
+ '("foobar")))
+
+(ert-deftest completion-substring-style-test ()
+ (completion--test-style 'substring "foo" 1
+ '("foobar" "foo!" "barfoo" "xfooy" "boobar")
+ '("foobar" "barfoo" "xfooy")))
+
+(ert-deftest completion-emacs21-style-test ()
+ (completion--test-style 'emacs21 "foo" 1
+ '("foobar" "foo!" "fobar" "barfoo" "xfooy" "boobar")
+ '("foobar")))
+
+(ert-deftest completion-emacs22-style-test ()
+ (completion--test-style 'emacs22 "fo0" 1
+ '("foobar" "foo!" "fobar" "barfoo" "xfooy" "boobar")
+ '("foobar" "fobar"))) ;; suffix ignored completely
+
+(ert-deftest completion-flex-style-test ()
+ (completion--test-style 'flex "abc" 1
+ '("abc" "abc!" "xaybzc" "xaybz")
+ '("abc" "xaybzc")))
+
+(ert-deftest completion-initials-style-test ()
+ (completion--test-style 'initials "abc" 1
+ '("a-b-c" "a-b-c!" "ax-by-cz" "xax-by-cz")
+ '("a-b-c" "ax-by-cz")))
+
+(ert-deftest completion-pcm-style-test ()
+ (completion--test-style 'partial-completion "ax-b-c" 1
+ '("ax-b-c" "ax-b-c!" "ax-by-cz" "xax-by-cz")
+ '("ax-b-c" "ax-by-cz")))
+
+(ert-deftest completion-filter-completions-highlight-test ()
+ ;; point at the beginning |foo
+ (let* ((completion-styles '(basic))
+ (result (completion-filter-completions
+ "foo" '("foobar" "fbarfoo" "fxfooy" "bar")
+ nil 1 nil)))
+ (should (equal
+ (format "%S" (alist-get 'completions result))
+ (format "%S" '("foobar" "fbarfoo" "fxfooy"))))
+ (should (equal
+ (format "%S" (funcall (alist-get 'highlight result)
+ (alist-get 'completions result)))
+ (format "%S"
+ '(#("foobar" 0 1 (face (completions-common-part))
+ 1 2 (face (completions-first-difference)))
+ #("fbarfoo" 0 1 (face (completions-common-part))
+ 1 2 (face (completions-first-difference)))
+ #("fxfooy" 0 1 (face (completions-common-part))
+ 1 2 (face (completions-first-difference)))))))))
+
+(defun completion--test-boundaries (style string table result)
+ (let ((table
+ (lambda (str pred action)
+ (pcase action
+ (`(boundaries . ,suffix) `(boundaries
+ ,(1+ (string-match-p "<\\|/" str))
+ . ,(or (string-search ">" suffix) (length suffix))))
+ (_ (complete-with-action action table
+ (replace-regexp-in-string ".*[</]" "" str)
+ pred)))))
+ (point (string-search "|" string))
+ (string (string-replace "|" "" string))
+ (completion-styles (list style)))
+ (should (equal
+ (assq-delete-all
+ (if (assq 'highlight result) '-does-not-exist 'highlight)
+ (completion-filter-completions
+ string table nil point nil))
+ result))
+ (should (equal
+ (completion-all-completions
+ string table nil point)
+ (append (alist-get 'completions result)
+ (alist-get 'base result))))))
+
+(ert-deftest completion-emacs21-boundaries-test ()
+ (completion--test-boundaries 'emacs21 "before<in|put>after"
+ '("other") nil)
+ (completion--test-boundaries 'emacs21 "before<in|put>after"
+ '("ainput>after" "input>after" "inpux>after"
+ "inxputy>after" "input>after2")
+ '((base . 7)
+ (end . 18)
+ (completions "input>after" "input>after2"))))
+
+(ert-deftest completion-emacs22-boundaries-test ()
+ (completion--test-boundaries 'emacs22 "before<in|put>after"
+ '("other") nil)
+ (completion--test-boundaries 'emacs22 "before<in|put>after"
+ '("ainxxx" "inyy" "inzzz")
+ '((base . 7)
+ (end . 12)
+ (completions "inyy" "inzzz"))))
+
+(ert-deftest completion-basic-boundaries-test ()
+ (completion--test-boundaries 'basic "before<in|put>after"
+ '("other") nil)
+ (completion--test-boundaries 'basic "before<in|put>after"
+ '("ainput" "input" "inpux" "inxputy")
+ '((base . 7)
+ (end . 12)
+ (completions "input" "inxputy"))))
+
+(ert-deftest completion-substring-boundaries-test ()
+ (completion--test-boundaries 'substring "before<in|puts>after"
+ '("other") nil)
+ (completion--test-boundaries 'substring "before<in|puts>after"
+ '("ainputs" "inputs" "inpux" "inxputsy")
+ '((base . 7)
+ (end . 13)
+ (completions "ainputs" "inputs" "inxputsy"))))
+
+(ert-deftest completion-pcm-boundaries-test ()
+ (completion--test-boundaries 'partial-completion "before<in-p|t>after"
+ '("other") nil)
+ (completion--test-boundaries 'partial-completion "before<in-p|t>after"
+ '("ain-pu-ts" "in-pts" "in-pu-ts" "in-px" "inx-ptsy")
+ '((base . 7)
+ (end . 12)
+ (completions "in-pts" "in-pu-ts" "inx-ptsy"))))
+
+(ert-deftest completion-initials-boundaries-test ()
+ (completion--test-boundaries 'initials "/ip|t"
+ '("other") nil)
+ (completion--test-boundaries 'initials "/ip|t"
+ '("ain/pu/ts" "in/pts" "in/pu/ts" "a/in/pu/ts"
+ "in/pu/ts/foo" "in/px" "inx/ptsy")
+ '((base . 1)
+ (end . 4)
+ (completions "in/pu/ts" "in/pu/ts/foo"))))
+
+(defun completion-emacs22orig-all-completions (string table pred point)
+ (let ((beforepoint (substring string 0 point)))
+ (completion-hilit-commonality
+ (all-completions beforepoint table pred)
+ point
+ (car (completion-boundaries beforepoint table pred "")))))
+
+(ert-deftest completion-upgrade-return-type-test ()
+ ;; Test transparent upgrade of old completion style return value
+ ;; to new return value format.
+ (let ((completion-styles-alist
+ '((emacs22orig completion-emacs22-try-completion
+ completion-emacs22orig-all-completions nil))))
+ (completion--test-boundaries 'emacs22orig "before<in|put>after"
+ '("ainxxx" "inyy" "inzzz")
+ '((base . 7)
+ ;; 18 is incorrect, should be 12!
+ ;; But the information is not available
+ ;; due to the completion-style upgrade.
+ (end . 18)
+ ;; Identity highlighting function.
+ (highlight . identity)
+ (completions "inyy" "inzzz")))))
+
(provide 'minibuffer-tests)
;;; minibuffer-tests.el ends here
--
2.20.1
--------------3147CDE26CD3C1A11006A179--
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 7 Jul 2021 08:56:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 07 04:56:17 2021 Received: from localhost ([127.0.0.1]:50828 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1m13Ls-0003eE-Ph for submit <at> debbugs.gnu.org; Wed, 07 Jul 2021 04:56:16 -0400 Received: from server.qxqx.de ([178.63.65.180]:47469 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1m13Lq-0003dw-Aq; Wed, 07 Jul 2021 04:56:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=o3u4a1/ZU7W8pFLoHziFDm4XIG8WTn7yTgWzxLbAWns=; b=gK3nxdsmphgKTeETBcWmUA4Qo4 RXioGPDTTt2+6BBibZiNXl6TkIjZzWODFkUe4nCHqnjBNe/RTTOf4gv21nCSPj+CVPUOx3IDvkJd/ MRQUXLGIzxJLD9wS5GLJQI1sU87P9dSvztcdan9oTMWD+M8HvgMeDm+MEwY3McP+gD5s=; Subject: Re: bug#48841: fido-mode is slower than ido-mode with similar settings To: Dmitry Gutov <dgutov@HIDDEN>, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <f94541d3-5f93-9a23-8256-3bbc453f127a@HIDDEN> <87eedgy7pt.fsf@HIDDEN> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@HIDDEN> <87a6o3x5j7.fsf@HIDDEN> <dd69952b-bb7b-7e86-466c-c2117f839cc4@HIDDEN> <87y2bnv5xc.fsf@HIDDEN> <35be6652-9c8d-ee21-e9eb-9598ad6777eb@HIDDEN> <CALDnm510An-+2b31oT_TE0akNjU_KWA7iv9RjN1Hr-KXSZ68sw@HIDDEN> <d57185f3-c28a-8c48-a50c-0b4b8bdb95c8@HIDDEN> <CALDnm51En25oyL8i+g-_oxBtCgmts0skjqwNE8hBn66k_DyV_g@HIDDEN> <858682b2-b8fd-898b-bef3-97dbe5e4debc@HIDDEN> <87mtrwuy4v.fsf@HIDDEN> <2234991b-c2e0-81e3-c1ef-b1d94d35a728@HIDDEN> <87v96hu845.fsf@HIDDEN> <310ab8d8-2bba-33bb-1aa4-1dc88dcb57d8@HIDDEN> <877disb30s.fsf@HIDDEN> <526eeb14-31c2-f414-ec44-192180d59164@HIDDEN> From: Daniel Mendler <mail@HIDDEN> Message-ID: <7fc8ce6d-20ba-79ed-56d8-f10be72cddc8@HIDDEN> Date: Wed, 7 Jul 2021 10:56:05 +0200 MIME-Version: 1.0 In-Reply-To: <526eeb14-31c2-f414-ec44-192180d59164@HIDDEN> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 Cc: Stefan Monnier <monnier@HIDDEN>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) On 7/4/21 3:53 AM, Dmitry Gutov wrote: >> - icomplete.el? for fido-mode & friends >> - minibuffer.el, for the *Completions* buffer >> - company.el >> - Any notable others? > > corfu, consult, etc? Probably Ivy too. All of these are in GNU ELPA. > > BTW, I think Daniel had some ideas about applying the face property > lazily as well. I can't find the particular discussion now, but perhaps > he can add to this discussion as well. Yes, Vertico and Corfu apply highlighting lazily. This leads to significant performance wins. See `vertico--all-completions` in https://github.com/minad/vertico/blob/main/vertico.el#L243-L279 and bug#47711. The technique I am using in Vertico and Corfu retains backward compatibility, such that the strings are returned unmodified by the completion style. Highlighting is applied lazily by copying the candidate strings and mutating the copies. For now I am relying on advices. One could add an optional argument (or dynamically bound variable) to completion styles which tell the completion style to opt out of copying the candidates and the highlighting. Daniel
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.Received: (at 47711) by debbugs.gnu.org; 18 Apr 2021 21:26:57 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 18 17:26:57 2021 Received: from localhost ([127.0.0.1]:47979 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1lYEwS-0004GL-Vu for submit <at> debbugs.gnu.org; Sun, 18 Apr 2021 17:26:57 -0400 Received: from server.qxqx.de ([178.63.65.180]:43317 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mail@HIDDEN>) id 1lYEwQ-0004G5-5P for 47711 <at> debbugs.gnu.org; Sun, 18 Apr 2021 17:26:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=1i52Ca6rZx32peDDFalbTqTolCv2NoCa8/Axw8v2Ch8=; b=G7SLFZWkGEcnOzpaALmVUjqf7t F5gysiVZxDsq+foQInGF+P7h4da0m3ArgVg9ZrwPbMGtL0AqCCzcUry92E8Mw51lHou52OxRGi8Wa 1y0pYvsyFbhh61n5wJ2/pdiBOol0FrDlv+r9HSMoJdaam08/RSpgBK7avk25zyGd21M4=; Subject: Re: bug#47711: Acknowledgement (27.1; Deferred highlighting support in `completion-all-completions', `vertico--all-completions`) To: 47711 <at> debbugs.gnu.org References: <3cc8aae8-58fc-abce-728c-090595281da2@HIDDEN> <handler.47711.B.16181742862702.ack <at> debbugs.gnu.org> From: Daniel Mendler <mail@HIDDEN> Message-ID: <4e53fde0-4c08-73d6-f500-5085ea4ecdfc@HIDDEN> Date: Sun, 18 Apr 2021 23:26:44 +0200 MIME-Version: 1.0 In-Reply-To: <handler.47711.B.16181742862702.ack <at> debbugs.gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47711 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Deferred highlighting is also useful for completion-at-point, see the ELPA Corfu package, `corfu--all-completions`, which uses the same method as Vertico.
bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 11 Apr 2021 20:51:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 11 16:51:26 2021
Received: from localhost ([127.0.0.1]:55936 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1lVh3F-0000hW-O7
for submit <at> debbugs.gnu.org; Sun, 11 Apr 2021 16:51:26 -0400
Received: from lists.gnu.org ([209.51.188.17]:52524)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <mail@HIDDEN>) id 1lVh3D-0000hO-VM
for submit <at> debbugs.gnu.org; Sun, 11 Apr 2021 16:51:24 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:38496)
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <mail@HIDDEN>)
id 1lVh3D-0000MJ-NK
for bug-gnu-emacs@HIDDEN; Sun, 11 Apr 2021 16:51:23 -0400
Received: from server.qxqx.de ([2a01:4f8:121:346::180]:36941 helo=mail.qxqx.de)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <mail@HIDDEN>)
id 1lVh3B-0000s7-0p
for bug-gnu-emacs@HIDDEN; Sun, 11 Apr 2021 16:51:23 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de;
s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:
Message-ID:Subject:From:Cc:To:Sender:Reply-To:Content-ID:Content-Description:
Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:
In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
List-Post:List-Owner:List-Archive;
bh=phweBwQ12UjBVQH3aBBq3QC32jFVbUVJO67bDBnsOG4=; b=zW5FvyGZ5fSOyOBNNxuk8MRqDS
tWjdWfWuC1C5+wVxXulc6UsLs0wFuD3gpOCVGMJAlLkL9sYpG5zBpNe7EBMl4WZO77YjKBJ8WKXe0
1VI1j2goeMO6fl0i6FYYo9LR85K2sUaWc1YfefNiDNrIBzYUKYy9EhrI5tcFG4ZzYEKo=;
To: bug-gnu-emacs@HIDDEN
From: Daniel Mendler <mail@HIDDEN>
Subject: 27.1; Deferred highlighting support in `completion-all-completions',
`vertico--all-completions`
Message-ID: <3cc8aae8-58fc-abce-728c-090595281da2@HIDDEN>
Date: Sun, 11 Apr 2021 22:51:14 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=2a01:4f8:121:346::180;
envelope-from=mail@HIDDEN; helo=mail.qxqx.de
X-Spam_score_int: -41
X-Spam_score: -4.2
X-Spam_bar: ----
X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.4 (-)
X-Debbugs-Envelope-To: submit
Cc: Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.4 (--)
Emacs is lacking a possibility to defer the completion highlighting when
computing completions via `completion-all-completions'. This feature is
important for the performance of completion UIs when the set of all
completions is much larger than the set of completions which are
displayed.
The Vertico package defers highlighting by modifying the
`completion*-hilit-*' function with advices.
(declare-function orderless-highlight-matches "ext:orderless")
(defun vertico--all-completions (&rest args)
"Compute all completions for ARGS with deferred highlighting."
(cl-letf* ((orig-pcm (symbol-function
#'completion-pcm--hilit-commonality))
(orig-flex (symbol-function
#'completion-flex-all-completions))
((symbol-function #'completion-flex-all-completions)
(lambda (&rest args)
;; Unfortunately for flex we have to undo the deferred
highlighting, since flex uses
;; the completion-score for sorting, which is applied
during highlighting.
(cl-letf (((symbol-function
#'completion-pcm--hilit-commonality) orig-pcm))
(apply orig-flex args))))
;; Defer the following highlighting functions
(hl #'identity)
((symbol-function #'completion-hilit-commonality)
(lambda (cands prefix &optional base)
(setq hl (lambda (x) (nconc
(completion-hilit-commonality x prefix base) nil)))
(and cands (nconc cands base))))
((symbol-function #'completion-pcm--hilit-commonality)
(lambda (pattern cands)
(setq hl (lambda (x) (completion-pcm--hilit-commonality
pattern x)))
cands))
((symbol-function #'orderless-highlight-matches)
(lambda (pattern cands)
(setq hl (lambda (x) (orderless-highlight-matches
pattern x)))
cands)))
(cons (apply #'completion-all-completions args) hl)))
This function `vertico--all-completions` returns the list of completions
and a highlighting
function which can then be used to highlight the completions on the fly.
It is a prototype of how some improved functionality in Emacs could look
like.
(completion-all-completions STRING TABLE PRED POINT &optional METADATA
DEFER-HL)
or
(completion-all-completions-defer-hl STRING TABLE PRED POINT &optional
METADATA)
If DEFER-HL=t, then the function returns the completions and a
highlighting function. One may consider returning a triple of base,
completions and highlighting functions. Internally the completion styles
should be adapted such that they support the deferred highlighting.
It could be that this feature becomes less needed with the introduction
of gccemacs in the future.
Daniel Mendler <mail@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#47711; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.