GNU bug report logs - #47711
27.1; Deferred highlighting support in `completion-all-completions', `vertico--all-completions`
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Package: emacs;
Reported by: Daniel Mendler <mail@HIDDEN>; dated Sun, 11 Apr 2021 20:52:01 UTC;
Maintainer for emacs is
bug-gnu-emacs@HIDDEN.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at submit <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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).
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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)?
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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--
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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?
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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--
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
--=-=-=--
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
--=-=-=--
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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).
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
--=-=-=--
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
--=-=-=--
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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--
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
--=-=-=--
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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--
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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).
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
)
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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?
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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?
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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?
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
)
--=-=-=--
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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?
Information forwarded
to bug-gnu-emacs@HIDDEN:
bug#47711; Package emacs.
Full text available.
Message received at 47711 <at> debbugs.gnu.org:
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.g