Received: (at 74561) by debbugs.gnu.org; 11 Feb 2025 20:07:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 11 15:07:22 2025 Received: from localhost ([127.0.0.1]:58922 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1thwXR-0006dL-HM for submit <at> debbugs.gnu.org; Tue, 11 Feb 2025 15:07:22 -0500 Received: from mail-ej1-x62e.google.com ([2a00:1450:4864:20::62e]:52680) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>) id 1thwXO-0006d4-NH for 74561 <at> debbugs.gnu.org; Tue, 11 Feb 2025 15:07:19 -0500 Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-aaedd529ba1so739700666b.1 for <74561 <at> debbugs.gnu.org>; Tue, 11 Feb 2025 12:07:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739304432; x=1739909232; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=C2pDifaXXadAdtuuWGGzF9fzNUIjmr1sMsjwdaohGLo=; b=Yrafs+utuFVstLxBv5brw+zlOfcfsrnkxmkkmAloSdl4koZtj2F8HvQMTqLd5rE4CE 2kLGwMKzH17WgC7GVn9mdMg69jtKjERO9mHibevY+Ck6r8UE78p3Kai0oek/1eaDr2N6 kHqVuzE180SMKWS90YToFRvzamBdCq3aVupX7pgFGb8p+siXPyip0awQWsAlSWkrSuX9 ZstgFQtM6qGwM9OVAPQ7xQswfJKvW0x6jqzddoWA7DeVWl+BVomYeoj77JrH+cecU0dh Ywal2WR1a47rXjDzFBs+q1qAo2C8AwF7d94Rk2vrlVByQBKRJTHOEe9lzvvYXCBgznuz 4fxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739304432; x=1739909232; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=C2pDifaXXadAdtuuWGGzF9fzNUIjmr1sMsjwdaohGLo=; b=IPS8mV2Oo2I8u8xsAKTr0LWjZ64b6L8B81KBjFxmsJZz9d+Mc9ywPsqMueW1L78XMO wfnZl8HdGXqYltz3j+TF8uHelQFYefOSrYm5oGkM94lhfModixujorfXXGoVtj774UdY v+reEsgnO6INVFLmNIghU8uY/PM3Gfky3sP5hJM1/hyDdGARl+KGGGYZv5T4p354Jy9Q 1S3hKrMxtFxnvgynjJrWuoBqZfUwd+8FaYabf+KPvZq2tyMYeWSH2Bg+mbmFwlkzJfLN JQu0RhZoHkKhqoaiXNNPcGMamQDIusoPPyPshNpkcE26yGUg76rov/rRWV0OZPcYrcxU 1Dcw== X-Forwarded-Encrypted: i=1; AJvYcCUcnKU9I7MtZinygmlyKvU4ArAkYvibJQtKgpxKQ60jXzCuVXOdbQXQmEkQjXijajw6FI3TAA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzVHOxbQgyPDYPDiJIzu0yksKLXCyS1sPOIoBbtSCjZejWyP2nF zzMHbfputxZLu/sigo2TyY1y+aQPqUReP9VSGSRq6hpdhFqfwlM0wmQGT8Aqss87cXgXUrxzwxw Jgzxxo5QXazzBxnuj6GKFgyGAWZ4JTD7J9mek0w== X-Gm-Gg: ASbGnctCWAtx97iPtvL726A3kwRyquBBzkKhupMSFesvLBHp2AWjPFnjBVUaMWN2JS4 DQF5yVvpfzmck6qYlHrzThZ8I5e30avKR42VfejUUHe6QcgzRZkLiOLRd6a0XFf2Day8DO6OKug == X-Google-Smtp-Source: AGHT+IGw7+jxdzXP+huf5642luHXLRzq+MwMofGZZShRTzUMAQS1DMF34Iac+Jy6wEmttZJBwA8y0DaQ6alBNT92jQI= X-Received: by 2002:a05:6402:51cf:b0:5dc:796f:fc86 with SMTP id 4fb4d7f45d1cf-5deadd9d31cmr1292024a12.16.1739304432215; Tue, 11 Feb 2025 12:07:12 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 11 Feb 2025 12:07:11 -0800 From: Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <ier7c5w466p.fsf@HIDDEN> References: <iercyigfmq8.fsf@HIDDEN> <jwvo71yk7s6.fsf-monnier+emacs@HIDDEN> <iera5dif69e.fsf@HIDDEN> <87r056ijui.fsf@HIDDEN> <8734gka5h9.fsf@HIDDEN> <86lducwl51.fsf@HIDDEN> <ier7c5w466p.fsf@HIDDEN> MIME-Version: 1.0 Date: Tue, 11 Feb 2025 12:07:11 -0800 X-Gm-Features: AWEUYZm-Phu35B94udX7DEZ0LSpUloMPI6ZG7-OuWx49l22pJmlOsFh1u2WlCnQ Message-ID: <CADwFkmnafYZuqJVyNdkQd8ODD15i56EvO4BOEEndEpp642VT1w@HIDDEN> Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* To: Spencer Baugh <sbaugh@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74561 Cc: sbaugh@HIDDEN, juri@HIDDEN, dmitry@HIDDEN, joaotavora@HIDDEN, 74561 <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: -1.0 (-) Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> writes: > Nope, no user-facing behavior changes. In fact, this probably shouldn't > be user-customizable at all, since it's an internal optimization with > essentially no cost. So I've changed this into a defvar > completions--insert-lazily. SGTM, but I have a question: What happens on very large displays? Is 200 always going to be enough completions? I imagine some users will be doing unusual things like having the completion buffer take up their whole 42" 5K monitor. So should this perhaps be calculated dynamically based on the geometry of the window, somehow?
bug-gnu-emacs@HIDDEN:bug#74561; Package emacs.
Full text available.
Received: (at 74561) by debbugs.gnu.org; 11 Feb 2025 19:44:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 11 14:44:55 2025
Received: from localhost ([127.0.0.1]:58821 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1thwBi-0007oE-FU
for submit <at> debbugs.gnu.org; Tue, 11 Feb 2025 14:44:55 -0500
Received: from mxout5.mail.janestreet.com ([64.215.233.18]:49241)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>)
id 1thwBf-0007ny-VY
for 74561 <at> debbugs.gnu.org; Tue, 11 Feb 2025 14:44:53 -0500
From: Spencer Baugh <sbaugh@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions*
In-Reply-To: <86lducwl51.fsf@HIDDEN> (Eli Zaretskii's message of "Tue, 11 Feb
2025 17:34:18 +0200")
References: <iercyigfmq8.fsf@HIDDEN>
<jwvo71yk7s6.fsf-monnier+emacs@HIDDEN>
<iera5dif69e.fsf@HIDDEN> <87r056ijui.fsf@HIDDEN>
<8734gka5h9.fsf@HIDDEN> <86lducwl51.fsf@HIDDEN>
Date: Tue, 11 Feb 2025 14:44:46 -0500
Message-ID: <ier7c5w466p.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com;
s=waixah; t=1739303086;
bh=yDZny+sOJPjXLWxmpZT6d9JNgVpJc/t3P7RkOyVBz3M=;
h=From:To:Cc:Subject:In-Reply-To:References:Date;
b=N/g6tKljOE4fZ1rWk8KUXf1lDstcraYIT9STtFkdqIs9SULhKtvKSvdKj03bZDsbO
ru3pdr2ajAl/wrx2/ybLdk3FFbKJ6qWXrT4HmI1s+9tGP8misRjq9ze53ADAsvh41U
A4KZT0qogYVNa0OG+GpuiHPqE/Wq7+lbxzHA72y5XXCChidRQkiLHv4ENP1qG8vGB2
TDu5UiaxfJOKUgV0m9oY73FKa8+4wndxBNP01ESAMkwHgVgQZIkuZn35yyJvQeRf2W
RHaDs/wP6l7EQE3kUatidPHFRBgLGTq5rbSbmPBnwd/M/R4LJ3l28/93QaRm5nEVkB
uQW9ifXzFU1Og==
X-Spam-Score: -1.6 (-)
X-Debbugs-Envelope-To: 74561
Cc: sbaugh@HIDDEN, juri@HIDDEN, dmitry@HIDDEN, joaotavora@HIDDEN,
74561 <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: -2.6 (--)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Eli Zaretskii <eliz@HIDDEN> writes:
>> Cc: Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN>,
>> dmitry@HIDDEN, 74561 <at> debbugs.gnu.org,
>> Stefan Monnier <monnier@HIDDEN>, juri@HIDDEN
>> From: sbaugh@HIDDEN
>> Date: Tue, 11 Feb 2025 15:03:31 +0000 (UTC)
>>=20
>> +(defcustom completions-insert-lazily 200
>> + "If non-nil, completions are inserted lazily.
>
> Does the default value mean a change in user-facing behavior of
> completion commands?
Nope, no user-facing behavior changes. In fact, this probably shouldn't
be user-customizable at all, since it's an internal optimization with
essentially no cost. So I've changed this into a defvar
completions--insert-lazily.
>> +When a number, only that many completions are inserted, and the
>
> Please use "If", not "When". The latter could be misinterpreted as
> meaning some time-related condition, which is not what you mean here.
Done.
> Also, what about the :version tag?
No longer a defcustom.
> And this user option needs a NEWS entry.
Added a NEWS entry for the change in general.
Updated patch:
--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
filename=0001-Lazily-highlight-and-insert-candidates-in-Completion.patch
From fd4ca55084fa24998c09cabbb6e7dd2a88164abd Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@HIDDEN>
Date: Mon, 13 Jan 2025 14:32:18 -0500
Subject: [PATCH] Lazily highlight and insert candidates in *Completions*
From profiling, the main bottleneck in completion over large
completion sets is display-completion-list, when there are many
available candidates. For example, in my large monorepo, when
completing over the 589196 files or the 73897 branches, even
with the candidates narrowed down by typing some prefix to
complete, TAB (when it shows *Completions*) or ? is slow, mostly
in display-completion-list.
However, rendering all the completion candidates is unnecessary if
the *Completions* window is never scrolled to see those candiates. By
eagerly inserting only some candidates and lazily highlighting and
inserting the remaining candidates only when necessary, performance is
much improved.
* lisp/minibuffer.el (completion--insert-strings): Insert completions
lazily. (bug#74561)
(completion--lazy-insert-strings)
(completions--insert-lazily)
(completions--lazy-insert-button) Add.
(minibuffer-completion-help): Set completion-lazy-hilit.
(with-minibuffer-completions-window): Call
completion--lazy-insert-strings.
* lisp/simple.el (completion-setup-function): Preserve
buffer-locals required for lazy completion insertion.
(switch-to-completions): Call
completion--lazy-insert-strings.
---
etc/NEWS | 10 ++++++++++
lisp/minibuffer.el | 47 ++++++++++++++++++++++++++++++++++++++++++++--
lisp/simple.el | 5 ++++-
3 files changed, 59 insertions(+), 3 deletions(-)
diff --git a/etc/NEWS b/etc/NEWS
index 9fe46d818bd..61a6d9a3319 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -176,6 +176,16 @@ will still be on that candidate after "*Completions*" is updated with a
new list of completions. The candidate is automatically deselected when
the "*Completions*" buffer is hidden.
+---
+*** "*Completions*" is displayed faster with many completion candidates.
+The "*Completions*" buffer is now created and displayed faster when it
+contains many completion candidates. When intially created and
+displayed in a window, only enough completion candidates are inserted
+into the "*Completions*" buffer to fill the window. The remaining
+completion candidates are inserted automatically if you run a command
+which interacts with "*Completions*" buffer, such as
+'switch-to-completions'.
+
** Windows
+++
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index b401e4a920c..d08874f1cbb 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2230,6 +2230,14 @@ completions-header-format
(string :tag "Format string for heading line"))
:version "29.1")
+(defvar completions--insert-lazily 200
+ "If non-nil, completions are inserted lazily.
+
+Only this many completions are inserted, and the rest are inserted
+lazily by `completion--lazy-insert-strings'.")
+
+(defvar-local completions--lazy-insert-button nil)
+
(defun completion--insert-strings (strings &optional group-fun)
"Insert a list of STRINGS into the current buffer.
The candidate strings are inserted into the buffer depending on the
@@ -2257,8 +2265,41 @@ completion--insert-strings
;; Align to tab positions for the case
;; 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))))
+ (let ((truncated-strings
+ (and completions--insert-lazily
+ (< completions--insert-lazily (length strings))
+ (take completions--insert-lazily strings)))
+ (start (point)))
+ (funcall (intern (format "completion--insert-%s" completions-format))
+ (mapcar (lambda (candidate)
+ (if (consp candidate)
+ (setcar candidate (completion-lazy-hilit (car candidate)))
+ (completion-lazy-hilit candidate)))
+ (or truncated-strings strings))
+ group-fun length wwidth colwidth columns)
+ (when truncated-strings
+ (newline)
+ (setq-local completions--lazy-insert-button
+ (insert-button "[Completions truncated, click here to insert the rest.]"
+ 'action #'completion--lazy-insert-strings))
+ (button-put completions--lazy-insert-button 'group-fun group-fun)
+ (button-put completions--lazy-insert-button 'completions-start (copy-marker start))
+ (button-put completions--lazy-insert-button 'completion-strings strings))))))
+
+(defun completion--lazy-insert-strings (&optional button)
+ (setq button (or button completions--lazy-insert-button))
+ (when button
+ (let ((completions--insert-lazily nil)
+ (completion-lazy-hilit t)
+ (standard-output (current-buffer))
+ (inhibit-read-only t)
+ (group-fun (button-get button 'group-fun))
+ (strings (button-get button 'completion-strings)))
+ (save-excursion
+ (goto-char (button-get button 'completions-start))
+ (delete-region (point) (button-end button))
+ (setq-local completions--lazy-insert-button nil)
+ (completion--insert-strings strings group-fun)))))
(defun completion--insert-horizontal (strings group-fun
length wwidth
@@ -2644,6 +2685,7 @@ minibuffer-completion-help
(end (or end (point-max)))
(string (buffer-substring start end))
(md (completion--field-metadata start))
+ (completion-lazy-hilit completions--insert-lazily)
(completions (completion-all-completions
string
minibuffer-completion-table
@@ -4986,6 +5028,7 @@ with-minibuffer-completions-window
(get-buffer-window "*Completions*" 0)))))
(when window
(with-selected-window window
+ (completion--lazy-insert-strings)
,@body))))
(defcustom minibuffer-completion-auto-choose t
diff --git a/lisp/simple.el b/lisp/simple.el
index e1c0dd4a092..57553343c04 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -10455,10 +10455,12 @@ completion-setup-function
(buffer-substring (minibuffer-prompt-end) (point)))))))
(with-current-buffer standard-output
(let ((base-position completion-base-position)
- (insert-fun completion-list-insert-choice-function))
+ (insert-fun completion-list-insert-choice-function)
+ (lazy-button completion--lazy-insert-button))
(completion-list-mode)
(when completions-highlight-face
(setq-local cursor-face-highlight-nonselected-window t))
+ (setq-local completion--lazy-insert-button lazy-button)
(setq-local completion-base-position base-position)
(setq-local completion-list-insert-choice-function insert-fun))
(setq-local completion-reference-buffer mainbuf)
@@ -10504,6 +10506,7 @@ switch-to-completions
(progn (minibuffer-completion-help)
(get-buffer-window "*Completions*" 0)))))
(select-window window)
+ (completion--lazy-insert-strings)
(when (bobp)
(cond
((and (memq this-command '(completion-at-point minibuffer-complete))
--
2.39.3
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#74561; Package emacs.
Full text available.Received: (at 74561) by debbugs.gnu.org; 11 Feb 2025 15:34:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 11 10:34:37 2025 Received: from localhost ([127.0.0.1]:58102 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1thsHV-0006kY-16 for submit <at> debbugs.gnu.org; Tue, 11 Feb 2025 10:34:37 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:56662) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1thsHQ-0006kG-M1 for 74561 <at> debbugs.gnu.org; Tue, 11 Feb 2025 10:34:35 -0500 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 1thsHJ-0005Am-Oc; Tue, 11 Feb 2025 10:34:25 -0500 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=Az9FKCPMT4SeZofPazDefZ44sSR9ZpA6zMOnzUc5hwY=; b=kSor/ovfmRdy+kgnHKfe 3FwiRIsZEqauYi5vZhPw6EiseTYn5A0lD6xX4ydd5aUv9ABtrxVGD2OnWq7SOKrJ66/LknRibzIb1 cCr61eM9UflfByH23S9dCbsauEGriO1M7OixpM+NT8h1YfqCKhg5myv6v9m9TjZxldJu2GWKU0WGE WL6eUqVOrZmPOa9DdVw/S3IdA822dLPKcuXmQSHp48uD0G9mjfSGsgfBanaoY0HJcNEtMy8dAlSBg 5XCmKcFyl05736eqW77eMIsFhKGihtQ7+C0XdXeFWvdZLkNKKaXzdIEwRTMq3vOrWEh6Jdue6taLb dtl9w1o3R82gQw==; Date: Tue, 11 Feb 2025 17:34:18 +0200 Message-Id: <86lducwl51.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: sbaugh@HIDDEN In-Reply-To: <8734gka5h9.fsf@HIDDEN> (sbaugh@HIDDEN) Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* References: <iercyigfmq8.fsf@HIDDEN> <jwvo71yk7s6.fsf-monnier+emacs@HIDDEN> <iera5dif69e.fsf@HIDDEN> <87r056ijui.fsf@HIDDEN> <8734gka5h9.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 74561 Cc: sbaugh@HIDDEN, juri@HIDDEN, dmitry@HIDDEN, joaotavora@HIDDEN, 74561 <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: -2.6 (--) > Cc: João Távora <joaotavora@HIDDEN>, > dmitry@HIDDEN, 74561 <at> debbugs.gnu.org, > Stefan Monnier <monnier@HIDDEN>, juri@HIDDEN > From: sbaugh@HIDDEN > Date: Tue, 11 Feb 2025 15:03:31 +0000 (UTC) > > +(defcustom completions-insert-lazily 200 > + "If non-nil, completions are inserted lazily. Does the default value mean a change in user-facing behavior of completion commands? > +When a number, only that many completions are inserted, and the Please use "If", not "When". The latter could be misinterpreted as meaning some time-related condition, which is not what you mean here. Also, what about the :version tag? And this user option needs a NEWS entry. Thanks.
bug-gnu-emacs@HIDDEN:bug#74561; Package emacs.
Full text available.
Received: (at 74561) by debbugs.gnu.org; 11 Feb 2025 15:03:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 11 10:03:42 2025
Received: from localhost ([127.0.0.1]:58004 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1thrnZ-0005B6-Nn
for submit <at> debbugs.gnu.org; Tue, 11 Feb 2025 10:03:42 -0500
Received: from s.wrqvtzvf.outbound-mail.sendgrid.net ([149.72.126.143]:16500)
by debbugs.gnu.org with esmtps
(TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2)
(envelope-from
<bounces+21787432-4621-74561=debbugs.gnu.org@HIDDEN>)
id 1thrnV-0005An-Qk
for 74561 <at> debbugs.gnu.org; Tue, 11 Feb 2025 10:03:39 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com;
h=from:subject:in-reply-to:references:mime-version:to:cc:content-type:
cc:content-type:from:subject:to;
s=s1; bh=SY7bVK6HFn9C7tfX1oEEIQtayeVgiavYj2aOPjYsYR8=;
b=ec2Nyvyz9Mv+HPpwmT6KsEhG8G6NKozc2/OBEJPliXm+t440dlch3J2x78PGIb16XSIm
azsK5lS8xBs73SEW2/jkDQu2+h7s7DhZX7ACCGW/xfnUvOsOqeR7E05gc484A1uxdlY0Ww
Tp9nHXUMprLtaW1YJI9EhyuqZtBuo6ri9V4h2bUAGeALAhNlCJMozZXnfnRTgrskUN04MB
g9KPppX8IAM90pdfxWkDmuTj3YGP1knGddUewaqy7gs5/W+wWEYs50459d1UIVl6ouHLwG
/cOogRUcicWuF7+f9OZgT3qABlva9cc1TgIKGc8U7LhOJwFlE7L9rQ8VEP7+OoeQ==
Received: by recvd-5f54b5d587-cddpk with SMTP id
recvd-5f54b5d587-cddpk-1-67AB66C3-17
2025-02-11 15:03:31.200072701 +0000 UTC m=+7666838.701353130
Received: from earth.catern.com (unknown) by geopod-ismtpd-3 (SG) with ESMTP
id TNG7V2M6RWCUjhWz9b9xQw Tue, 11 Feb 2025 15:03:30.981 +0000 (UTC)
X-Comment: SPF check N/A for local connections - client-ip=127.0.0.1;
helo=localhost; envelope-from=sbaugh@HIDDEN; receiver=janestreet.com
Received: from localhost (localhost [127.0.0.1])
by earth.catern.com (Postfix) with ESMTPSA id 5B37B60142;
Tue, 11 Feb 2025 10:03:30 -0500 (EST)
From: sbaugh@HIDDEN
Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions*
In-Reply-To: <87r056ijui.fsf@HIDDEN> (sbaugh@HIDDEN's message of "Mon,
13 Jan 2025 19:39:50 +0000 (UTC)")
References: <iercyigfmq8.fsf@HIDDEN>
<jwvo71yk7s6.fsf-monnier+emacs@HIDDEN>
<iera5dif69e.fsf@HIDDEN> <87r056ijui.fsf@HIDDEN>
Date: Tue, 11 Feb 2025 15:03:31 +0000 (UTC)
Message-ID: <8734gka5h9.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
X-SG-EID: =?us-ascii?Q?u001=2Ev6RTqHFpv1T6krEot6UFAVAJmQ+4h1t8=2FTfqqE2B07ORFH2fPQmmCvFjz?=
=?us-ascii?Q?zKblTkxOtk1A6MJoeZDZzXmoVx9orTx+4K9=2FD8P?=
=?us-ascii?Q?Fx6CealLffSXvAIHJMSd21+y4gE9y7lKN8B2Ey3?=
=?us-ascii?Q?FQWBboeUA37LqM3iMSmSx6O7EEPcAcGggbvoTeD?=
=?us-ascii?Q?yD8DcvHPnvKZMd721hRrLO=2FnSX5+CAFc3Ff7KYi?=
=?us-ascii?Q?w=3D=3D?=
To: Spencer Baugh <sbaugh@HIDDEN>
X-Entity-ID: u001.oW4JupFKOzCccZAQN2OOFQ==
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 74561
Cc: =?iso-8859-1?b?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>, dmitry@HIDDEN,
74561 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>,
juri@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=us-ascii
Content-Transfer-Encoding: 7bit
Improved the patch further on feedback from Stefan. It now also uses
completion-lazy-hilit, which further improves performance.
I'm not sure if completion-lazy-hilit-fn needs to be saved and restored
(like group-fun is being saved and restored). The current version of
this patch doesn't save completion-lazy-hilit-fn, and that seems to work
fine, because completion-lazy-hilit-fn hasn't changed by the time we
call completion--lazy-insert-strings. But maybe this is not robust in
some case?
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline;
filename=0001-Lazily-highlight-and-insert-candidates-in-Completion.patch
From 454ce335856c6ab550447f7ed1d79dbb67d6f3ef Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@HIDDEN>
Date: Mon, 13 Jan 2025 14:32:18 -0500
Subject: [PATCH] Lazily highlight and insert candidates in *Completions*
From profiling, the main bottleneck in completion over large
completion sets is display-completion-list, when there are many
available candidates. For example, in my large monorepo, when
completing over the 589196 files or the 73897 branches, even
with the candidates narrowed down by typing some prefix to
complete, TAB (when it shows *Completions*) or ? is slow, mostly
in display-completion-list.
However, rendering all the completion candidates is unnecessary if
the *Completions* window is never scrolled to see those candiates. By
eagerly inserting only some candidates and lazily highlighting and
inserting the remaining candidates only when necessary, performance is
much improved.
* lisp/minibuffer.el (completions-insert-lazily): Add defcustom
for inserting completions lazily. (bug#74561)
(completion--lazy-insert-completions)
(completion--lazy-insert-group-fun)
(completion--lazy-insert-start, completion--lazy-insert-end):
Add.
(completion--insert-strings): Check completions-insert-lazily.
(minibuffer-completion-help): Set completion-lazy-hilit.
(completion--lazy-insert-strings): Add.
(with-minibuffer-completions-window): Call
completion--lazy-insert-strings.
* lisp/simple.el (completion-setup-function): Preserve
buffer-locals required for lazy completion insertion.
(switch-to-completions): Call
completion--lazy-insert-strings.
---
lisp/minibuffer.el | 49 ++++++++++++++++++++++++++++++++++++++++++++--
lisp/simple.el | 5 ++++-
2 files changed, 51 insertions(+), 3 deletions(-)
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 1f33bda5f65..9dca6bb2d15 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2230,6 +2230,16 @@ completions-header-format
(string :tag "Format string for heading line"))
:version "29.1")
+(defcustom completions-insert-lazily 200
+ "If non-nil, completions are inserted lazily.
+
+When a number, only that many completions are inserted, and the
+rest are inserted lazily."
+ :type '(choice (const :tag "Render all completions immediately" nil)
+ (integer :tag "Only render this many completions")))
+
+(defvar-local completion--lazy-insert-button nil)
+
(defun completion--insert-strings (strings &optional group-fun)
"Insert a list of STRINGS into the current buffer.
The candidate strings are inserted into the buffer depending on the
@@ -2257,8 +2267,41 @@ completion--insert-strings
;; Align to tab positions for the case
;; 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))))
+ (let ((truncated-strings
+ (and completions-insert-lazily
+ (< completions-insert-lazily (length strings))
+ (take completions-insert-lazily strings)))
+ (start (point)))
+ (funcall (intern (format "completion--insert-%s" completions-format))
+ (mapcar (lambda (candidate)
+ (if (consp candidate)
+ (setcar candidate (completion-lazy-hilit (car candidate)))
+ (completion-lazy-hilit candidate)))
+ (or truncated-strings strings))
+ group-fun length wwidth colwidth columns)
+ (when truncated-strings
+ (newline)
+ (setq-local completion--lazy-insert-button
+ (insert-button "[Completions truncated, click here to insert the rest.]"
+ 'action #'completion--lazy-insert-strings))
+ (button-put completion--lazy-insert-button 'group-fun group-fun)
+ (button-put completion--lazy-insert-button 'completions-start (copy-marker start))
+ (button-put completion--lazy-insert-button 'completion-strings strings))))))
+
+(defun completion--lazy-insert-strings (&optional button)
+ (setq button (or button completion--lazy-insert-button))
+ (when button
+ (let ((completions-insert-lazily nil)
+ (completion-lazy-hilit t)
+ (standard-output (current-buffer))
+ (inhibit-read-only t)
+ (group-fun (button-get button 'group-fun))
+ (strings (button-get button 'completion-strings)))
+ (save-excursion
+ (goto-char (button-get button 'completions-start))
+ (delete-region (point) (button-end button))
+ (setq-local completion--lazy-insert-button nil)
+ (completion--insert-strings strings group-fun)))))
(defun completion--insert-horizontal (strings group-fun
length wwidth
@@ -2620,6 +2663,7 @@ minibuffer-completion-help
(end (or end (point-max)))
(string (buffer-substring start end))
(md (completion--field-metadata start))
+ (completion-lazy-hilit completions-insert-lazily)
(completions (completion-all-completions
string
minibuffer-completion-table
@@ -4962,6 +5006,7 @@ with-minibuffer-completions-window
(get-buffer-window "*Completions*" 0)))))
(when window
(with-selected-window window
+ (completion--lazy-insert-strings)
,@body))))
(defcustom minibuffer-completion-auto-choose t
diff --git a/lisp/simple.el b/lisp/simple.el
index e1c0dd4a092..57553343c04 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -10455,10 +10455,12 @@ completion-setup-function
(buffer-substring (minibuffer-prompt-end) (point)))))))
(with-current-buffer standard-output
(let ((base-position completion-base-position)
- (insert-fun completion-list-insert-choice-function))
+ (insert-fun completion-list-insert-choice-function)
+ (lazy-button completion--lazy-insert-button))
(completion-list-mode)
(when completions-highlight-face
(setq-local cursor-face-highlight-nonselected-window t))
+ (setq-local completion--lazy-insert-button lazy-button)
(setq-local completion-base-position base-position)
(setq-local completion-list-insert-choice-function insert-fun))
(setq-local completion-reference-buffer mainbuf)
@@ -10504,6 +10506,7 @@ switch-to-completions
(progn (minibuffer-completion-help)
(get-buffer-window "*Completions*" 0)))))
(select-window window)
+ (completion--lazy-insert-strings)
(when (bobp)
(cond
((and (memq this-command '(completion-at-point minibuffer-complete))
--
2.44.0
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#74561; Package emacs.
Full text available.
Received: (at 74561) by debbugs.gnu.org; 13 Jan 2025 19:40:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 13 14:40:02 2025
Received: from localhost ([127.0.0.1]:52921 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tXQI5-0007H3-CX
for submit <at> debbugs.gnu.org; Mon, 13 Jan 2025 14:40:02 -0500
Received: from s.wfbtzhsw.outbound-mail.sendgrid.net ([159.183.224.105]:4090)
by debbugs.gnu.org with esmtps
(TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2)
(envelope-from
<bounces+21787432-4621-74561=debbugs.gnu.org@HIDDEN>)
id 1tXQI1-0007Gn-Vf
for 74561 <at> debbugs.gnu.org; Mon, 13 Jan 2025 14:39:59 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com;
h=from:subject:in-reply-to:references:mime-version:to:cc:content-type:
cc:content-type:from:subject:to;
s=s1; bh=dyDoaOnzcyV6dchwfRdHRQ26gQASFycCKtDar0KtV38=;
b=zQ28E2zA2J0ZbfwHxyZcjCyP80Csyc+WZaZhTmc/dvpCMwWNKFmvDygx55aYybAiuXWE
IF7CQDY8EMkvwTgwSMN4u8izyVDwmDypxrd1OoWV040FQluvIKBE5+XTjPFWQPNo8BHDc6
uBj0eUIosNABXIYRvWGfpt2twFYAm1o8iewBWwKv5B/jj2mZHsBf9tFeorJJze3DBo/GMU
GIqtXBQOz2VmVaYNAaNbgfy3m9RWEfVq/PyD8OarTIG8pW9jPI1k9bIDR9GFDS+Oyj77gL
XcFfIPLPf+mxzlNv2vhE2EzIQj16laqJpoZjVCw091pLvspbt9GGE0FLPLgSgqCQ==
Received: by recvd-5f9ffdf494-trckm with SMTP id
recvd-5f9ffdf494-trckm-1-67856C06-8
2025-01-13 19:39:50.419678783 +0000 UTC m=+5178042.141330583
Received: from earth.catern.com (unknown) by geopod-ismtpd-30 (SG) with ESMTP
id unhZPEwrSbSdEVmFHWZFBA Mon, 13 Jan 2025 19:39:50.302 +0000 (UTC)
X-Comment: SPF check N/A for local connections - client-ip=127.0.0.1;
helo=localhost; envelope-from=sbaugh@HIDDEN; receiver=janestreet.com
Received: from localhost (localhost [127.0.0.1])
by earth.catern.com (Postfix) with ESMTPSA id C9D5E62524;
Mon, 13 Jan 2025 14:39:49 -0500 (EST)
From: sbaugh@HIDDEN
Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions*
In-Reply-To: <iera5dif69e.fsf@HIDDEN> (Spencer Baugh's message of
"Fri, 29 Nov 2024 09:45:33 -0500")
References: <iercyigfmq8.fsf@HIDDEN>
<jwvo71yk7s6.fsf-monnier+emacs@HIDDEN>
<iera5dif69e.fsf@HIDDEN>
Date: Mon, 13 Jan 2025 19:39:50 +0000 (UTC)
Message-ID: <87r056ijui.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
X-SG-EID: =?us-ascii?Q?u001=2Ev6RTqHFpv1T6krEot6UFAVAJmQ+4h1t8=2FTfqqE2B07P5ncIyt5NhLAOOv?=
=?us-ascii?Q?WsTVL4lS18bdsc3CKu37Yumunh+z0xBqCdxpXb5?=
=?us-ascii?Q?7=2FaxMFN3ucb0Lwp1Wnblhx8p8d4wDlhFi+GuWhS?=
=?us-ascii?Q?seTVbF4JB9ExTtqBrVe6RfwXaaBueiU0AHxjFq+?=
=?us-ascii?Q?NrtG8JQMG0Pzpqs8HNPJ92ivgyicz5b2nTI7YvW?=
=?us-ascii?Q?A=3D=3D?=
To: Spencer Baugh <sbaugh@HIDDEN>
X-Entity-ID: u001.oW4JupFKOzCccZAQN2OOFQ==
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 74561
Cc: dmitry@HIDDEN, 74561 <at> debbugs.gnu.org,
Stefan Monnier <monnier@HIDDEN>, juri@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=us-ascii
Content-Transfer-Encoding: 7bit
Spencer Baugh <sbaugh@HIDDEN> writes:
> Stefan Monnier <monnier@HIDDEN> writes:
>> I think we should try and fill the buffer lazily. We don't have much
>> experience with "jit" populating a buffer (the closest I can think of is
>> the `vlf` package, which doesn't do "jit", IIRC), so it may take some
>> trial-and-error until we have something that works, but it
>> seems worthwhile.
>
> Yes, I think filling the *Completions* buffer lazily would be way better
> than limiting the size of the buffer, thanks everyone for your comments.
>
> I think it would be sufficient to do something simple, and just split
> filling the *Completions* buffer into two parts:
>
> - In minibuffer-completion-help, insert only enough completion
> candidates that the part of the *Completions* buffer that's displayed in
> a window initially looks normal. Save the rest of the completions in a
> buffer-local in *Completions*.
>
> - Upon any kind of interaction with the *Completions* buffer, insert all
> the rest of the completion candidates in completions--finish-populate.
>
> We could be lazier than this, but this is probably sufficient to give a
> big speedup, since I think *Completions* is rendered much more often
> than it's interacted with.
>
> So to do this, all we need is a way to do completions--finish-populate
> at the right time.
>
> I'm not sure when to do that. Maybe we could just call it in
> window-selection-change-functions and with-minibuffer-completions-window
> and maybe a few other places?
I've done this in the attached patch and it seems to work well. As a
fallback, there's also a button at the end of the *Completions* buffer
to finish filling it, in case something goes wrong with the automatic
laziness.
Incidentally, filling the buffer lazily allows the default completion
frontend to start using completion-lazy-hilit, which will be another
nice performance benefit (which can happen in a later follow-up patch).
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline;
filename=0001-Lazily-insert-candidates-in-Completions.patch
From d0ff52fbe81b4eea0bc319c14df269d90cfba4d2 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@HIDDEN>
Date: Mon, 13 Jan 2025 14:32:18 -0500
Subject: [PATCH] Lazily insert candidates in *Completions*
From profiling, the main bottleneck in completion over large
completion sets is display-completion-list, when there are many
available candidates. For example, in my large monorepo, when
completing over the 589196 files or the 73897 branches, even
with the candidates narrowed down by typing some prefix to
complete, TAB (when it shows *Completions*) or ? is slow, mostly
in display-completion-list.
However, rendering all the completion candidates is unnecessary
if the *Completions* window is never scrolled to see those
candiates. By eagerly inserting only some candidates and lazily
inserting the remaining only when necessary, performance is much
improved.
* lisp/minibuffer.el (completions-insert-lazily): Add defcustom
for inserting completions lazily. (bug#74561)
(completion--lazy-insert-completions)
(completion--lazy-insert-group-fun)
(completion--lazy-insert-start, completion--lazy-insert-end):
Add.
(completion--insert-strings): Check completions-insert-lazily.
(completion--lazy-display-completion-list): Add.
(with-minibuffer-completions-window): Call
completion--lazy-display-completion-list.
* lisp/simple.el (completion-setup-function): Preserve
buffer-locals required for lazy completion insertion.
(switch-to-completions): Call
completion--lazy-display-completion-list.
---
lisp/minibuffer.el | 42 ++++++++++++++++++++++++++++++++++++++++--
lisp/simple.el | 11 ++++++++++-
2 files changed, 50 insertions(+), 3 deletions(-)
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 1f33bda5f65..dc6999c7532 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2230,6 +2230,19 @@ completions-header-format
(string :tag "Format string for heading line"))
:version "29.1")
+(defcustom completions-insert-lazily 200
+ "If non-nil, completions are inserted lazily.
+
+When a number, only that many completions are inserted, and the
+rest are inserted lazily."
+ :type '(choice (const :tag "Render all completions immediately" nil)
+ (integer :tag "Only render this many completions")))
+
+(defvar-local completion--lazy-insert-completions nil)
+(defvar-local completion--lazy-insert-group-fun nil)
+(defvar-local completion--lazy-insert-start nil)
+(defvar-local completion--lazy-insert-end nil)
+
(defun completion--insert-strings (strings &optional group-fun)
"Insert a list of STRINGS into the current buffer.
The candidate strings are inserted into the buffer depending on the
@@ -2251,14 +2264,26 @@ completion--insert-strings
;; Don't allocate more columns than we can fill.
;; Windows can't show less than 3 lines anyway.
(max 1 (/ (length strings) 2))))
- (colwidth (/ wwidth columns)))
+ (colwidth (/ wwidth columns))
+ is-truncated)
(unless (or tab-stop-list (null completion-tab-width)
(zerop (mod colwidth completion-tab-width)))
;; Align to tab positions for the case
;; when the caller uses tabs inside prefix.
(setq colwidth (- colwidth (mod colwidth completion-tab-width))))
+ (when (and completions-insert-lazily (< completions-insert-lazily (length strings)))
+ (setq is-truncated t)
+ (setq-local completion--lazy-insert-completions strings)
+ (setq-local completion--lazy-insert-group-fun group-fun)
+ (setq-local completion--lazy-insert-start (point-marker))
+ (setq strings (take completions-insert-lazily strings)))
(funcall (intern (format "completion--insert-%s" completions-format))
- strings group-fun length wwidth colwidth columns))))
+ strings group-fun length wwidth colwidth columns)
+ (when is-truncated
+ (newline)
+ (insert-button "[Completions truncated, click here to insert the rest.]"
+ 'action #'completion--lazy-display-completion-list)
+ (setq-local completion--lazy-insert-end (point-marker))))))
(defun completion--insert-horizontal (strings group-fun
length wwidth
@@ -2507,6 +2532,18 @@ display-completion-list
(run-hooks 'completion-setup-hook)
nil)
+(defun completion--lazy-display-completion-list (&optional _button)
+ (when completion--lazy-insert-completions
+ (let ((completions-insert-lazily nil)
+ (standard-output (current-buffer))
+ (inhibit-read-only t))
+ (delete-region completion--lazy-insert-start completion--lazy-insert-end)
+ (save-excursion
+ (goto-char completion--lazy-insert-start)
+ (completion--insert-strings
+ completion--lazy-insert-completions completion--lazy-insert-group-fun)
+ (setq-local completion--lazy-insert-completions nil)))))
+
(defvar completion-extra-properties nil
"Property list of extra properties of the current completion job.
These include:
@@ -4962,6 +4999,7 @@ with-minibuffer-completions-window
(get-buffer-window "*Completions*" 0)))))
(when window
(with-selected-window window
+ (completion--lazy-display-completion-list)
,@body))))
(defcustom minibuffer-completion-auto-choose t
diff --git a/lisp/simple.el b/lisp/simple.el
index c47ea8660f9..44221ba1bed 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -10455,10 +10455,18 @@ completion-setup-function
(buffer-substring (minibuffer-prompt-end) (point)))))))
(with-current-buffer standard-output
(let ((base-position completion-base-position)
- (insert-fun completion-list-insert-choice-function))
+ (insert-fun completion-list-insert-choice-function)
+ (lazy-completions completion--lazy-insert-completions)
+ (lazy-group-fun completion--lazy-insert-group-fun)
+ (lazy-start completion--lazy-insert-start)
+ (lazy-end completion--lazy-insert-end))
(completion-list-mode)
(when completions-highlight-face
(setq-local cursor-face-highlight-nonselected-window t))
+ (setq-local completion--lazy-insert-completions lazy-completions)
+ (setq-local completion--lazy-insert-group-fun lazy-group-fun)
+ (setq-local completion--lazy-insert-start lazy-start)
+ (setq-local completion--lazy-insert-end lazy-end)
(setq-local completion-base-position base-position)
(setq-local completion-list-insert-choice-function insert-fun))
(setq-local completion-reference-buffer mainbuf)
@@ -10504,6 +10512,7 @@ switch-to-completions
(progn (minibuffer-completion-help)
(get-buffer-window "*Completions*" 0)))))
(select-window window)
+ (completion--lazy-display-completion-list)
(when (bobp)
(cond
((and (memq this-command '(completion-at-point minibuffer-complete))
--
2.44.0
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#74561; Package emacs.
Full text available.Stefan Kangas <stefankangas@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 74561) by debbugs.gnu.org; 30 Nov 2024 17:17:27 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 30 12:17:27 2024 Received: from localhost ([127.0.0.1]:48867 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tHR5z-0005i6-9f for submit <at> debbugs.gnu.org; Sat, 30 Nov 2024 12:17:27 -0500 Received: from fhigh-b3-smtp.messagingengine.com ([202.12.124.154]:58177) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1tHR5w-0005hp-7F for 74561 <at> debbugs.gnu.org; Sat, 30 Nov 2024 12:17:25 -0500 Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfhigh.stl.internal (Postfix) with ESMTP id B636B2540173; Sat, 30 Nov 2024 12:17:18 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-11.internal (MEProxy); Sat, 30 Nov 2024 12:17:18 -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:subject:subject:to:to; s=fm3; t=1732987038; x=1733073438; bh=R/O/FtrIBYlxeqN88XSjmliL7LCBlVsZwf0JUmGRsmQ=; b= j3mA+lY7pOPRrUrzRjrHQL0M1++ErCfsbWnan8oD+z5Bxa2MIti5mW+965hnYg5Y NUvTC1H6G5XbsJIs7pYtduHpZANOkpgfPvJwWNzvoo5Amcz+g2tsEx7Ouyzro8Rz tVMJLoScyi+cBZAtFA6/e89NAFKSufvrCM0nmHswTDEkiwxjUkBmPj1UHstmkjFD fZkNxJQnpnsaQJJnGa5RVUvESZITJyrutMCsUf71uDa4xpk35Ym2wOV3SE1Q4R6y 46K/i83kYjU211Ma/eHM3aNHYLr+Fjkj7n41m5gf8OaFoAEuwBTEBDiG26RbhHxJ sDi0FyG2Dt6B6e35Q5IKPw== 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:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1732987038; x= 1733073438; bh=R/O/FtrIBYlxeqN88XSjmliL7LCBlVsZwf0JUmGRsmQ=; b=S CDIqUqcZJOFQzd3iY5lmDG3SZ5ss8T8pT7Sft+Ht4qaN9uGO/RBT1cyyOQH7jTGp MXfkk2vQMxE88o9t+oz567P0FFU6tWdHC1vaXwVHtBl6He/Ek+GvpVA8AAfITbc7 EZLRFvLEo+84KkAnVekGwNZPGOVU9Jmyt7/q7o7SKF6/4No/le/VN5pCfz69q3lh pUr9zHRpVzWoiQf56pVGxlarINAPWkqUEqHZWItrUHj2RWsHeokRVRqGC6uM1Tyw ZnaQSM3XTC6McnjMmC97K8ptbm7sNHAnBaF4isR0yQn5W1jXquGAztiBteLbFQV3 Th1vD/0vNB0FonYnuIKzQ== X-ME-Sender: <xms:nkhLZ_n7TRnv6W50tpXpNWdkkU_9bmJaJxtHXHiEpRL3R4RNjrEQvA> <xme:nkhLZy0bGFbmiuX12-wV2yA5sOWb39JRcWd4kP6KZQpGKSXFEq5grf637_4GqWfGR uNH1IB0_SN1pN6T5pc> X-ME-Received: <xmr:nkhLZ1pYilvD2KMJnM6opRlUB3IFigOevhnuBjPVzgNPttO_ySjm0PTlnql-8gXNXNyc> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrheehgdeliecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth hsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeen ucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvg hvqeenucggtffrrghtthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedt vddtveefhfdvveegudejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohep gedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepshgsrghughhhsehjrghnvghsth hrvggvthdrtghomhdprhgtphhtthhopehmohhnnhhivghrsehirhhordhumhhonhhtrhgv rghlrdgtrgdprhgtphhtthhopeejgeehieduseguvggssghughhsrdhgnhhurdhorhhgpd hrtghpthhtohepjhhurhhisehlihhnkhhovhdrnhgvth X-ME-Proxy: <xmx:nkhLZ3nmIwkgLRp9YXXPc2cDe4mNv-zihja7gnl0c9MLhxWMhqEYvw> <xmx:nkhLZ92bKccePT_ft79k6ipbxo908nl_NZ772zKnqnLopys43VUidA> <xmx:nkhLZ2uHYgXsWMGrzFuaBhdjKXsSsfAiSNFXG4WGphD_4cdbw-Tx2w> <xmx:nkhLZxVc3-NU77K9pVtR2jaXf8DgVTVWbBAXTN0JjOFBzZsuIXLa3A> <xmx:nkhLZ4R49shuyPNQNWQsamiO6T1l-PElPkc697RRrFD0Q_9GQFDkDaS3> Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 30 Nov 2024 12:17:16 -0500 (EST) Message-ID: <ef02d7fb-1482-405f-ba39-e62781145f8f@HIDDEN> Date: Sat, 30 Nov 2024 19:17:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* To: Spencer Baugh <sbaugh@HIDDEN>, Stefan Monnier <monnier@HIDDEN> References: <iercyigfmq8.fsf@HIDDEN> <jwvo71yk7s6.fsf-monnier+emacs@HIDDEN> <iera5dif69e.fsf@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <iera5dif69e.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74561 Cc: 74561 <at> debbugs.gnu.org, juri@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 29/11/2024 16:45, Spencer Baugh wrote: >> Hmm... interesting. I expected it would be the computation of faces >> from things like `completion-pcm--hilit-commonality`. >> >> Do you happen to know which part of `display-completion-list` is the >> most costly? is it the actual insertion into the buffer? > A simple way to profile this is: > (progn > (require 'profiler) > (profiler-reset) > (profiler-cpu-start 10000) > (completing-read ":" (mapcar #'number-to-string (number-sequence 0 100000))) > (profiler-cpu-stop) > (setq profiler-cpu-log (profiler-cpu-log)) > (profiler-report-cpu)) > > The biggest individual contributors of runtime are > set/add-text-properties and insert. Buffer text properties are implemented in terms of plists, so it makes sense that they're consing and contribute to GC churn. Actually limiting the completions buffer to N completions makes a lot of sense from my POV - not in the least because it corresponds to rendering a completion popup (which only shows N lines), with similar big-O complexity. I suppose supporting full C-s searches is something of a complication, though. In Xref buffer, we do such adjustments in post-command-hook (for line truncation).
bug-gnu-emacs@HIDDEN:bug#74561; Package emacs.
Full text available.Received: (at 74561) by debbugs.gnu.org; 29 Nov 2024 14:45:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 29 09:45:52 2024 Received: from localhost ([127.0.0.1]:41740 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tH2Fj-0004BY-Pr for submit <at> debbugs.gnu.org; Fri, 29 Nov 2024 09:45:52 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:41161) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1tH2FW-0004Ax-QH for 74561 <at> debbugs.gnu.org; Fri, 29 Nov 2024 09:45:39 -0500 From: Spencer Baugh <sbaugh@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* In-Reply-To: <jwvo71yk7s6.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message of "Thu, 28 Nov 2024 23:12:59 -0500") References: <iercyigfmq8.fsf@HIDDEN> <jwvo71yk7s6.fsf-monnier+emacs@HIDDEN> Date: Fri, 29 Nov 2024 09:45:33 -0500 Message-ID: <iera5dif69e.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1732891533; bh=M7UY3hy74cfh7Ku/0Erb7oS+MfVL/xb6rluz+cMUam4=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=ZzsMipJcTvqfqxCDz47gLivqXOTFAtJy81T/z70y/N3tmhi9aPevqxSucEHP233X/ vBdBs436CpaovW4igOQYOdN4b4djjmS6qXSrxFnLhs1mCSePaP57OKAHjLNVvXRPMC LAzJdBDeTHdoSk7ZzXFy1Jal80q6xieVrGq0tuy/NvKxoZmBPFkHAf7WTbyf0Y1IMg 8qO4Gq/QZ5yCNA6DuB/LKnVUCB1SHLd37/JmR3/dT444J9/JKnCj+iUaoJjRzs+JbW pc3uBTFXLwUTPxEjVljk4hNXeGPf6/Kvgfudg5RM0lcbJb8tdpcFrXghiuN/mlXPtT QlgwyxRqwQaeQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74561 Cc: dmitry@HIDDEN, 74561 <at> debbugs.gnu.org, juri@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.7 (-) Stefan Monnier <monnier@HIDDEN> writes: >> From profiling, the main bottleneck in completion over large >> completion sets is display-completion-list, when there are many >> available candidates. > > Hmm... interesting. I expected it would be the computation of faces > from things like `completion-pcm--hilit-commonality`. > > Do you happen to know which part of `display-completion-list` is the > most costly? is it the actual insertion into the buffer? A simple way to profile this is: (progn (require 'profiler) (profiler-reset) (profiler-cpu-start 10000) (completing-read ":" (mapcar #'number-to-string (number-sequence 0 100000))) (profiler-cpu-stop) (setq profiler-cpu-log (profiler-cpu-log)) (profiler-report-cpu)) The biggest individual contributors of runtime are set/add-text-properties and insert. > I think we should try and fill the buffer lazily. We don't have much > experience with "jit" populating a buffer (the closest I can think of is > the `vlf` package, which doesn't do "jit", IIRC), so it may take some > trial-and-error until we have something that works, but it > seems worthwhile. Yes, I think filling the *Completions* buffer lazily would be way better than limiting the size of the buffer, thanks everyone for your comments. I think it would be sufficient to do something simple, and just split filling the *Completions* buffer into two parts: - In minibuffer-completion-help, insert only enough completion candidates that the part of the *Completions* buffer that's displayed in a window initially looks normal. Save the rest of the completions in a buffer-local in *Completions*. - Upon any kind of interaction with the *Completions* buffer, insert all the rest of the completion candidates in completions--finish-populate. We could be lazier than this, but this is probably sufficient to give a big speedup, since I think *Completions* is rendered much more often than it's interacted with. So to do this, all we need is a way to do completions--finish-populate at the right time. I'm not sure when to do that. Maybe we could just call it in window-selection-change-functions and with-minibuffer-completions-window and maybe a few other places?
bug-gnu-emacs@HIDDEN:bug#74561; Package emacs.
Full text available.
Received: (at 74561) by debbugs.gnu.org; 29 Nov 2024 04:13:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 28 23:13:21 2024
Received: from localhost ([127.0.0.1]:40517 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tGsNd-0005ph-H3
for submit <at> debbugs.gnu.org; Thu, 28 Nov 2024 23:13:21 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:37121)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1tGsNa-0005pQ-Ff
for 74561 <at> debbugs.gnu.org; Thu, 28 Nov 2024 23:13:19 -0500
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8B788445446;
Thu, 28 Nov 2024 23:13:11 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1732853586;
bh=P6qZVmAAh5GGIKBw+fDYm1TnWot6Wl/RNaId9Tzkg9o=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=Ab/zjklT3OmemMkQeY1n1VT+JfyPeLC3N58ytr4+C50Rf3ODYE3dCeE9derdehoJX
obnnn4Qug3Z4lS9t7VcW6qCoJpdCU5FDA1QYP+a8Swm1eud/xUmeK43hV6wUzfKdhH
ZTNq9nPWkm4ABXGyFUST6UxClhK1e+BKw7akPnE0vXOyYO2Z5d3UBQP1vlJZDPm5S4
+myPak7GQ8Uprk+2q2Hn1r/C+bCrSzP2vpZCZfR2Tm5NKgd41kLtwemC7+QvX4pIk/
0PAjLhHbIuv4L87tgmVl7nBdDhG2MtLlgr0/tSR+uuYmoH3EROpGps9UZacXb/G934
a5316b56+h9Jw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5CE9C445450;
Thu, 28 Nov 2024 23:13:06 -0500 (EST)
Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D6D8312022A;
Thu, 28 Nov 2024 23:13:05 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Spencer Baugh <sbaugh@HIDDEN>
Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions*
In-Reply-To: <iercyigfmq8.fsf@HIDDEN> (Spencer Baugh's message of
"Wed, 27 Nov 2024 15:25:19 -0500")
Message-ID: <jwvo71yk7s6.fsf-monnier+emacs@HIDDEN>
References: <iercyigfmq8.fsf@HIDDEN>
Date: Thu, 28 Nov 2024 23:12:59 -0500
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.002 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: 74561
Cc: dmitry@HIDDEN, 74561 <at> debbugs.gnu.org, juri@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 profiling, the main bottleneck in completion over large
> completion sets is display-completion-list, when there are many
> available candidates.
Hmm... interesting. I expected it would be the computation of faces
from things like `completion-pcm--hilit-commonality`.
Do you happen to know which part of `display-completion-list` is the
most costly? is it the actual insertion into the buffer?
I think we should try and fill the buffer lazily. We don't have much
experience with "jit" populating a buffer (the closest I can think of is
the `vlf` package, which doesn't do "jit", IIRC), so it may take some
trial-and-error until we have something that works, but it
seems worthwhile.
Stefan
bug-gnu-emacs@HIDDEN:bug#74561; Package emacs.
Full text available.Received: (at 74561) by debbugs.gnu.org; 29 Nov 2024 02:36:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 28 21:36:30 2024 Received: from localhost ([127.0.0.1]:40424 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tGqru-00019G-7D for submit <at> debbugs.gnu.org; Thu, 28 Nov 2024 21:36:30 -0500 Received: from mx0b-00069f02.pphosted.com ([205.220.177.32]:23170) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <drew.adams@HIDDEN>) id 1tGqrr-000194-0X for 74561 <at> debbugs.gnu.org; Thu, 28 Nov 2024 21:36:27 -0500 Received: from pps.filterd (m0246632.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4AT1fc5u013482; Fri, 29 Nov 2024 02:36:26 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= corp-2023-11-20; bh=k1NyyfPAuD/+Fm/pQ/trRmc2QwEHhx+tMUgAKnzcGVM=; b= X+AWTtRYXOnudp0Oz3yOwjoDL+6n4XT7LLP2qKWY3fvXGxNlg+5NLoUhH7d9jy32 guI63bpVzCiFG+V5uRq+GsIOoYs6Wx2x1gH/u363aNnGnNNgtbcgDJUPJNBzM+Bg Qloy9inIzaNmDxTcQEY6f8DAbzNV4HNvQ8udGf89LAk3rnO3comcEgy4wDfqDLCI BSyphIUYuc2Z4O8sGDHMMK8JLH4FNJSkb/yjwtl+0I/VvyrBB4CDmSIFx9SrQxls LEFoUYmoPlA+4pv01cT/1YULgsVa0EhssT5QINpjIySf1wBAgI6ChO49or9+7/bR vGnSEco/HDMzDbTSiZCSBg== Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta03.appoci.oracle.com [138.1.37.129]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4366xxah89-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 29 Nov 2024 02:36:25 +0000 (GMT) Received: from pps.filterd (phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 4AT27DIq001516; Fri, 29 Nov 2024 02:36:13 GMT Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2047.outbound.protection.outlook.com [104.47.58.47]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 436700w70y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 29 Nov 2024 02:36:13 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=XyG22h9Xj3BLJMt6kicbymAJ1OJkcNd8/P18Vd4eDqp95HMB9K09iiy06tCuKjjA1kcDdS5oXL5XtGnrJGcAIk408eD++OXhS3OIZjSSSJ9By2LDT9mEeGQYMOhG/otayLGXAWBdfMivTLCIzFEQRP4Kogfi3Wp4kKyes7DVPVFvO/Z3ExWSvgwK8XIjJ6DkD/ggnHpoIaHyJrk8uNF0h4mPopAjuniPuiiL8Ooj4CoHhqvnP96r/EdQcT2iNtrfcRblMtIqNavs7YaGgscLm469tbZIMqav3MVB1p654O9B0oEbt5f2g/6ldVEpR+PsGq+dYPJBv3dvdww08w/uQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=k1NyyfPAuD/+Fm/pQ/trRmc2QwEHhx+tMUgAKnzcGVM=; b=qBfcOv70IBIgnThOWI4H0fRLm14vj3NbH8lOzVc2awVIDra9DUtUfuUdIdhtMP1WihgH/hvUprIhvRTsitEqQVdp6uVumRY761vcSr+BN8RDAz0BJIBSkXHEiU1naGKYD6JaRUeo+5hPSoOWqMK+9O+0AP/YiGcfqExCWhV0qc8su7/D+/IIlcvJO31IOnyHDCEEZ/sTG3QwPAGNGgudedavGN3UXrG5SRXFBG+nUzoIzpEDtebWdwMGzYZ9KTqW8TMSQnrBxh0jRLYKUH+WFKjxRbXUZfHcSzfToimkpelAp9tlmnvrwVZVd1ZO5FoU+Svz3WbAN84E50tkZBOQeA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k1NyyfPAuD/+Fm/pQ/trRmc2QwEHhx+tMUgAKnzcGVM=; b=bjwSVdso8LW3UJ6/gaDS0nNNg8Ipm78744yPCrdqlKowweMU6aypNPxcSWDMawcMP6/fDp+Y4JP9LzY0alSBmPcs8A/bzk+kuM/o8Q/NAa6n9T7es6Elhg7it2fdmxU0Gi9ciRJ4NJ1n+RtMvoETScZwiowoeqqtCKJVM0oSLDI= Received: from DS7PR10MB5232.namprd10.prod.outlook.com (2603:10b6:5:3aa::24) by BY5PR10MB4305.namprd10.prod.outlook.com (2603:10b6:a03:20e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.14; Fri, 29 Nov 2024 02:36:10 +0000 Received: from DS7PR10MB5232.namprd10.prod.outlook.com ([fe80::8303:658f:14f8:2324]) by DS7PR10MB5232.namprd10.prod.outlook.com ([fe80::8303:658f:14f8:2324%5]) with mapi id 15.20.8207.010; Fri, 29 Nov 2024 02:36:10 +0000 From: Drew Adams <drew.adams@HIDDEN> To: Juri Linkov <juri@HIDDEN>, Spencer Baugh <sbaugh@HIDDEN> Subject: RE: [External] : bug#74561: [PATCH] Allow limiting the size of *Completions* Thread-Topic: [External] : bug#74561: [PATCH] Allow limiting the size of *Completions* Thread-Index: AQHbQcS+icG8r2tUyEKr/0KnFSCsQbLNixPQ Date: Fri, 29 Nov 2024 02:36:10 +0000 Message-ID: <DS7PR10MB52323C909A58B11BE149078EF32A2@HIDDEN> References: <iercyigfmq8.fsf@HIDDEN> <877c8n45tg.fsf@HIDDEN> In-Reply-To: <877c8n45tg.fsf@HIDDEN> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DS7PR10MB5232:EE_|BY5PR10MB4305:EE_ x-ms-office365-filtering-correlation-id: 0d839099-06b0-456c-8e89-08dd101e95aa x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|366016|1800799024|376014|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?/K+Ju20iYez6za1On/pWilSGtakjUpBKTJGVhBpAUH8R0ZCncgNJharFY5WA?= =?us-ascii?Q?CZoADYwkxzhO0rEm9J5i1kWUOFgwx7VH1oCjXB5av3rQs3fH7Comig9r7Z+j?= =?us-ascii?Q?OujMTmOnBAhtHQ0igfmO7Nwadb9WGvlMHUzd1oZBXgVbijKBUkgHOCK6U++6?= =?us-ascii?Q?OtrC9DYrYKlt4gnVVM2LtGUCHZqknWt7+fU6uGWCFl/w8p5zR1xEveh2aEn6?= =?us-ascii?Q?ZuvpKo0XMmfufL3Y5+MtgKxy7blMVPHlsaoSg9VubdujgCEq6NhWJMSVsjRX?= =?us-ascii?Q?Be35HsE5ZC2OZRRyf7zx8Zi4ErLQoO1DwBdvJ9jpKELpOy4ovoCi0bG+SH3k?= =?us-ascii?Q?wPZmuI1uiykycu8uFfhskYP9bTaCCns4mrjQ8O7tVcAayxVO7NUHtvSKx3Jd?= =?us-ascii?Q?bjyIP2gpbwP/eVXpvLSmVCKWgnr7orCL3dtrVfp/5/LUZ27ON+KAE9mkibzk?= =?us-ascii?Q?le3pBv7YyzKr9t6mG0tZ4Vmqabsu5RDhUMKWqP4k8NshtbePFUxQIcvjtDPQ?= =?us-ascii?Q?VK112dGP/1mhLOUTnX266IWkM69iBtQmeoug+8S1nROMD4EzmY9KOaVgi7Wm?= =?us-ascii?Q?8sn8ck/zBnDmRBbnoL7aixFEehLLIjmk1jWktWTjWUZsUa/XWglG4NyFijQQ?= =?us-ascii?Q?qbh1NKikihUWsPuUWX5wre32mBsskCwSvGjqv69lg2WBWdvH8XjqnkJ70vhq?= =?us-ascii?Q?ppJmNfzDfKE9BGggxgT006x4BwoGjJFZo2NQKxU3IN4G8COohtCuTXGUgcBl?= =?us-ascii?Q?KdeM0pBGrDUBII3f+evV7RN/8f0BQLNqHz92KxIApWWeRitefpLeaohMULRU?= =?us-ascii?Q?Y9FFCMpD9zOIxmqf1Den+nZtESNwirXv0rIPCynDN7q0NEsYR8y4uOP9B3H+?= =?us-ascii?Q?LRNKsukSmjr3EhTLFlUSfq11tr/n06GrXW9aE+TLXHizd8nkQD9mbEFPSTD+?= =?us-ascii?Q?Y+YZib0JhN2hwbTllim5TqTALWo1Q8wxkT4NFdzpgLBp99sukSXmB/X5q5WF?= =?us-ascii?Q?7kDXqyBCRpL7xA/zZFz6kBHbQ2GDFcS52PBnjkeMfSAA9eS8w7Y9zlnP9Wzf?= =?us-ascii?Q?CgVWxiK/ol6DUhMd7VtTJZx8nprxm2H04zBKTcjkk0Hywd/IBqMLA7Xp7sRw?= =?us-ascii?Q?fzlz75zItDIpvSURPh2WNYTMbb4/xQNMxXGp8JO1cvx8G6EqUn6DI5TGanA6?= =?us-ascii?Q?4i0gGg82IFdRd994o11YvS2ISJH9++9jULV6nK9NbZpohf1olwfa0FzTJG1f?= =?us-ascii?Q?5Voh13/5142TeDr9nGJ09ktBn3NTytBPbpfnhbn4IEHlei3WuRK1oRSF/66v?= =?us-ascii?Q?5d76Bv+LDue1UNscgeoK4tjy3DlPB5+wJaTIPEN0/LtoPjuk6ANysFGxkPga?= =?us-ascii?Q?p0tQsM5c7M3G4urvgpB+Uc08q5ZKoxPw/clwf+seIJgYkxA9qg=3D=3D?= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DS7PR10MB5232.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(366016)(1800799024)(376014)(38070700018); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?4iYK5BeFggfEaPYbhLjt4PWhY8nX6LFx4hg2BLj9ay8nwA9fjPcDm35PfAh2?= =?us-ascii?Q?vauYEYOZPK+D2obVPTBWHx49X8B4ya+m75FoG6nQARmIzhkV9p0VbHGEZlDJ?= =?us-ascii?Q?jB72z+NZUPwJHrH7zvryFn02Jc2JtxBmmGyx+1rbM/LZYgmmQWTHfEfKAFmw?= =?us-ascii?Q?Y6KK02IgzUZoTEyPyy5miNLQok9iq51M4Mnq4st0pG4e0VEBlT2uEGEX8SRL?= =?us-ascii?Q?cAdTrIErzUIuA/0nffZl/eOqObQPhucBA1vOthdRi9lu0jEe8jVht4+6WtTU?= =?us-ascii?Q?LApqJer72tZKpZwZmjxbbIRs/AzCx3RrR9fHEzWCp+zsLOuY3rPudfxb3luY?= =?us-ascii?Q?+yIKaw54ojHOc1iljt+frOQHXP11o/Ci33wFY1JSn+DmKytliBsdV7nzsj3D?= =?us-ascii?Q?pCHIwmdon3MpNxDbiNuIy4Pg2j7nKZ33a8qahPA6Zt4vTCBkH7yxnaa070lN?= =?us-ascii?Q?aIA+drP1T4nt03M7/DwAyW4AFJAUi2jGxOuyVID/RXxNR+QgHCiQKzBKjh3K?= =?us-ascii?Q?PvWQ7pnibkF2spOoYUqHo2jttVsmCP9HDQBaelN8Bcxh7OLLE5QsGiwRl0Zh?= =?us-ascii?Q?XJVhyORrBpnMcsUO71m8PM5hGasUozWa/3Udi4uHuRG0ljVx3s/Ofsjum60J?= =?us-ascii?Q?EyRZsUK0rK/WDri+iaGd4ZDDfGunR9wIr8huKMLMzQ28p6KD8Gt2Ujra3f70?= =?us-ascii?Q?iK5sDxEA13RpT8q5oz0f3Ty25/qA++icW56+jEWsdBfR3UQTGyxx/TuymFRp?= =?us-ascii?Q?hSTPuxn8dL6b/G/EQ0P3qAkLqM6iFZV/LJ2o81BP9Q1Y+4Jm8Yv8KksCmwer?= =?us-ascii?Q?D+n0Sy9GSH42a3a83p7xrGnNy7BQRobZNzNtY5lV9hfzXR6pyaO3f1kYD1lp?= =?us-ascii?Q?XWvMWpr5NR/fSrlXJmR5UMstFh0CydSm+THK0tJwgnAcuSA4tIFJCUiBQ1lY?= =?us-ascii?Q?I69FkmFOp2MU1R/6Lfldqz3Z2qZjieMQms++aT7RAKwiVwbeZqhrs+D2JTzO?= =?us-ascii?Q?Ymjiiq5tgyCN32UbQZ5p/d6lt5Enr/wWy9GzBg28nWtUaG44B2UKZs7TqADH?= =?us-ascii?Q?jGfIJix18FUVxidvVx99HL/xRs3qmQ3akr256ZWKynOl5zr4r6GN4rrfvGPt?= =?us-ascii?Q?U0LR5oLS1pq23HrSPHRHHIzBk4ti3XWtrJuQzPRv8ojuYTKBXW0MLREvVFky?= =?us-ascii?Q?bAWg7GGp20vRwmjmqLkfOe5Z0pBnVy3WY5xxpJVdSO/ntUZkvCbFs98IRSiF?= =?us-ascii?Q?r69YFh/jLxgSc/kSs7+TBnli321wc7KOP9PUx8GuNCPv2m9dBKBy0WpPwhwJ?= =?us-ascii?Q?qEpLBIXlB6Zel97gCwKwFqbOlGzMnxmeXhq+CXu+cKd82rTutm984w8BY8nt?= =?us-ascii?Q?X7Az6203ZIB6qAV/8I0axEAr6OuNPoxrhA9v98K1NXP1QNKNYDsvZjkQgesp?= =?us-ascii?Q?u0+Qc67viDgi6925s8C65YoV0QiAtJ07QU60RI5WFQzbyyOgIWqOmkewFAfo?= =?us-ascii?Q?r4yhu3L7H6v/lxu8S3J74o2b6rcBFCcyv+ChH0EpRYxsmm8Ym+JHAq+bm4BL?= =?us-ascii?Q?3vx/w4Hv9O1A/ZJBdPaLrPr+vg17MqKTLVaZ9RoG?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: Cq/OgxqHP9Iy1UnQz8iNVVOejVafrVKZ42O446oBpPmsuOYd7ksPkZjS9jyfah7w5p/ZzdwtTBhfkYpptF7gIP9rmvJiPDnN630oe62tqFwqiRvd+FExll9YEOQOsW+KLRD3C7n6yWA+RdoQcCNIGBr4mr7N+LWP+TZrga6eoyNR/rQpB6qJPd89mgu6w6LIHRurda8x64FhK45pUQ1YXJiGdMwE3l1conRLVfVC7h//4l/joVUElhZLSUx/6ChCFBRjzo2K69dwvbozI3IaBJXjnqmm25YrbyNswPUct/HN3PDZgJqrxkGfIqTHB4YHzWkPrtE71lgx/fzCKxjAHn0cGFX/Y9mjamhIwaL5KSmqZIjEOh/iQFAqJH471kCmyjUuVSRgLu+qIVCfLmN9+tLMoX5wDsiQ/y5nkRvam1R6iUFvTdVKPwAvCdBOtOzWunywCyELkkC4b9oSX9+1XhA5X+6D4T6AwDqa+Wa6jvhvjvTiy9BPH9LPoZy6GiXAMXdgtbLKFxMbOZ5m5tOsJj+RGZNNQopUGjgX+Xg6AJ5p4toVleL8l35P/I99Byxdq6aRDPI9LRFZjOsFLNRxbLodjIa9jB2Mqi4FWQgCHLc= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DS7PR10MB5232.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0d839099-06b0-456c-8e89-08dd101e95aa X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2024 02:36:10.2342 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JyceyguH9QnGrOgq2Wih0b3kPjK0Z/qxq5AS3rMEHINhN/Hf+68hl2b2guCYt3kOKx8YIipzlw+fi9FW7lxveA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR10MB4305 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2024-11-29_01,2024-11-28_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 spamscore=0 phishscore=0 bulkscore=0 adultscore=0 suspectscore=0 malwarescore=0 mlxlogscore=942 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000 definitions=main-2411290019 X-Proofpoint-GUID: i4q_p1fWEnt--L9WkVoq13uv3XwtkWIY X-Proofpoint-ORIG-GUID: i4q_p1fWEnt--L9WkVoq13uv3XwtkWIY X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74561 Cc: "dmitry@HIDDEN" <dmitry@HIDDEN>, "74561 <at> debbugs.gnu.org" <74561 <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.7 (-) > > +(defcustom completions-list-max 10000 > > + "Maximum number of completions for `minibuffer-completion-help' to > list. >=20 > 10000 is too small default value. I often use 'C-x 8 RET TAB' > to browse the full list of 50866 Unicode characters > and use Isearch to find a character by name. And it's quite fast - > usually takes only 1-2 seconds to show the completion list. Why have a count as default? The option I have (`icicle-max-candidates') has default value `nil', meaning there's no limit by default.
bug-gnu-emacs@HIDDEN:bug#74561; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 28 Nov 2024 18:37:11 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 28 13:37:11 2024 Received: from localhost ([127.0.0.1]:39699 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tGjO3-0001ia-7g for submit <at> debbugs.gnu.org; Thu, 28 Nov 2024 13:37:11 -0500 Received: from lists.gnu.org ([209.51.188.17]:54384) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1tGjO1-0001iP-M1 for submit <at> debbugs.gnu.org; Thu, 28 Nov 2024 13:37:10 -0500 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 <juri@HIDDEN>) id 1tGjNz-0006CE-Gd for bug-gnu-emacs@HIDDEN; Thu, 28 Nov 2024 13:37:07 -0500 Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <juri@HIDDEN>) id 1tGjNv-0004fM-Lo for bug-gnu-emacs@HIDDEN; Thu, 28 Nov 2024 13:37:04 -0500 Received: by mail.gandi.net (Postfix) with ESMTPSA id 96D40E0003; Thu, 28 Nov 2024 18:36:58 +0000 (UTC) From: Juri Linkov <juri@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> Subject: Re: [PATCH] Allow limiting the size of *Completions* In-Reply-To: <iercyigfmq8.fsf@HIDDEN> (Spencer Baugh's message of "Wed, 27 Nov 2024 15:25:19 -0500") Organization: LINKOV.NET References: <iercyigfmq8.fsf@HIDDEN> Date: Thu, 28 Nov 2024 20:18:19 +0200 Message-ID: <877c8n45tg.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@HIDDEN Received-SPF: pass client-ip=217.70.183.196; envelope-from=juri@HIDDEN; helo=relay4-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: submit Cc: dmitry@HIDDEN, bug-gnu-emacs@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.6 (--) > +(defcustom completions-list-max 10000 > + "Maximum number of completions for `minibuffer-completion-help' to list. 10000 is too small default value. I often use 'C-x 8 RET TAB' to browse the full list of 50866 Unicode characters and use Isearch to find a character by name. And it's quite fast - usually takes only 1-2 seconds to show the completion list. An alternative would be to populate the list lazily by small chunks added with an idle timer. But not sure it's worth the complexity.
bug-gnu-emacs@HIDDEN:bug#74561; Package emacs.
Full text available.Received: (at 74561) by debbugs.gnu.org; 28 Nov 2024 06:44:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 28 01:44:24 2024 Received: from localhost ([127.0.0.1]:36148 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tGYGG-0006Rm-3W for submit <at> debbugs.gnu.org; Thu, 28 Nov 2024 01:44:24 -0500 Received: from eggs.gnu.org ([209.51.188.92]:53724) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tGYGC-0006RU-T3 for 74561 <at> debbugs.gnu.org; Thu, 28 Nov 2024 01:44:22 -0500 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 1tGYDz-0000DB-7F; Thu, 28 Nov 2024 01:42:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=bB3fxEeEmzBL7UFPq7NCtsy69ZS7wAMv0HZPYJGGE58=; b=bTWuARvPHC9L cvU/ACMa5BSGVRDCnRdiFFcNHpEyxFsQWl3RxKp/PQkfWzXGohvOXOV01TtL2vXGa3bWaWN1rnaCq hHhbwgtEp5pvMYI9ybCKnu8sPUGl1B3QVVZFJy5ypIFBqpd/lhPcvji96pNTid1Awg1FZIap1nv+9 hwdE8LUdKUZZMBjklY099CpbSczkQlL6KpUpiPHVqJ71jCeCfVDfyx7MLctuN1SDAi3B31l9gQ2PK dNPK4irxVHhMBL8xbCybnDLVi4RIWb1tufx2VRvDnCzrAlvQkXJC+6t0/BmJELXzGI8gZhIHyvohK YmCFrN7sYBYbgsimw7OJ9Q==; Date: Thu, 28 Nov 2024 08:42:01 +0200 Message-Id: <86y113eu6e.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN>, Stefan Monnier <monnier@HIDDEN> In-Reply-To: <iercyigfmq8.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* References: <iercyigfmq8.fsf@HIDDEN> X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 74561 Cc: dmitry@HIDDEN, 74561 <at> debbugs.gnu.org, juri@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.6 (--) (Adding Stefan to the discussion.) > Cc: dmitry@HIDDEN, juri@HIDDEN > Date: Wed, 27 Nov 2024 15:25:19 -0500 > From: Spencer Baugh via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > > >From profiling, the main bottleneck in completion over large > completion sets is display-completion-list, when there are many > available candidates. For example, in my large monorepo, when > completing over the 589196 files or the 73897 branches, even with the > candidates narrowed down by typing some prefix to complete, TAB (when > it shows *Completions*) or ? is slow, mostly in > display-completion-list. > > By adding completions-list-max with a very large default, performance > is greatly improved in these situations without impacting the normal > case of completion on reasonably sized sets. > > Limiting the work done by display-completion-list is also important > for packages which auto-update *Completions* inside while-no-input: > since display-completion-list doesn't do anything which reads input, > while-no-input won't interrupt it. Such packages can instead just > bind completions-list-max to a smaller value. IMO, that's the wrong way of solving this issue. A Lisp program can hardly know what limitation to impose in each case. It could very well set a limitation that leaves the important candidates out. (And, btw, the fact that completion is slow when there are many candidates is the wrong rationale for this kind of feature. If I magically speed up completion by 2 orders of magnitude, would you drop the proposal and agree to showing 589196 candidates to the user?) IMO, this is something for the user to specify, not for Lisp programs or global options. So the better solution for this is to ask the user whether to show all the candidates and how many of them to show, and the user's response will probably be different depending on the context and the circumstances. This is what Bash does: User: TAB Bash: Display all 4741 possibilities? (y or n) Why shouldn't Emacs learn from Bash, let alone improve it (Bash doesn't let you ask for the first 1000 possibilities, for example, or for the last 110)? The proposal here does not allow such UI, AFAIU. So I think we should instead add a mechanism for supporting such a UI, and include in it the capability for the user to tell Emacs how many candidates to show. Then we could improve the completion interaction by using that mechanism. > >From profiling, the main bottleneck in completion over large > completion sets is display-completion-list, when there are many > available candidates. For example, in my large monorepo, when > completing over the 589196 files or the 73897 branches, even with the > candidates narrowed down by typing some prefix to complete, TAB (when > it shows *Completions*) or ? is slow, mostly in > display-completion-list. If display-completion-list takes most of the time (something that is expected, I think), then the problem is in display, and any improvements should be there first. For example, could it be that it is slow due to long lines? if not, what makes display-completion-list so slow? More detailed analysis needed, IMO. This is independent of the larger issue above: whatever we do to limit the number of candidates, it's ridiculous to spend most of the time in showing the candidates on display, so we should make that as fast as possible, regardless of the rest. > Limiting the work done by display-completion-list is also important > for packages which auto-update *Completions* inside while-no-input: > since display-completion-list doesn't do anything which reads input, > while-no-input won't interrupt it. Here's another immediate hint for improving the UX: make it so display-completion-list could be interrupted. Again, limiting the number of completions is blunt instrument, which misses opportunities for important improvements. > +If FULL-COUNT is non-nil, it's used as the total number of > +completions." This is hard to parse. Does FULL-COUNT have to be a number? if so, the doc string should say so. And how is "total number of completions" used by the function? without knowing that, this addition to the doc string is not useful. > + (completion--insert-strings completions group-fun) > + (when (and full-count (/= full-count (length completions))) > + (newline) > + (insert (propertize > + (format "Displaying %s of %s possible completions.\n" > + (length completions) full-count) > + 'face > + 'shadow))))) That leaves no possibility to display the next portion of the candidates. Why not? couldn't some UI want to present such a feature? > +(defcustom completions-list-max 10000 > + "Maximum number of completions for `minibuffer-completion-help' to list. "to show" or "to display", not "to list". The latter is ambiguous, whereas minibuffer-completion-help's job is to display the candidates. > +After the completions are sorted, any beyond this amount are > +discarded and a message about truncation is inserted. Passive tense alert! > This can > +improve performance when displaying large numbers of completions." Performance is not the only reason to avoid showing a very long list of completions. If we want to include in the doc string the reasons to use this variable, let's mention the other reasons. More generally, since this is a user option, we should perhaps have a variable that takes the default value from the option, and let Lisp programs bind that variable, not the option. Suppose we have a situation with nested completion -- would we want the outer one affect the inner one if it binds the option to some value? > + (when completions-list-max > + (setq full-count (length completions)) > + (when (< completions-list-max full-count) > + (setq completions (take completions-list-max completions)))) > + This assumes that the process of producing the completion can never be the bottleneck, but that is not a given. How about extending this to allow stopping the process of collecting the candidates once the limit is reached?
bug-gnu-emacs@HIDDEN:bug#74561; Package emacs.
Full text available.Received: (at 74561) by debbugs.gnu.org; 27 Nov 2024 23:23:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 27 18:23:22 2024 Received: from localhost ([127.0.0.1]:35448 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tGRNR-0001HK-SW for submit <at> debbugs.gnu.org; Wed, 27 Nov 2024 18:23:22 -0500 Received: from mx0b-00069f02.pphosted.com ([205.220.177.32]:21816) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <drew.adams@HIDDEN>) id 1tGRNQ-0001HC-9R for 74561 <at> debbugs.gnu.org; Wed, 27 Nov 2024 18:23:21 -0500 Received: from pps.filterd (m0246630.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4ARICLAZ014609; Wed, 27 Nov 2024 23:23:19 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= corp-2023-11-20; bh=NOlC/7enQMMOahkMfEbLL/njwKNjX2jrxpHeoR+E+Sk=; b= eW7W1oSG0w4sAdfoAtaew6JOt2sw2OdLJqQi6Z5+mhiqWuBexaR6HIefntAPqXuE d08vRNkZAaDe2TmkP8taw18yV5v5W/EBopHIhT8xi4lhDcRZrX86QTrt8GZ3Jjkk uymajKsnzjc2c4sNsPKOLUPx8BjBRmcPg+918dFDIAYoljMcfzP/2J5S6xFyjym9 WiIuIGRw9bB4mssB2SQyzYLe73XTG8+rjaXsdx0NZRfStlh4qrspymBVwqHNQZqw +7DGaNedTt55UpIibZyxH8BLqwfq84zN+YYSJ0TVFoIOYKZ4A9h9x+IuuDLfD77/ zfeyTlFk4yL07TmnQx7rQQ== Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta01.appoci.oracle.com [138.1.114.2]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4366xy8ny0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 27 Nov 2024 23:23:15 +0000 (GMT) Received: from pps.filterd (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 4ARMpfTl014283; Wed, 27 Nov 2024 23:23:14 GMT Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2042.outbound.protection.outlook.com [104.47.58.42]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 4366yxw7ms-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 27 Nov 2024 23:23:14 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=YLi8k+astw1bvnE1QU71g7MCjKPMsnnxrei0/VA713BaXNcO/UpxYhqAOZAxYGKy2aGIZNqVpOkXHyh9cLVZjbAJtONrTiZ4bvoIqPvUih8/ARPh0FCyZ9fSBdO9iQfDHmsbGYYhxWgfDlsYa5fa1kkg7dRt+yzGAa1O+lhg4JIpH+FbcOkLERU1F/vY+hvxKbb+uDzLvunQIk+tXzwPI8Yfeut24eLQeOn15jbNUFKLH2WdTH/Nfrllvh0027QLH7gWAXQ/uwSTiMbZIM/8Qqs0SifBgdNRUBwy4WGhegSIY8/xMeG2FhVUwMKT2RN7qrTJhaXykSMNNYet1k6QAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NOlC/7enQMMOahkMfEbLL/njwKNjX2jrxpHeoR+E+Sk=; b=e14W3u1dMuLcl9rM8QrxNK0Mve104XVBiMPMMan2/0naAJqE4B50RzKIhbJosSOlDSulzEnSopETDeiIS3GGiA+hJDEr12KUu3/FaxdofyrVKQMbVQPs291jiH028Hh6PYCaSIqoVwnFqH7IqGWiG3eeYT03MCAbNeC//ezgUvFzYOqm7PQmWoZ/UvU4W0v13RJbuChXNCJp65jzlE9+B4RGH/M9LhnUB3XoStbcmAuoXjHoFvmKGR0uOVNeix59F5IEM9Ec+TfeCnPrwgFPX00oRdI8heDEXlCw0zKpX9Ghxc/YP41ZCqAJxSHRcL4YTR0h190HWV02+GN1bhkj+g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NOlC/7enQMMOahkMfEbLL/njwKNjX2jrxpHeoR+E+Sk=; b=xJNpy4LlwWEJKdDpmem0kGqKgiOFYsGzPjrUrbqUw7gK49DnuRGBp4hRO6dnBNAwD2sgVEohlMSv+sqHvL3FuLh4lfVrXOw/0KdJ506VkeAHg4Nz4hRfvQrUfMEAYlxYUsGlSxgORTG4SXNbNQC2JgM5U/w85RFH0+HDegDNUmg= Received: from DS7PR10MB5232.namprd10.prod.outlook.com (2603:10b6:5:3aa::24) by DS7PR10MB7189.namprd10.prod.outlook.com (2603:10b6:8:ea::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8182.21; Wed, 27 Nov 2024 23:23:12 +0000 Received: from DS7PR10MB5232.namprd10.prod.outlook.com ([fe80::8303:658f:14f8:2324]) by DS7PR10MB5232.namprd10.prod.outlook.com ([fe80::8303:658f:14f8:2324%5]) with mapi id 15.20.8207.010; Wed, 27 Nov 2024 23:23:12 +0000 From: Drew Adams <drew.adams@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN>, "74561 <at> debbugs.gnu.org" <74561 <at> debbugs.gnu.org> Subject: RE: [External] : bug#74561: [PATCH] Allow limiting the size of *Completions* Thread-Topic: [External] : bug#74561: [PATCH] Allow limiting the size of *Completions* Thread-Index: AQHbQQqmDQXrYffJAkmdXskRA8pvfbLLvqGQ Date: Wed, 27 Nov 2024 23:23:12 +0000 Message-ID: <DS7PR10MB5232C3A77A67D803133A60F2F3282@HIDDEN> References: <iercyigfmq8.fsf@HIDDEN> In-Reply-To: <iercyigfmq8.fsf@HIDDEN> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DS7PR10MB5232:EE_|DS7PR10MB7189:EE_ x-ms-office365-filtering-correlation-id: 24aeaddf-4093-4113-26ed-08dd0f3a7639 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|366016|1800799024|376014|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?SLb8m/CeU8Z6NgP21WbGH/ZYXXpb/+jr2/C6WIGFpcblmWHfDzXppGoKqhic?= =?us-ascii?Q?KUXZpIRrmJh75gKD+mecvTOcEq8vmt0nvjcrOpt57VY7Eh4jg37FBTshBw2u?= =?us-ascii?Q?acCxu5Znr67iU784G7PLPQuXXR5iX/rKJa8fEeGyMkcbrKkvf8YPA1kMMvHb?= =?us-ascii?Q?95Oe4BW2TR26X1FKWhhoNNishOHNDp+EFQ69zgTJEz4YQd1B2NiD64oTJUgB?= =?us-ascii?Q?efMyqx6k6sAfJG5uYOEYTWzMkwmyVgSDBmNDfZfsMcF5fd7D8uyuloJYB9gU?= =?us-ascii?Q?VNM5hHqAaa7Ht+a8okWFMIc1YFKtv+pMESg7/uOaCS//jEVBs2ENh7Pv8DfD?= =?us-ascii?Q?dqd9Bl64NtwxFF718douEE426EsmLeXGJio6e9mlD3Sx+TN/hACF2h7Mabjv?= =?us-ascii?Q?4+h3pq3a4tSbrO5C3kTIM8+aLF0mDHNzVp6indt2/zqFRrXt2yieooFcslLA?= =?us-ascii?Q?+hc1HP5KCWyy9hOAUf2A1AfYa1mz0Ou1e0vWtPxct6wTYgxaGaLnnA3L0RW9?= =?us-ascii?Q?qE0TdoOULbxtzqtlspc8hV0KVnAfh6Syk6hViMQqzrtupgkLKMCuh5bAUV7y?= =?us-ascii?Q?o+h/rYD+f1HC5a6YX4ayuvvQZ7Qbz3AmHATfN0m3ESJ6zfp7lnw8TI2jaj2Q?= =?us-ascii?Q?FQRYBTTqEmS9A0HfW8lRMspCwEUqnsjQDYr9AzMXCUn4c2Pw/BuG6pgWsfxv?= =?us-ascii?Q?HXnBgKPnyAfvsEDCnVqnuALkpdrcSUIRYuBTU6plBxIC5RYhDrmB3Bxtzcja?= =?us-ascii?Q?7a4+phShFWRr7VKrtQg9cTVSuvg4l52VAcHtD/mlh9BtrZl7TlJJrlS/SBU2?= =?us-ascii?Q?VyvtDLOi21Fx5KplkQ53gb2f1OLi8jsBER/Ud9qtApMwG7Zc4RoQ5qZUJ80u?= =?us-ascii?Q?QG16WRCF8IOVgmLzeKgygyQGyWaZ77tS4DPeK9Bxah+fpIahzW4f04B0xDBw?= =?us-ascii?Q?VYS3TqUCkS/mVUmscM+u/zmexjFnGngI3qyQUdMUxFfw3ArqaShWKxA7oq7n?= =?us-ascii?Q?EkFo9IqNMi6l4y9foSf7geJnZ5GU3jGXcZSM2BEjrwlsFY1QicLHog8rBRl0?= =?us-ascii?Q?se0GbH2I99WfXK7A1UwCFp6TtBPLxpNuwGdERIfuKlO91b5W5pdpJ9lPHMxo?= =?us-ascii?Q?Fadt3/l52BJjF6srSkaPY5mg9g9Emz0n4XsKNhyW/2cFklEBX7FDtpr5WiMK?= =?us-ascii?Q?H1+rhU+NyNz2jxtFK6JgSN/xqWrk9gOXXU6MJX43aIiKGxGogzeG/4kpXYXE?= =?us-ascii?Q?TjUCUACmk50V8Bjzk+95Ow/fmQknkYuZB6WieC+Jp/EU+6lci0DF4RQDzRHx?= =?us-ascii?Q?sq8xQhgldSeHn8AaIy35RxC1ocDHs+G3URgZG6nF1sia0p1ruSKo7CDR/TT+?= =?us-ascii?Q?J1z6QU2/EhKE+5vgpeJt32GeYB1SZWQT1w7L0FPczx8pxZn7JA=3D=3D?= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DS7PR10MB5232.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(366016)(1800799024)(376014)(38070700018); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?hv5YXDIjhYi3C5puEJ0a+6SQkOYt80y47R342hDecZAtvIm5AWRBx5oK/ELd?= =?us-ascii?Q?oi4V8hGum8d8zgIVCm6p+EK/ScKmgI7V2TLoVlUaeMBRG3eWDz9J2ivD5J0E?= =?us-ascii?Q?gSpDWM/iLvua0XxtReIg8n3qwrQZ7rggcUTboOgr6+2cEYlRZYG+MV4qtfPT?= =?us-ascii?Q?ytv+7YjU39sx/dSiA0RN+w8UtES+Nblwkbugbn/1nsqhm8MzVtzYj4QG2tcF?= =?us-ascii?Q?PS+DY8PXyxmt9NJivS1yl7m+nshHSha2MlE4yjgyRSYKEAFM4RbqgB25AdIK?= =?us-ascii?Q?YG7WUo2VzCG5LJZE68IYblEMa/9oLQKxeRnxNJqkmMe5505tb9A8HQFU9dQR?= =?us-ascii?Q?iGYj2yuKu6ljdBL8cqUiQcYWqYqZiv+8NIDdp0QJIM1kDh4iAYA6jdiJGdPL?= =?us-ascii?Q?5BcOFd3aZ4fFfSf+aveEHtkCg5TJfu2CWr24vUzZ7KZgq8Tf7XVNJQkQO5Yg?= =?us-ascii?Q?wowWIswP+5zZ6zxlBndL9NkVMq7qpSH7Ga9ZVrX+7Fsy6AgwhGswOg0JRjZ4?= =?us-ascii?Q?YgOkTpTFz3NV2NKrELrE1Yirag2JCHRDlqis1CvYJN/tm71i6VMLRU25/ic7?= =?us-ascii?Q?D3/VpHbPetiYVoHOsyVCa+ZYk0O5wfheFSaEkiaS8FJGV7Q1yyDdmghMVm+G?= =?us-ascii?Q?ysBECtuMtLgcqGqGagfHzIbYWiS83siHP2dKi3MxrXGSspurzCj5vl4s0Tah?= =?us-ascii?Q?ntYL6upGodqjrEIPLRHV7xfqV+oGkx7OMRniGrJLm5d+MHPtCXEvF1xo7Kso?= =?us-ascii?Q?zwTZhIpC0CBIwdFygQOk1vngA4AEy8EjFdOx5nQ+LrSdp5V98Rn7lu9SL8Fw?= =?us-ascii?Q?fUy+xDF3TEnPJP0LOlBLZOy6H2wNu+q6Mj/qGEqKr8i5NKAfCBvfXGtAV6F9?= =?us-ascii?Q?HFryM1BQKR//d/ZPe7a02P+p2S2L7nRLu0lS0oqly4RxJaqvwMxsIj3UWupu?= =?us-ascii?Q?VKO5WUqmNHeyjE9s0aICjlKHPzeHRP6U76kYQUn5Z/j8EAquez5z5qXa2sBt?= =?us-ascii?Q?xRATzFSuwslfUjKZE+O+HGIIuXLu6WWQaT3qu8j8IhIDZI7lEVbawrDYUbZH?= =?us-ascii?Q?wMJdto0s/hvRA0idzShD/TyIVh+AV5mqxp09qTFrgx6PrEBR96kYowXJNClg?= =?us-ascii?Q?SLWukgyuZFBbdGlQQ+bzl9unPRKgbS8FTnrCdDwafuFb1P2/3RrVEeYsENT4?= =?us-ascii?Q?i1r2evCH9UQrTNeR4JT0IreV9JicOKm4sGHMSpfH3OtlEwzS/3j6nf8CIU70?= =?us-ascii?Q?NZZR2rfbzbkLNO7Um+CqlnYGD2P+1Oe+qqBkuaeT62EyVugUvJmPOXH+S3yQ?= =?us-ascii?Q?TjR+CjBf7W1eM44ILVGBhUVp3ZQcd5v7CbOSca7PLjstxkpPMrJcGQBgYaQ1?= =?us-ascii?Q?HHO47u+WwfPS5+79MQf6C6anbSK3a4UfKvd7WjTTkNeAnDcP8l77WenqMNT4?= =?us-ascii?Q?gB+CAygPHEB7cxKPsDeffJaCf17dKCl7DGwa3QY6s0rJUXFYOPZyU0qK983P?= =?us-ascii?Q?aIZe9w6X4KCOSJIebDJ811b5QFrL+RhGaI4LWR4jCtk1xtu3CzL+H5iAIhuu?= =?us-ascii?Q?YrB78HKoyz/Lnp/lkJ35mpwVh6VtBXtQLb8hGJOO?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: NZt+SQSsOON9qCDWjdRofw21KQ3OfhiQj4pB2r5QUkhBNJQE/AfFyCmMn5JNeBQMuSXyu4HE8bTsEEvkpvmRwjMtmlhoi7PAWys33bA1TE+xVthtyybOL5pK7H6I2BSTuFxrUJ+C7AkqxLvzxqZAOpmdjkVe/yO3eoESicojrf92hYuwQHVkoG5NU9/5LStkAmUprr5zLieaay5Bg20LNFTs83/8KU+qBg+NwKjZjD3qMrlpW+6HRv6y7jRgcwN8+0QvB1BoyrwubbZjV65Nc9+xO8RamXvCKcqVxLE7HOf0eSkSOlwAjrDYkENEa+oWgzRBXGsAHcXV/eSxjd5fLZjzoMEe+E0RXt+eEOXQO9NkqDDrRwpKMwag+9wIEemiHlXxTbNho3MzIUF9PBhqxE6J9QFIRHeZcQJWLuNYMJPbArw7s3LyVYSuDJITw00GYncxNlYTjZdBs35eqjgRYjlTyjvYXOfrNx2dYSVefL6w/CmZj2cq8wjN+KY6mR1g7MngsnVTdanKKgqqkXL9EIt9pNdFn++mqSF2Qcj0BSbE91xWxbpRkfnIO8shscrF2ueY2L+MCNGXBn3uw14KjTGKAEJp5joeITcYBxY4IkM= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DS7PR10MB5232.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 24aeaddf-4093-4113-26ed-08dd0f3a7639 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2024 23:23:12.2278 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Y/UTPGNbiDYhiW5+h6TB3qspPW055yrouyP/PyXnwdEqpQjGXyxJGG6Fk1tTbZaBpqoEWOxllf1H1FLbll7WhQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR10MB7189 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2024-11-27_10,2024-11-27_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 suspectscore=0 spamscore=0 phishscore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000 definitions=main-2411270182 X-Proofpoint-GUID: -LTZ7xCSuBDxMuBz_fG03PcK9nannjz9 X-Proofpoint-ORIG-GUID: -LTZ7xCSuBDxMuBz_fG03PcK9nannjz9 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74561 Cc: "dmitry@HIDDEN" <dmitry@HIDDEN>, "juri@HIDDEN" <juri@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.7 (-) FWIW, Icicles has had this since 2010. `C-h v icicle-max-candidates': icicle-max-candidates is a variable defined in `icicles-opt.el'. Its value is nil Documentation: Non-nil means truncate completion candidates to at most this many. If you use library `doremi.el' then you can use `C-x #' during completion to increment or decrement the option value using the vertical arrow keys or the mouse wheel. A numeric prefix argument for `C-x #' sets the increment size. A plain prefix argument (`C-u') resets `icicle-max-candidates' to nil, meaning no truncation. If the value is an integer and you use Do Re Mi (library `doremi.el') then you can use multi-command `icicle-increment-option' anytime to change the option value incrementally. You can customize this variable. If the list of candidates shown in `*Completions*' is truncated because of `icicle-max-candidates' then: 1. Mode-line minor-mode lighter `Icy' is suffixed by `...'. If you see `...' you know that if you increase `icicle-max-candidates' (e.g. by using `C-x #') then more candidates will be available. 2. The mode-line of buffer *Completions*' shows the number of candidates - e.g., `567 candidates'. If the display is truncated then it shows the number displayed and the total number - e.g., `149/567 candidates shown'.
bug-gnu-emacs@HIDDEN:bug#74561; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 27 Nov 2024 20:25:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 27 15:25:29 2024
Received: from localhost ([127.0.0.1]:34765 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tGObI-0000MH-HT
for submit <at> debbugs.gnu.org; Wed, 27 Nov 2024 15:25:29 -0500
Received: from lists.gnu.org ([209.51.188.17]:33874)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <sbaugh@HIDDEN>) id 1tGObF-0000M5-LX
for submit <at> debbugs.gnu.org; Wed, 27 Nov 2024 15:25:27 -0500
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 <sbaugh@HIDDEN>)
id 1tGObE-0004qS-01
for bug-gnu-emacs@HIDDEN; Wed, 27 Nov 2024 15:25:24 -0500
Received: from mxout5.mail.janestreet.com ([64.215.233.18])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <sbaugh@HIDDEN>)
id 1tGObC-0001fS-5t
for bug-gnu-emacs@HIDDEN; Wed, 27 Nov 2024 15:25:23 -0500
From: Spencer Baugh <sbaugh@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: [PATCH] Allow limiting the size of *Completions*
Date: Wed, 27 Nov 2024 15:25:19 -0500
Message-ID: <iercyigfmq8.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com;
s=waixah; t=1732739120;
bh=t5P4N8if2RHQwvM+ETw6Dv1534Uti5eaHBmYjsw9WNA=;
h=From:To:Cc:Subject:Date;
b=Bodi7dfGmi+qzWnaYw1jsEPduK1HBRkAKT+43w4A44WqFI9vKoOBu56Fw6BrimJpK
dPsxg+/hueyUE0wxn4QdBGgmp8CjFv0o26SgWkYtR8rT/7wsune3njv09sw/EFegb4
V69SaDvfMKTElsEiBmZgW2uU8PEBzpUH+5QE1Tu6QknvqS6s7liNrDZgjwv3BaNXYe
+Zk+lDO0wMBDSCWIMypsmdjEuefkHJ8AO4uWmsN8CDo44v5+BzMdBISLq2YHuHhoT7
1WHKN2z/cnG4LStestvUpyQz8OW1E3I6niI8grYsLZmU/CZHpJ9UdpMG/N2hyVoffW
v7InutHm/B+qw==
Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@HIDDEN;
helo=mxout5.mail.janestreet.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001,
RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.4 (-)
X-Debbugs-Envelope-To: submit
Cc: dmitry@HIDDEN, juri@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.4 (--)
--=-=-=
Content-Type: text/plain
Tags: patch
From profiling, the main bottleneck in completion over large
completion sets is display-completion-list, when there are many
available candidates. For example, in my large monorepo, when
completing over the 589196 files or the 73897 branches, even with the
candidates narrowed down by typing some prefix to complete, TAB (when
it shows *Completions*) or ? is slow, mostly in
display-completion-list.
By adding completions-list-max with a very large default, performance
is greatly improved in these situations without impacting the normal
case of completion on reasonably sized sets.
Limiting the work done by display-completion-list is also important
for packages which auto-update *Completions* inside while-no-input:
since display-completion-list doesn't do anything which reads input,
while-no-input won't interrupt it. Such packages can instead just
bind completions-list-max to a smaller value.
* lisp/minibuffer.el (display-completion-list): Add FULL-COUNT
argument.
(completions-list-max): Add.
(minibuffer-completion-help): Truncate completions based on
completions-list-max.
In GNU Emacs 29.2.50 (build 9, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.15.12, Xaw scroll bars) of 2024-11-20 built on
igm-qws-u22796a
Repository revision: 28dc0b6f9987e0def7dff4deaa23aa60f021d2a7
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Rocky Linux 8.10 (Green Obsidian)
Configured using:
'configure --with-x-toolkit=lucid --without-gpm --without-gconf
--without-selinux --without-imagemagick --with-modules --with-gif=no
--with-tree-sitter --with-native-compilation=aot
PKG_CONFIG_PATH=/usr/local/home/garnish/libtree-sitter/0.22.6-1/lib/pkgconfig/'
--=-=-=
Content-Type: text/patch
Content-Disposition: attachment;
filename=0001-Allow-limiting-the-size-of-Completions.patch
From 808b1a6d01fcd2d2cc03324aa9826b3160047653 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@HIDDEN>
Date: Thu, 14 Nov 2024 17:14:10 -0500
Subject: [PATCH] Allow limiting the size of *Completions*
From profiling, the main bottleneck in completion over large
completion sets is display-completion-list, when there are many
available candidates. For example, in my large monorepo, when
completing over the 589196 files or the 73897 branches, even with the
candidates narrowed down by typing some prefix to complete, TAB (when
it shows *Completions*) or ? is slow, mostly in
display-completion-list.
By adding completions-list-max with a very large default, performance
is greatly improved in these situations without impacting the normal
case of completion on reasonably sized sets.
Limiting the work done by display-completion-list is also important
for packages which auto-update *Completions* inside while-no-input:
since display-completion-list doesn't do anything which reads input,
while-no-input won't interrupt it. Such packages can instead just
bind completions-list-max to a smaller value.
* lisp/minibuffer.el (display-completion-list): Add FULL-COUNT
argument.
(completions-list-max): Add.
(minibuffer-completion-help): Truncate completions based on
completions-list-max.
---
lisp/minibuffer.el | 38 +++++++++++++++++++++++++++++++-------
1 file changed, 31 insertions(+), 7 deletions(-)
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 5d11064d900..8078e1603ae 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2354,7 +2354,7 @@ completion-hilit-commonality
completions)
base-size))))
-(defun display-completion-list (completions &optional common-substring group-fun)
+(defun display-completion-list (completions &optional common-substring group-fun full-count)
"Display the list of completions, COMPLETIONS, using `standard-output'.
Each element may be just a symbol or string
or may be a list of two strings to be printed as if concatenated.
@@ -2366,7 +2366,9 @@ display-completion-list
At the end, this runs the normal hook `completion-setup-hook'.
It can find the completion buffer in `standard-output'.
GROUP-FUN is a `group-function' used for grouping the completion
-candidates."
+candidates.
+If FULL-COUNT is non-nil, it's used as the total number of
+completions."
(declare (advertised-calling-convention (completions) "24.4"))
(if common-substring
(setq completions (completion-hilit-commonality
@@ -2379,17 +2381,24 @@ display-completion-list
(let ((standard-output (current-buffer))
(completion-setup-hook nil))
(with-suppressed-warnings ((callargs display-completion-list))
- (display-completion-list completions common-substring group-fun)))
+ (display-completion-list completions common-substring group-fun full-count)))
(princ (buffer-string)))
(with-current-buffer standard-output
(goto-char (point-max))
(if completions-header-format
- (insert (format completions-header-format (length completions)))
+ (insert (format completions-header-format (or full-count (length completions))))
(unless completion-show-help
;; Ensure beginning-of-buffer isn't a completion.
(insert (propertize "\n" 'face '(:height 0)))))
- (completion--insert-strings completions group-fun)))
+ (completion--insert-strings completions group-fun)
+ (when (and full-count (/= full-count (length completions)))
+ (newline)
+ (insert (propertize
+ (format "Displaying %s of %s possible completions.\n"
+ (length completions) full-count)
+ 'face
+ 'shadow)))))
(run-hooks 'completion-setup-hook)
nil)
@@ -2455,6 +2464,15 @@ completions--fit-window-to-buffer
(resize-temp-buffer-window win))
(fit-window-to-buffer win completions-max-height)))
+(defcustom completions-list-max 10000
+ "Maximum number of completions for `minibuffer-completion-help' to list.
+
+After the completions are sorted, any beyond this amount are
+discarded and a message about truncation is inserted. This can
+improve performance when displaying large numbers of completions."
+ :type 'number
+ :version "31.1")
+
(defcustom completion-auto-deselect t
"If non-nil, deselect current completion candidate when you type in minibuffer.
@@ -2554,7 +2572,8 @@ minibuffer-completion-help
;; window, mark it as softly-dedicated, so bury-buffer in
;; minibuffer-hide-completions will know whether to
;; delete the window or not.
- (display-buffer-mark-dedicated 'soft))
+ (display-buffer-mark-dedicated 'soft)
+ full-count)
(with-current-buffer-window
"*Completions*"
;; This is a copy of `display-buffer-fallback-action'
@@ -2610,6 +2629,11 @@ minibuffer-completion-help
(_ completions-group-sort))
completions)))
+ (when completions-list-max
+ (setq full-count (length completions))
+ (when (< completions-list-max full-count)
+ (setq completions (take completions-list-max completions))))
+
(cond
(aff-fun
(setq completions
@@ -2661,7 +2685,7 @@ minibuffer-completion-help
(if (eq (car bounds) (length result))
'exact 'finished))))))
- (display-completion-list completions nil group-fun)
+ (display-completion-list completions nil group-fun full-count)
(when current-candidate-and-offset
(with-current-buffer standard-output
(when-let* ((match (text-property-search-forward
--
2.39.3
--=-=-=--
Spencer Baugh <sbaugh@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#74561; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.