From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 27 15:25:29 2024 Received: (at submit) by debbugs.gnu.org; 27 Nov 2024 20:25:29 +0000 Received: from localhost ([127.0.0.1]:34765 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tGObI-0000MH-HT for submit@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 ) id 1tGObF-0000M5-LX for submit@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 ) id 1tGObE-0004qS-01 for bug-gnu-emacs@gnu.org; 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 ) id 1tGObC-0001fS-5t for bug-gnu-emacs@gnu.org; Wed, 27 Nov 2024 15:25:23 -0500 From: Spencer Baugh To: bug-gnu-emacs@gnu.org Subject: [PATCH] Allow limiting the size of *Completions* Date: Wed, 27 Nov 2024 15:25:19 -0500 Message-ID: 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@janestreet.com; 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@gutov.dev, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 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 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 27 18:23:22 2024 Received: (at 74561) by debbugs.gnu.org; 27 Nov 2024 23:23:22 +0000 Received: from localhost ([127.0.0.1]:35448 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tGRNR-0001HK-SW for submit@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 ) id 1tGRNQ-0001HC-9R for 74561@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 To: Spencer Baugh , "74561@debbugs.gnu.org" <74561@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: References: In-Reply-To: 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@gutov.dev" , "juri@linkov.net" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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'. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 28 01:44:24 2024 Received: (at 74561) by debbugs.gnu.org; 28 Nov 2024 06:44:24 +0000 Received: from localhost ([127.0.0.1]:36148 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tGYGG-0006Rm-3W for submit@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 ) id 1tGYGC-0006RU-T3 for 74561@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 ) 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@gnu.org> From: Eli Zaretskii To: Spencer Baugh , Stefan Monnier In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* References: X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 74561 Cc: dmitry@gutov.dev, 74561@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) (Adding Stefan to the discussion.) > Cc: dmitry@gutov.dev, juri@linkov.net > 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" > > >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? From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 28 13:37:11 2024 Received: (at submit) by debbugs.gnu.org; 28 Nov 2024 18:37:11 +0000 Received: from localhost ([127.0.0.1]:39699 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tGjO3-0001ia-7g for submit@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 ) id 1tGjO1-0001iP-M1 for submit@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 ) id 1tGjNz-0006CE-Gd for bug-gnu-emacs@gnu.org; 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 ) id 1tGjNv-0004fM-Lo for bug-gnu-emacs@gnu.org; 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 To: Spencer Baugh Subject: Re: [PATCH] Allow limiting the size of *Completions* In-Reply-To: (Spencer Baugh's message of "Wed, 27 Nov 2024 15:25:19 -0500") Organization: LINKOV.NET References: Date: Thu, 28 Nov 2024 20:18:19 +0200 Message-ID: <877c8n45tg.fsf@mail.linkov.net> 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@linkov.net Received-SPF: pass client-ip=217.70.183.196; envelope-from=juri@linkov.net; 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@gutov.dev, bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 28 21:36:30 2024 Received: (at 74561) by debbugs.gnu.org; 29 Nov 2024 02:36:30 +0000 Received: from localhost ([127.0.0.1]:40424 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tGqru-00019G-7D for submit@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 ) id 1tGqrr-000194-0X for 74561@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 To: Juri Linkov , Spencer Baugh 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: References: <877c8n45tg.fsf@mail.linkov.net> In-Reply-To: <877c8n45tg.fsf@mail.linkov.net> 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@gutov.dev" , "74561@debbugs.gnu.org" <74561@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 28 23:13:21 2024 Received: (at 74561) by debbugs.gnu.org; 29 Nov 2024 04:13:22 +0000 Received: from localhost ([127.0.0.1]:40517 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tGsNd-0005ph-H3 for submit@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 ) id 1tGsNa-0005pQ-Ff for 74561@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 To: Spencer Baugh Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* In-Reply-To: (Spencer Baugh's message of "Wed, 27 Nov 2024 15:25:19 -0500") Message-ID: References: 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@gutov.dev, 74561@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 29 09:45:52 2024 Received: (at 74561) by debbugs.gnu.org; 29 Nov 2024 14:45:52 +0000 Received: from localhost ([127.0.0.1]:41740 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tH2Fj-0004BY-Pr for submit@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 ) id 1tH2FW-0004Ax-QH for 74561@debbugs.gnu.org; Fri, 29 Nov 2024 09:45:39 -0500 From: Spencer Baugh To: Stefan Monnier Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* In-Reply-To: (Stefan Monnier's message of "Thu, 28 Nov 2024 23:12:59 -0500") References: Date: Fri, 29 Nov 2024 09:45:33 -0500 Message-ID: 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@gutov.dev, 74561@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Stefan Monnier 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? From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 30 12:17:27 2024 Received: (at 74561) by debbugs.gnu.org; 30 Nov 2024 17:17:27 +0000 Received: from localhost ([127.0.0.1]:48867 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tHR5z-0005i6-9f for submit@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 ) id 1tHR5w-0005hp-7F for 74561@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: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrheehgdeliecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth hsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeen ucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvg hvqeenucggtffrrghtthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedt vddtveefhfdvveegudejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohep gedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepshgsrghughhhsehjrghnvghsth hrvggvthdrtghomhdprhgtphhtthhopehmohhnnhhivghrsehirhhordhumhhonhhtrhgv rghlrdgtrgdprhgtphhtthhopeejgeehieduseguvggssghughhsrdhgnhhurdhorhhgpd hrtghpthhtohepjhhurhhisehlihhnkhhovhdrnhgvth X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 30 Nov 2024 12:17:16 -0500 (EST) Message-ID: 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 , Stefan Monnier References: Content-Language: en-US From: Dmitry Gutov In-Reply-To: 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@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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). From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 01 20:57:01 2025 Received: (at control) by debbugs.gnu.org; 2 Jan 2025 01:57:01 +0000 Received: from localhost ([127.0.0.1]:41333 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tTASL-000283-Cs for submit@debbugs.gnu.org; Wed, 01 Jan 2025 20:57:01 -0500 Received: from mail-ed1-x531.google.com ([2a00:1450:4864:20::531]:61656) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tTASJ-00027X-FP for control@debbugs.gnu.org; Wed, 01 Jan 2025 20:56:59 -0500 Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-5d3f28a4fccso16951616a12.2 for ; Wed, 01 Jan 2025 17:56:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735783013; x=1736387813; darn=debbugs.gnu.org; h=to:subject:message-id:date:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=Udqf18CyeJsGUhAqcFNGXQtBpff3tFsX7R5BC4tXWAQ=; b=WJQFC917MmQ4NKG651k6buRszkc52/U1X6dSgvupsOxOu0X4ykfRfCrhBFdBk3vAR9 Y3ybjrd9/BS6QMcEleRmMO30Ca4PfWtDT/bt78txYiLvFskaHCW32mG/Bok7hlO7au1D 5wIUi6WlnX+T3yn6N7LFLXhtt/7CSu4T2t4wanxdy+8iYujURqUP/CliF4S7CuSkxo2H cNfnRZlWRfU0RF0xriGvzfixNbefRRdOH7au5hqBr/K4jTb7Ozmk9hZfvVG6cLUVhGuE 4kV0nlCRilv+QAHYfp59DkcVSlAYGBm3Si3Ap3eQLE0z4We/8xj7HSMTgzOZcaey8EIZ cX6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735783013; x=1736387813; h=to:subject:message-id:date:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Udqf18CyeJsGUhAqcFNGXQtBpff3tFsX7R5BC4tXWAQ=; b=Qhwo0NPhQVFi3GiBJuBJJJVm6AohQ9QSeNSDTS8dz6Cx1KJ677TtpfNjt0qzgu4UfS fmTi3Mcq8AFf3HcLiIwReJJfFnhqc8rnsqofPoJqEPBznqlhZekGwHZ+zXAXEz5rsVQg TsZG8pMGG6qMlf7Aqqqb+AP9eT4TSbihtmR4bAczYstlq+oJjIlQgbU5QyKaW4Ww+23m 6ka2Q9HhiBimYy2W6IhKSU5ikBg1240COP37ZEnJc3xQMSf5yeBYYkPKozKsSxzHscN0 H9lRQLQ+y8oPRw9tKIYauk8bAz5YrC+gaASKdEp/H4pZPCa8AU1Ups9mtSTdrEOveSyB 0J1Q== X-Gm-Message-State: AOJu0YzPSkGfWdpHbizxss82dxXVUSmu9KcrISsnTIN4d9eOEY3ZGXLu PKl6Dd3jhHgoJIrI6r9yODpvUTeTYm7soaagaET6EaqFewF/XrRnMigkcfSLxO1QSF3c7T3RW3X jdM/V3VIZmaK1EWSYKLVmjddxSJQUt/rO X-Gm-Gg: ASbGnctlG5nNVGx1vyKEnMSENnLvAwzRV+WVr5zxwpnn49rIoLncbHxOTE1oRuzZ/UB Q7r//Sd7rQZGv1kPsHpQXwfYH3gOo9Xgbdz97aVuY X-Google-Smtp-Source: AGHT+IGDQNnTES1mmfq5RCUkcNSooGVwYF317zWNezSNtt8bWc0Ma5OLWAlom+bEiYYtBPA3A9ksc9VqDx775fvGJb0= X-Received: by 2002:a05:6402:4402:b0:5cf:e9d6:cc8a with SMTP id 4fb4d7f45d1cf-5d81dda9256mr39544462a12.20.1735783013371; Wed, 01 Jan 2025 17:56:53 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Wed, 1 Jan 2025 19:56:53 -0600 From: Stefan Kangas MIME-Version: 1.0 Date: Wed, 1 Jan 2025 19:56:53 -0600 Message-ID: Subject: control message for bug #74561 To: control@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) severity 74561 wishlist quit From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 14:40:02 2025 Received: (at 74561) by debbugs.gnu.org; 13 Jan 2025 19:40:02 +0000 Received: from localhost ([127.0.0.1]:52921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXQI5-0007H3-CX for submit@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 ) id 1tXQI1-0007Gn-Vf for 74561@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@catern.com; 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@catern.com Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* In-Reply-To: (Spencer Baugh's message of "Fri, 29 Nov 2024 09:45:33 -0500") References: Date: Mon, 13 Jan 2025 19:39:50 +0000 (UTC) Message-ID: <87r056ijui.fsf@catern.com> 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 X-Entity-ID: u001.oW4JupFKOzCccZAQN2OOFQ== Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74561 Cc: dmitry@gutov.dev, 74561@debbugs.gnu.org, Stefan Monnier , juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Spencer Baugh writes: > Stefan Monnier 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 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 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 11 10:03:42 2025 Received: (at 74561) by debbugs.gnu.org; 11 Feb 2025 15:03:42 +0000 Received: from localhost ([127.0.0.1]:58004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1thrnZ-0005B6-Nn for submit@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 ) id 1thrnV-0005An-Qk for 74561@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@catern.com; 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@catern.com Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* In-Reply-To: <87r056ijui.fsf@catern.com> (sbaugh@catern.com's message of "Mon, 13 Jan 2025 19:39:50 +0000 (UTC)") References: <87r056ijui.fsf@catern.com> Date: Tue, 11 Feb 2025 15:03:31 +0000 (UTC) Message-ID: <8734gka5h9.fsf@catern.com> 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 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=?= , dmitry@gutov.dev, 74561@debbugs.gnu.org, Stefan Monnier , juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 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 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 11 10:34:37 2025 Received: (at 74561) by debbugs.gnu.org; 11 Feb 2025 15:34:37 +0000 Received: from localhost ([127.0.0.1]:58102 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1thsHV-0006kY-16 for submit@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 ) id 1thsHQ-0006kG-M1 for 74561@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 ) 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@gnu.org> From: Eli Zaretskii To: sbaugh@catern.com In-Reply-To: <8734gka5h9.fsf@catern.com> (sbaugh@catern.com) Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* References: <87r056ijui.fsf@catern.com> <8734gka5h9.fsf@catern.com> 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@janestreet.com, juri@linkov.net, dmitry@gutov.dev, joaotavora@gmail.com, 74561@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > Cc: João Távora , > dmitry@gutov.dev, 74561@debbugs.gnu.org, > Stefan Monnier , juri@linkov.net > From: sbaugh@catern.com > 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 11 14:44:55 2025 Received: (at 74561) by debbugs.gnu.org; 11 Feb 2025 19:44:55 +0000 Received: from localhost ([127.0.0.1]:58821 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1thwBi-0007oE-FU for submit@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 ) id 1thwBf-0007ny-VY for 74561@debbugs.gnu.org; Tue, 11 Feb 2025 14:44:53 -0500 From: Spencer Baugh To: Eli Zaretskii Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* In-Reply-To: <86lducwl51.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 11 Feb 2025 17:34:18 +0200") References: <87r056ijui.fsf@catern.com> <8734gka5h9.fsf@catern.com> <86lducwl51.fsf@gnu.org> Date: Tue, 11 Feb 2025 14:44:46 -0500 Message-ID: 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@catern.com, juri@linkov.net, dmitry@gutov.dev, joaotavora@gmail.com, 74561@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eli Zaretskii writes: >> Cc: Jo=C3=A3o T=C3=A1vora , >> dmitry@gutov.dev, 74561@debbugs.gnu.org, >> Stefan Monnier , juri@linkov.net >> From: sbaugh@catern.com >> 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 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 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 11 15:07:22 2025 Received: (at 74561) by debbugs.gnu.org; 11 Feb 2025 20:07:22 +0000 Received: from localhost ([127.0.0.1]:58922 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1thwXR-0006dL-HM for submit@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 ) id 1thwXO-0006d4-NH for 74561@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@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 In-Reply-To: References: <87r056ijui.fsf@catern.com> <8734gka5h9.fsf@catern.com> <86lducwl51.fsf@gnu.org> MIME-Version: 1.0 Date: Tue, 11 Feb 2025 12:07:11 -0800 X-Gm-Features: AWEUYZm-Phu35B94udX7DEZ0LSpUloMPI6ZG7-OuWx49l22pJmlOsFh1u2WlCnQ Message-ID: Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* To: Spencer Baugh , Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74561 Cc: sbaugh@catern.com, juri@linkov.net, dmitry@gutov.dev, joaotavora@gmail.com, 74561@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" 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? From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 12 07:11:15 2025 Received: (at 74561) by debbugs.gnu.org; 12 Feb 2025 12:11:15 +0000 Received: from localhost ([127.0.0.1]:33046 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tiBaB-00054L-H9 for submit@debbugs.gnu.org; Wed, 12 Feb 2025 07:11:15 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58748) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tiBa7-00053S-Fc for 74561@debbugs.gnu.org; Wed, 12 Feb 2025 07:11:08 -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 ) id 1tiBZz-0008Ez-IH; Wed, 12 Feb 2025 07:10:59 -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=n6Y8pQQtFDVeXv6rqbXKGX1kqcGXYlzz2ZjSwnXWxws=; b=biWj5Lnm5qVVZSwQXxEj L1UwY6jiNIVoyO5hGO35tQBt/j0q6m1c5d85a6ABX8XHSH+B3IDXUGFLJguN0/5yBxrW+SNf2X2F+ Yh4t0VCrC2Pi1RdQIFAm/nxl4RN7leQ7ECu6RCTaYuW54hdOM1oKb2qqYJns1v1nqOqaf6C9m56ss G/HNf+2UCsB4iCYyNqwT1Qx7L3FYaLmTCqO/LedbUVdInfCd4bPR3wWrw3Jhz/TbtIZ1yf0QGCdhI ufJj64PIX6/LGXCPHHw/HFQeYaV/K0wsStMUCCXZ+8lgpR0AFlMwNUs829Sgs7YatgMxAVe/5Ipxj SNTR4wdky3d+2w==; Date: Wed, 12 Feb 2025 14:10:21 +0200 Message-Id: <8634gjwehe.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Tue, 11 Feb 2025 14:44:46 -0500) Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* References: <87r056ijui.fsf@catern.com> <8734gka5h9.fsf@catern.com> <86lducwl51.fsf@gnu.org> 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@catern.com, juri@linkov.net, dmitry@gutov.dev, joaotavora@gmail.com, 74561@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) > From: Spencer Baugh > Cc: sbaugh@catern.com, juri@linkov.net, dmitry@gutov.dev, > joaotavora@gmail.com, 74561@debbugs.gnu.org, monnier@iro.umontreal.ca > Date: Tue, 11 Feb 2025 14:44:46 -0500 > > Eli Zaretskii writes: > > >> Cc: João Távora , > >> dmitry@gutov.dev, 74561@debbugs.gnu.org, > >> Stefan Monnier , juri@linkov.net > >> From: sbaugh@catern.com > >> 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? > > Nope, no user-facing behavior changes. The NEWS entry seems to imply that the behavior did change. So either the NEWS entry needs to be augmented, or there's some misunderstanding between us regarding what "behavior change" means. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 14 15:54:54 2025 Received: (at 74561) by debbugs.gnu.org; 14 Feb 2025 20:54:54 +0000 Received: from localhost ([127.0.0.1]:52034 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tj2i5-0007z1-3y for submit@debbugs.gnu.org; Fri, 14 Feb 2025 15:54:53 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:55363) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tj2i2-0007yl-52 for 74561@debbugs.gnu.org; Fri, 14 Feb 2025 15:54:51 -0500 From: Spencer Baugh To: Stefan Kangas Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* In-Reply-To: (Stefan Kangas's message of "Tue, 11 Feb 2025 12:07:11 -0800") References: <87r056ijui.fsf@catern.com> <8734gka5h9.fsf@catern.com> <86lducwl51.fsf@gnu.org> Date: Fri, 14 Feb 2025 15:54:44 -0500 Message-ID: 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=1739566484; bh=XaN181NacMCz50Hy7f36H0423QeU46aHo+Y1yLzVurc=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=SdSEjp9iKe4nwDZUUGYa/zQ6r3hhhYPowsWME0AhQK/C3Og6JKoS7jQZDD9JEpjhi 9nKp+uLbtLYcILJoijOk0JFEZBsZ/m2NMAnF/14XwUSzAYiDE5hb3R1O1yN9HE34xb OrHw28PA44nsGn+n8u1yL0A6wohbX3s87bX4SHh1p8GZUTyO7++gylpd2TbfnCNH1W WiKJuvbkKvX2OoxWEidjSMbWZEvSIaNMsIh8cdPBmZeKcTRn5v+orZ8qsewSKSo7CR pt4NEIlmx5EB4Vnx955G9rlppqmotiEMGn2II3gNwKXu3i2ivDiw2E/dCHK/9e/QoH kIc4I5OjdsAtw== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74561 Cc: sbaugh@catern.com, juri@linkov.net, dmitry@gutov.dev, joaotavora@gmail.com, Eli Zaretskii , 74561@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain Stefan Kangas writes: > Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of > text editors" 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? Yes, good point, it definitely should be calculated dynamically. The easiest way to do this correctly is to insert completion candidates until we have at least frame-height lines in the *Completions* buffer. Then no matter how the window gets resized afterwards (and it will indeed be resized, by fit-window-to-buffer) there will be enough completion candidates that the displayed part of the window is full. I've done this in the attached patch. In the process, I realized that this optimization doesn't help completions-format=vertical without a lot of effort, since that fills the entire first column before continuing to the second column. That's fine, the optimization works for other values of completions-format, and I can straightforwardly extend the optimization to completions-format=vertical in later changes. I've also updated NEWS to be more clear about the lack of user-facing behavior changes. BTW, the current implementation uses throw and catch to interrupt the process of inserting completions when enough have been inserted. This opens up the possibility of further optimization later: instead of throwing the symbol "truncated" as I do now, I could throw a function, a continuation which could be called to continue inserting the completions from where I left off. That would avoid duplicating some work, and therefore make things even faster. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Lazily-highlight-and-insert-candidates-in-Completion.patch >From 3641bb9cb64b671ca0abd846b1b32d760884bb43 Mon Sep 17 00:00:00 2001 From: Spencer Baugh 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) (completion--newline, completions--lazy-insert-button): Add. (completion--insert-horizontal, completion--insert-vertical) (completion--insert-one-column): Add LINES argument. (completion--insert): Call completion-lazy-hilit. (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 | 64 +++++++++++++++++++++++++++++++++++++++------- lisp/simple.el | 5 +++- 3 files changed, 69 insertions(+), 10 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index 9fe46d818bd..f9cb7b4a247 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. +As always, if there are more completion candidates than can be displayed +in the current frame, only a subset of the candidates is displayed. +This process is now faster: only that subset of the candidates is +actually inserted into "*Completions*" until you run a command which +interacts with the text of the "*Completions*" buffer. This +optimization only applies when 'completions-format' is 'horizontal' or +'one-column'. + ** Windows +++ diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index b401e4a920c..af13cb8d79a 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -2230,6 +2230,15 @@ completions-header-format (string :tag "Format string for heading line")) :version "29.1") +(defvar-local completions--lazy-insert-button nil) + +(defvar completion--insert-strings-lazily t + "If non-nil, `completion--insert-strings' inserts strings lazily. + +Candidate strings are inserted until the buffer contents has enough +lines to fill the current frame. The remainder will be inserted by +`completion--lazy-insert-strings'.") + (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,18 +2260,53 @@ 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)) + (lines (when completion--insert-strings-lazily (frame-height)))) (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)))) - (funcall (intern (format "completion--insert-%s" completions-format)) - strings group-fun length wwidth colwidth columns)))) + (let ((start (point)) + (truncated + (catch 'completions-truncated + (funcall (intern (format "completion--insert-%s" completions-format)) + strings group-fun length wwidth colwidth columns lines)))) + (when (eq truncated 'truncated) + (newline) + ;; If there's a bug which causes us to not insert the remaining + ;; completions automatically, the user can at least press this button. + (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 ((completion--insert-strings-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--newline (wanted-lines) + "Insert a newline and throw if there are more than WANTED-LINES." + (newline) + (when (and wanted-lines (> (line-number-at-pos) wanted-lines)) + (throw 'completions-truncated 'truncated))) (defun completion--insert-horizontal (strings group-fun length wwidth - colwidth _columns) + colwidth _columns lines) (let ((column 0) (first t) (last-title nil) @@ -2286,7 +2330,7 @@ completion--insert-horizontal (apply #'+ (mapcar #'string-width str)) (string-width str))))) ;; No space for `str' at point, move to next line. - (progn (insert "\n") (setq column 0)) + (progn (completion--newline lines) (setq column 0)) (insert " \t") ;; Leave the space unpropertized so that in the case we're ;; already past the goal column, there is still @@ -2307,7 +2351,7 @@ completion--insert-horizontal (defun completion--insert-vertical (strings group-fun _length _wwidth - colwidth columns) + colwidth columns _lines) (while strings (let ((group nil) (column 0) @@ -2357,7 +2401,7 @@ completion--insert-vertical (insert "\n")) (setq row (1+ row))))))) -(defun completion--insert-one-column (strings group-fun &rest _) +(defun completion--insert-one-column (strings group-fun _length _wwidth _colwidth _columns lines) (let ((last-title nil) (last-string nil)) (dolist (str strings) (unless (equal last-string str) ; Remove (consecutive) duplicates. @@ -2369,14 +2413,14 @@ completion--insert-one-column (when title (insert (format completions-group-format title) "\n"))))) (completion--insert str group-fun) - (insert "\n"))) + (completion--newline lines))) (delete-char -1))) (defun completion--insert (str group-fun) (if (not (consp str)) (add-text-properties (point) - (progn + (let ((str (completion-lazy-hilit str))) (insert (if group-fun (funcall group-fun str 'transform) @@ -2644,6 +2688,7 @@ minibuffer-completion-help (end (or end (point-max))) (string (buffer-substring start end)) (md (completion--field-metadata start)) + (completion-lazy-hilit t) (completions (completion-all-completions string minibuffer-completion-table @@ -4986,6 +5031,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..c7742689897 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 completions--lazy-insert-button)) (completion-list-mode) (when completions-highlight-face (setq-local cursor-face-highlight-nonselected-window t)) + (setq-local completions--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 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 14 17:05:21 2025 Received: (at 74561) by debbugs.gnu.org; 14 Feb 2025 22:05:22 +0000 Received: from localhost ([127.0.0.1]:52123 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tj3oH-00062T-Lb for submit@debbugs.gnu.org; Fri, 14 Feb 2025 17:05:21 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:28906) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tj3oD-00062B-BA for 74561@debbugs.gnu.org; Fri, 14 Feb 2025 17:05:19 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B6967100154; Fri, 14 Feb 2025 17:05:11 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1739570710; bh=l+FlEv7FzOXq8LVsJSnUnudipeSac/ofSoCwfE13INQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=c6PeGkLKTYwCOEiI+4fGdPgVSRUey0DrrzBdtXiEW+NBaX/xXb4xCi3+5H+YqlHgS aEZ14cJQLxYibVn82oX7BTZugP6o1STM2oOrkWlt7dF8gCe4QPWqle1ZBuH40S9BqQ rzp1BKGbnb569e8V3uUeFpI6YtdHhh4yLWGaE8Ip1G2SieU7hVzi954r3SxGUlHpgt lX8AFxqLrbEZxiLku1BbTKel6N57A/VV52mV8fB2VD6hxa+LCqylkDa5pALkCaTOhm aeh/gcR/UDtBYkPddFBYKSjTHWckuhrOKAKlAS1m5xBj91ODhsqF2DRQzbmkI+4WEp 5wtUzJmwer8pg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C691A100035; Fri, 14 Feb 2025 17:05:10 -0500 (EST) Received: from pastel (unknown [104.247.242.5]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7E81212005D; Fri, 14 Feb 2025 17:05:10 -0500 (EST) From: Stefan Monnier To: Spencer Baugh Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* In-Reply-To: (Spencer Baugh's message of "Fri, 14 Feb 2025 15:54:44 -0500") Message-ID: References: <87r056ijui.fsf@catern.com> <8734gka5h9.fsf@catern.com> <86lducwl51.fsf@gnu.org> Date: Fri, 14 Feb 2025 17:05:09 -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 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: sbaugh@catern.com, juri@linkov.net, dmitry@gutov.dev, joaotavora@gmail.com, Eli Zaretskii , 74561@debbugs.gnu.org, Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > In the process, I realized that this optimization doesn't help > completions-format=vertical without a lot of effort, since that fills > the entire first column before continuing to the second column. FWIW, maybe we should change this behavior so instead of filling column-by-column we fill line-by-line. When the result completely fits in the *Completions* window, the current behavior is arguably superior (assuming alphabetical sorting: it tends to make it easier to see the common prefixes), but for longer completion lists I don't like it very much. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 15 09:37:29 2025 Received: (at 74561) by debbugs.gnu.org; 15 Feb 2025 14:37:30 +0000 Received: from localhost ([127.0.0.1]:54081 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tjJIO-0001BD-Mo for submit@debbugs.gnu.org; Sat, 15 Feb 2025 09:37:29 -0500 Received: from s.wrqvtbkv.outbound-mail.sendgrid.net ([149.72.123.24]:33208) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tjJIM-0001Aw-3G for 74561@debbugs.gnu.org; Sat, 15 Feb 2025 09:37:26 -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: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=nwayyyS2YEXUvT933Lfh0QtYCX0C/96sZamtTh1pPdc=; b=Lsr2glyPFkMwlHnIjOr4PdaUjuucR6whWIl+XH/VVvWPRJLlm2/5mBV5ZZrpVkRll5E3 NQYLlBEoYEu+wu2L6bR3JacRP7rNweBttbQo/O9nCds6xTZfZnktfg49uhlnz1jxo2khd1 LyxWkReXUSb8q1nhWQBlRaSWJjrnPQUt503/1+yDj8wYFGvBKY9JpM6pHK6Ja6kmTsrEwx MhLQd+NbnEMoH4rbrTwJenE23oWdzA6KoPC1JDgnVSTZN7607tMVem0lBB0NmT6B1HwizH 5GxiMJlbtykRBHnXrEze6Og2Zdlb55SIynHyo7gYWjQqZ/zb/fZfqclzfVnmp7yA== Received: by recvd-69cbc48b94-cc5f7 with SMTP id recvd-69cbc48b94-cc5f7-1-67B0A6A0-F 2025-02-15 14:37:20.247048437 +0000 UTC m=+8010777.526802664 Received: from earth.catern.com (unknown) by geopod-ismtpd-17 (SG) with ESMTP id cKPrR1O6Sti3l4LOOioUGQ Sat, 15 Feb 2025 14:37:20.104 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=127.0.0.1; helo=localhost; envelope-from=sbaugh@catern.com; receiver=iro.umontreal.ca Received: from localhost (localhost [127.0.0.1]) by earth.catern.com (Postfix) with ESMTPSA id 6A3F560154; Sat, 15 Feb 2025 09:37:19 -0500 (EST) From: Spencer Baugh Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* In-Reply-To: References: <87r056ijui.fsf@catern.com> <8734gka5h9.fsf@catern.com> <86lducwl51.fsf@gnu.org> Date: Sat, 15 Feb 2025 14:37:20 +0000 (UTC) Message-ID: <87y0y78eao.fsf@catern.com> MIME-Version: 1.0 X-SG-EID: =?us-ascii?Q?u001=2ENz+HMmDcsM8qhRi=2Fi6l=2F+K9+Alj0GzpTFMB942b8RB9iS3mO4LgRspB0E?= =?us-ascii?Q?Ies5DXpew3WGLZfkYr7CnH+lQWJZ+A+G4Sc8zxN?= =?us-ascii?Q?QMTm4lX42F2W5NwO16XytG3j80tx9J2SgdKtdsM?= =?us-ascii?Q?C+hbGlCT9baNFimR+V0RqC+f37oHXSYnWhEw82w?= =?us-ascii?Q?+fUHnmE1YVyzEXPydzPQu5YhwF5vMbGFS705EgJ?= =?us-ascii?Q?JIM8h6anp5nmVRHpOIdDnX6t8sNcRvP1qqOZM6H?= =?us-ascii?Q?MzL4?= To: Stefan Monnier , Spencer Baugh X-Entity-ID: u001.oW4JupFKOzCccZAQN2OOFQ== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Stefan Monnier writes: >> In the process, I realized that this optimization doesn't help >> completions-format=vertical without a lot of effort, since that fills >> the enti [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [149.72.123.24 listed in bl.score.senderscore.com] 0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [149.72.123.24 listed in sa-trusted.bondedsender.org] 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [149.72.123.24 listed in wl.mailspike.net] 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 RCVD_IN_MSPIKE_BL Mailspike blocklisted 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 0.0 RCVD_IN_MSPIKE_ZBI No description available. X-Debbugs-Envelope-To: 74561 Cc: 74561@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Stefan Monnier writes: >> In the process, I realized that this optimization doesn't help >> completions-format=vertical without a lot of effort, since that fills >> the entire first column before continuing to the second column. > > FWIW, maybe we should change this behavior so instead of filling > column-by-column we fill line-by-line. > > When the result completely fits in the *Completions* window, the current > behavior is arguably superior (assuming alphabetical sorting: it tends > to make it easier to see the common prefixes), but for longer > completion lists I don't like it very much. I'm not sure what you mean. completions-format=vertical looks like: A D G B E H C F I completions-format=horizontal looks like: A B C D E F G H I Is your suggestion that completions-format=vertical should look like the second one? But then what would be the point of it as a separate category? From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 15 10:06:27 2025 Received: (at 74561) by debbugs.gnu.org; 15 Feb 2025 15:06:27 +0000 Received: from localhost ([127.0.0.1]:57371 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tjJkQ-0003P6-UJ for submit@debbugs.gnu.org; Sat, 15 Feb 2025 10:06:27 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:40384) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tjJkL-0003Ol-6T for 74561@debbugs.gnu.org; Sat, 15 Feb 2025 10:06:24 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0FC70801B8; Sat, 15 Feb 2025 10:06:14 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1739631967; bh=wNNbIRtbQMA1KfQLs5W9x72i4v+RY7quea/IBGzM2q0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mhkzStZpkhvSXChRuj3N1DosWBZwXTdOu6yHERBPvqAbG22rptqu9Fya6qBwESSHs LbOqE+nE7YUHEGgWUr9wrp0hc0e0nfudOvsG6RqaI7/oZfdYDaS0vUZ+yToi8cj6xC 7MR1/5bd7S5zX3m70IiKb6cWC7q2yLsMvzDacqqQ3qSVLgvwaZuUWqX6jllwoWZOhP 74go3O1WeGLJpOSaXh1MV3RtR0FNYFAEHKMN6Pat9aRbg3yKpuyy9Q+eCNyDi/shRE gxikuFAuLEvIO2fkpCpqea93YH+AMLALN0JCyBzAmI79mE7xddfu4GPOM9x2iO8+K/ 8aMRRy09QY7Dw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6F03E804D9; Sat, 15 Feb 2025 10:06:07 -0500 (EST) Received: from pastel (unknown [104.247.242.5]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3F6A8120372; Sat, 15 Feb 2025 10:06:07 -0500 (EST) From: Stefan Monnier To: Spencer Baugh Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* In-Reply-To: <87y0y78eao.fsf@catern.com> (Spencer Baugh's message of "Sat, 15 Feb 2025 14:37:20 +0000 (UTC)") Message-ID: References: <87r056ijui.fsf@catern.com> <8734gka5h9.fsf@catern.com> <86lducwl51.fsf@gnu.org> <87y0y78eao.fsf@catern.com> Date: Sat, 15 Feb 2025 10:06:06 -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.137 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: Spencer Baugh , 74561@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > I'm not sure what you mean. That's because I was confused. > completions-format=vertical looks like: > A D G > B E H > C F I > > completions-format=horizontal looks like: > A B C > D E F > G H I Ah, right I forgot we have both settings. > Is your suggestion that completions-format=vertical should look like the > second one? No, I was just noticing that I like `vertical` when it all fits on screen, but that I prefer `horizontal` when the list is long. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 15 12:50:23 2025 Received: (at 74561) by debbugs.gnu.org; 15 Feb 2025 17:50:23 +0000 Received: from localhost ([127.0.0.1]:57790 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tjMJ5-0000cz-1O for submit@debbugs.gnu.org; Sat, 15 Feb 2025 12:50:23 -0500 Received: from relay8-d.mail.gandi.net ([217.70.183.201]:44647) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tjMIj-0000Vn-NT for 74561@debbugs.gnu.org; Sat, 15 Feb 2025 12:50:02 -0500 Received: by mail.gandi.net (Postfix) with ESMTPSA id BB5E544424; Sat, 15 Feb 2025 17:49:52 +0000 (UTC) From: Juri Linkov To: Stefan Monnier Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* In-Reply-To: Organization: LINKOV.NET References: <87r056ijui.fsf@catern.com> <8734gka5h9.fsf@catern.com> <86lducwl51.fsf@gnu.org> Date: Sat, 15 Feb 2025 19:45:06 +0200 Message-ID: <87bjv3hzkt.fsf@mail.linkov.net> 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-State: clean X-GND-Score: -100 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdehfedukecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfitefpfffkpdcuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefujghofhffkfgfgggtsehttdertddtredtnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecuggftrfgrthhtvghrnhepffegteefveelhfeljeefueehieduiedtfffhuddtkeeffffghfevheetgeeukeehnecukfhppeeluddruddvledrleekrdehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepledurdduvdelrdelkedrhedphhgvlhhopehmrghilhdrghgrnhguihdrnhgvthdpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnsggprhgtphhtthhopeekpdhrtghpthhtohepjeegheeiudesuggvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopehjohgrohhtrghvohhrrgesghhmrghilhdrtghomhdprhgtphhtthhopegumhhithhrhiesghhuthhovhdruggvvhdprhgtphhtthhopehssggruhhghhestggrthgvrhhnrdgtohhmpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtohepshhtvghfrghnkhgrnhhgrghssehgmhgrihhlrdgtohhmpdhrtghpthhtohepshgsrghughhhsehjr ghnvghsthhrvggvthdrtghomhdprhgtphhtthhopehmohhnnhhivghrsehirhhordhumhhonhhtrhgvrghlrdgtrg X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 74561 Cc: Spencer Baugh , sbaugh@catern.com, dmitry@gutov.dev, joaotavora@gmail.com, Eli Zaretskii , 74561@debbugs.gnu.org, Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> In the process, I realized that this optimization doesn't help >> completions-format=vertical without a lot of effort, since that fills >> the entire first column before continuing to the second column. > > FWIW, maybe we should change this behavior so instead of filling > column-by-column we fill line-by-line. I think this is exactly how we should improve completion--insert-vertical. Instead of filling the first column before continuing to the second column the algorithm could be changed to: 1. partition the list of completions (e.g. by `seq-partition`) into N groups corresponding to columns; 2. then take the first elements from each sublist while laying them out line-by-line. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 16 11:35:32 2025 Received: (at 74561) by debbugs.gnu.org; 16 Feb 2025 16:35:32 +0000 Received: from localhost ([127.0.0.1]:36553 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tjhcC-0002Vx-31 for submit@debbugs.gnu.org; Sun, 16 Feb 2025 11:35:32 -0500 Received: from s.wrqvwxzv.outbound-mail.sendgrid.net ([149.72.154.232]:45396) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tjhc7-0002Vh-UZ for 74561@debbugs.gnu.org; Sun, 16 Feb 2025 11:35:29 -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: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=9l6QcDmaxe/3Z9QREX5XTG2zds4JiOU5yjpbLUm++gk=; b=cv9nkhSDH3l37O4C0NVjh7tGQLKqut5FP6KNic8RvRjW20o35sIqCID4WZ5IiaOh/zTb FMd7KZOlh1pGwX7iXiKQ+paf4JGqySa1npLsXMkG3X8jwmOM+l+VJh93BSA1u1tkZImMqG XEiMGn+eUh3u4JwwiGkNVKX2yrA7Iv3BGrCcIU60GD6jXgCVRr6dkMbtA+d2OxZQVn2gRG y9dgdj6xBieU2pDPUKLgw47Ljp/ZJNvFPFCvgr5eh1HARAxqqWI7P8ae4yLzTsfWfEK5kt 5iMEfFI+Jlw2aQV6a1ljenZc258ETOSfnK8UxinAa0+aOb4Goy0t0/ymP1zlDuFQ== Received: by recvd-84b546689d-xhmms with SMTP id recvd-84b546689d-xhmms-1-67B213C9-6 2025-02-16 16:35:21.552930634 +0000 UTC m=+8104353.488231235 Received: from earth.catern.com (unknown) by geopod-ismtpd-31 (SG) with ESMTP id zy-AI8ZGRnGG8wo1uIIpPw Sun, 16 Feb 2025 16:35:21.354 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=127.0.0.1; helo=localhost; envelope-from=sbaugh@catern.com; receiver=linkov.net Received: from localhost (localhost [127.0.0.1]) by earth.catern.com (Postfix) with ESMTPSA id 994046016A; Sun, 16 Feb 2025 11:35:20 -0500 (EST) From: Spencer Baugh Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* In-Reply-To: <87bjv3hzkt.fsf@mail.linkov.net> References: <87r056ijui.fsf@catern.com> <8734gka5h9.fsf@catern.com> <86lducwl51.fsf@gnu.org> <87bjv3hzkt.fsf@mail.linkov.net> Date: Sun, 16 Feb 2025 16:35:21 +0000 (UTC) Message-ID: <87tt8t97av.fsf@catern.com> MIME-Version: 1.0 X-SG-EID: =?us-ascii?Q?u001=2ENz+HMmDcsM8qhRi=2Fi6l=2F+K9+Alj0GzpTFMB942b8RB9iS3mO4LgRspB0E?= =?us-ascii?Q?Ies5DXpew3WGLZfkYr7CnH+lQWJZ0t=2FztxjIaFp?= =?us-ascii?Q?RcIHqQMiQUM054e3Flu82DQwa3loeF=2FrnoBhNSY?= =?us-ascii?Q?05AGqO1UjK0AmEEr4p8n7Aonu+mTdjQDdw5RYTw?= =?us-ascii?Q?ggwaIO53+Ye7GYTPPgLXBT6M1ugE4iy1LtCDVbB?= =?us-ascii?Q?dcm+wZbJCPy0RJc87igEE9NzATxd=2F+xAdFa18tP?= =?us-ascii?Q?uQ1W?= To: Juri Linkov , Stefan Monnier X-Entity-ID: u001.oW4JupFKOzCccZAQN2OOFQ== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 74561 Cc: Spencer Baugh , dmitry@gutov.dev, joaotavora@gmail.com, Eli Zaretskii , 74561@debbugs.gnu.org, Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) Juri Linkov writes: >>> In the process, I realized that this optimization doesn't help >>> completions-format=vertical without a lot of effort, since that fills >>> the entire first column before continuing to the second column. >> >> FWIW, maybe we should change this behavior so instead of filling >> column-by-column we fill line-by-line. > > I think this is exactly how we should improve completion--insert-vertical. > Instead of filling the first column before continuing to the second column > the algorithm could be changed to: > > 1. partition the list of completions (e.g. by `seq-partition`) > into N groups corresponding to columns; > 2. then take the first elements from each sublist > while laying them out line-by-line. I can do this, but just to warn you, this will require essentiallya complete rewrite of completion--insert-vertical. So the patch is going to become a lot larger. I suggest we should land the optimization for completion--insert-horizontal and completion--insert-one-column first, since those require smaller changes. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 16 12:00:26 2025 Received: (at 74561) by debbugs.gnu.org; 16 Feb 2025 17:00:26 +0000 Received: from localhost ([127.0.0.1]:36645 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tji0I-0003hO-A2 for submit@debbugs.gnu.org; Sun, 16 Feb 2025 12:00:26 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:1391) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tji0G-0003h9-D9 for 74561@debbugs.gnu.org; Sun, 16 Feb 2025 12:00:25 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7529D100154; Sun, 16 Feb 2025 12:00:18 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1739725217; bh=ikxHSdJbDCaVVBi7gg+ncV7LCLX6wIKDKyrgWr5QtlA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=DNs8wbVQWRA1ikliUbZwzsqIfiaWkLUjqfZ++Im7AvIlEyb8nBeqNEtgT4QoUtnD1 wlaod3EzzqvI8eYX2rvhBek37zffRZRVXDcPi210emSBzoMCS8BRxbDUu7mL4Bbm9+ mAjeK4stOp0Wd6uXeilhtg12KHiRLWGLiP5RgElyOx4UoDVsg9hCKRd/vXmycADsRE xzvJgSqDSLW3Ug+QRi24+hfNNkRV+H3wxycDpFQTVFBJIklNy27HXhUuUhdh+zXbJB VvFaq7JSggIBP7Eygsm9jU8PkuRYZolJxwNbyQqiwmVporUGvN1g4AqfXAUstRsbp1 M3eH3GRMaKwfg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D6759100034; Sun, 16 Feb 2025 12:00:17 -0500 (EST) Received: from pastel (unknown [104.247.242.5]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6C2B51202BB; Sun, 16 Feb 2025 12:00:17 -0500 (EST) From: Stefan Monnier To: Spencer Baugh Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* In-Reply-To: <87tt8t97av.fsf@catern.com> (Spencer Baugh's message of "Sun, 16 Feb 2025 16:35:21 +0000 (UTC)") Message-ID: References: <87r056ijui.fsf@catern.com> <8734gka5h9.fsf@catern.com> <86lducwl51.fsf@gnu.org> <87bjv3hzkt.fsf@mail.linkov.net> <87tt8t97av.fsf@catern.com> Date: Sun, 16 Feb 2025 12:00:15 -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.141 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: Spencer Baugh , Juri Linkov , dmitry@gutov.dev, joaotavora@gmail.com, Eli Zaretskii , 74561@debbugs.gnu.org, Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> 1. partition the list of completions (e.g. by `seq-partition`) >> into N groups corresponding to columns; >> 2. then take the first elements from each sublist >> while laying them out line-by-line. > > I can do this, but just to warn you, this will require essentiallya > complete rewrite of completion--insert-vertical. So the patch is going > to become a lot larger. I suggest we should land the optimization for > completion--insert-horizontal and completion--insert-one-column first, > since those require smaller changes. +1 Stefan "not convinced such a rewrite is even worth the trouble, because of the increase of the costs that are proportional to the total completions" From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 16 12:40:07 2025 Received: (at 74561) by debbugs.gnu.org; 16 Feb 2025 17:40:07 +0000 Received: from localhost ([127.0.0.1]:36901 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tjicg-0006cz-Jj for submit@debbugs.gnu.org; Sun, 16 Feb 2025 12:40:07 -0500 Received: from relay9-d.mail.gandi.net ([2001:4b98:dc4:8::229]:52743) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tjicd-0006aV-Cq for 74561@debbugs.gnu.org; Sun, 16 Feb 2025 12:40:04 -0500 Received: by mail.gandi.net (Postfix) with ESMTPSA id 633BE442C1; Sun, 16 Feb 2025 17:39:53 +0000 (UTC) From: Juri Linkov To: Stefan Monnier Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* In-Reply-To: Organization: LINKOV.NET References: <87r056ijui.fsf@catern.com> <8734gka5h9.fsf@catern.com> <86lducwl51.fsf@gnu.org> <87bjv3hzkt.fsf@mail.linkov.net> <87tt8t97av.fsf@catern.com> Date: Sun, 16 Feb 2025 19:38:58 +0200 Message-ID: <87bjv1pz65.fsf@mail.linkov.net> 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-State: clean X-GND-Score: -100 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdehiedtkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfitefpfffkpdcuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefujghofhffkfgfgggtsehttdertddtredtnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecuggftrfgrthhtvghrnhepffegteefveelhfeljeefueehieduiedtfffhuddtkeeffffghfevheetgeeukeehnecukfhppeeluddruddvledrleekrdehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepledurdduvdelrdelkedrhedphhgvlhhopehmrghilhdrghgrnhguihdrnhgvthdpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnsggprhgtphhtthhopeekpdhrtghpthhtohepjeegheeiudesuggvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopehjohgrohhtrghvohhrrgesghhmrghilhdrtghomhdprhgtphhtthhopegumhhithhrhiesghhuthhovhdruggvvhdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopehsthgvfhgrnhhkrghnghgrshesghhmrghilhdrtghomhdprhgtphhtthhopehssggruhhghhesjhgrnhgvshhtrhgvvghtrdgtohhmpdhrtghpthhtohepshgsrghug hhhsegtrghtvghrnhdrtghomhdprhgtphhtthhopehmohhnnhhivghrsehirhhordhumhhonhhtrhgvrghlrdgtrg X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 74561 Cc: Spencer Baugh , Spencer Baugh , dmitry@gutov.dev, joaotavora@gmail.com, Eli Zaretskii , 74561@debbugs.gnu.org, Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>> 1. partition the list of completions (e.g. by `seq-partition`) >>> into N groups corresponding to columns; >>> 2. then take the first elements from each sublist >>> while laying them out line-by-line. >> >> I can do this, but just to warn you, this will require essentiallya >> complete rewrite of completion--insert-vertical. So the patch is going >> to become a lot larger. I suggest we should land the optimization for >> completion--insert-horizontal and completion--insert-one-column first, >> since those require smaller changes. > > +1 > > Stefan "not convinced such a rewrite is even worth the trouble, > because of the increase of the costs that are > proportional to the total completions" Maybe indeed not worth the trouble, this needs more measurements that could be postponed to later after landing the optimization for horizontal/one-column. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 04 12:33:31 2025 Received: (at 74561) by debbugs.gnu.org; 4 Mar 2025 17:33:31 +0000 Received: from localhost ([127.0.0.1]:60718 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tpW91-00033P-4z for submit@debbugs.gnu.org; Tue, 04 Mar 2025 12:33:31 -0500 Received: from s.wfbtzhsv.outbound-mail.sendgrid.net ([159.183.224.104]:64092) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tpW8q-00032t-35 for 74561@debbugs.gnu.org; Tue, 04 Mar 2025 12:33:17 -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=5DSzhQQ2BYJZLgbaVRTgbgkatvNDZ9MfpI6oOzuXSaU=; b=Op6UXqrb93vhKVbWmOHcedgYBVwDy41ssnN9hdwKY+JnBIb6cmeD6DbJwQJ0pzWozNGs ++4dwoYvKkKrP/q6g30YRRQNNuRV2uPSDqM8SVFUCVFel111DIo/+uxUg4FkA2bOwlQwyh 69XJSOyMI7QotnLZMwW4OFFrIIMp6VTY03QRiquNlVU9wNgNXGY6ary5M6Ub5rP/EL5AO1 Lv2sMdDja/GevzDJ1hfnTeZdNYR6/9GVcRIGRKDH7PIM3of9Jt7VGPeNJuQ4p8bPDVaGrw 28mLKp+45DEkM2OikvKm92MXZFW/utbBcGJmHCDcTlVTd9bjLxpN2oJppVtHqcnQ== Received: by recvd-65d974bbff-p92hh with SMTP id recvd-65d974bbff-p92hh-1-67C73952-24 2025-03-04 17:33:06.581176178 +0000 UTC m=+1121343.306506096 Received: from earth.catern.com (unknown) by geopod-ismtpd-14 (SG) with ESMTP id VuJF3ZEpTzWGzc00Aubpxw Tue, 04 Mar 2025 17:33:06.498 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=127.0.0.1; helo=localhost; envelope-from=sbaugh@catern.com; receiver=janestreet.com Received: from localhost (localhost [127.0.0.1]) by earth.catern.com (Postfix) with ESMTPSA id EA9B662540; Tue, 04 Mar 2025 12:33:05 -0500 (EST) From: sbaugh@catern.com Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* In-Reply-To: (Spencer Baugh's message of "Fri, 14 Feb 2025 15:54:44 -0500") References: <87r056ijui.fsf@catern.com> <8734gka5h9.fsf@catern.com> <86lducwl51.fsf@gnu.org> Date: Tue, 04 Mar 2025 17:33:06 +0000 (UTC) Message-ID: <87tt88ya3y.fsf@catern.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SG-EID: =?us-ascii?Q?u001=2Ev6RTqHFpv1T6krEot6UFAVAJmQ+4h1t8=2FTfqqE2B07Ntt8ZXe+jvVVpJv?= =?us-ascii?Q?AiRJO0guO4OqcHQQzUcxiqoQjDj382BjhDQpXJR?= =?us-ascii?Q?eNP0UjcqPMy17GJXShxyr5RpNOvDZIG2W3IUKXE?= =?us-ascii?Q?OyOTz98QVQuBYQ6IvVi4palKCvmPOppSIz3eeMb?= =?us-ascii?Q?=2FpwyWYPJhQhp3wqW4N4nK6K1ThGnluLmafs53CK?= =?us-ascii?Q?A=3D=3D?= To: Spencer Baugh X-Entity-ID: u001.oW4JupFKOzCccZAQN2OOFQ== Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74561 Cc: juri@linkov.net, dmitry@gutov.dev, joaotavora@gmail.com, 74561@debbugs.gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca, Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Any further thoughts about this patch? I have an updated version which is even more efficient: we now throw a continuation instead of a symbol, and call that continuation to insert the remaining completions. That means the initial completions which are already inserted in the buffer don't need to be deleted and reinserted. Happily, this is also less code. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Lazily-highlight-and-insert-candidates-in-Completion.patch >From ccc9687291c29e6fe9829502c560d04d1644428c Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Sun, 16 Feb 2025 20:16:19 -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) (completions--lazy-insert-button): Add. (completion--insert-horizontal, completion--insert-one-column): Throw a continuation when enough lines of completions are inserted. (completion--insert-vertical): Add ignored lines argument. (minibuffer-completion-help): Set completion-lazy-hilit. (with-minibuffer-completions-window): Call completion--lazy-insert-strings. (with-minibuffer-completions-window): * lisp/simple.el (completion-setup-function): Preserve buffer-locals required for lazy completion insertion. (switch-to-completions): Call completion--lazy-insert-strings. * etc/NEWS: Announce. --- etc/NEWS | 10 ++++++ lisp/minibuffer.el | 77 +++++++++++++++++++++++++++++++++++++--------- lisp/simple.el | 5 ++- 3 files changed, 77 insertions(+), 15 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index 39c62756085..6b030c9fdb6 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -189,6 +189,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. +As always, if there are more completion candidates than can be displayed +in the current frame, only a subset of the candidates is displayed. +This process is now faster: only that subset of the candidates is +actually inserted into "*Completions*" until you run a command which +interacts with the text of the "*Completions*" buffer. This +optimization only applies when 'completions-format' is 'horizontal' or +'one-column'. + --- *** New user option 'crm-prompt' for 'completing-read-multiple'. This option configures the prompt format of 'completing-read-multiple'. diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index b0ca0a2ece8..5cc9f6221e6 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -2232,6 +2232,8 @@ completions-header-format (string :tag "Format string for heading line")) :version "29.1") +(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 @@ -2253,23 +2255,50 @@ 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)) + (lines (if completions-max-height completions-max-height (frame-height)))) (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)))) - (funcall (intern (format "completion--insert-%s" completions-format)) - strings group-fun length wwidth colwidth columns)))) + (let ((completions-continuation + (catch 'completions-truncated + (funcall (intern (format "completion--insert-%s" completions-format)) + strings group-fun length wwidth colwidth columns lines) + nil))) + (when completions-continuation + ;; If there's a bug which causes us to not insert the remaining + ;; completions automatically, the user can at least press this button. + (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 + 'completions-continuation completions-continuation)))))) + +(defun completion--lazy-insert-strings (&optional button) + (setq button (or button completions--lazy-insert-button)) + (when button + (let ((completion-lazy-hilit t) + (standard-output (current-buffer)) + (inhibit-read-only t) + (completions-continuation (button-get button 'completions-continuation))) + (save-excursion + (goto-char (button-start button)) + (delete-region (point) (button-end button)) + (setq-local completions--lazy-insert-button nil) + (funcall completions-continuation))))) (defun completion--insert-horizontal (strings group-fun length wwidth - colwidth _columns) + colwidth _columns lines + &optional last-title) (let ((column 0) (first t) - (last-title nil) - (last-string nil)) - (dolist (str strings) + (last-string nil) + str) + (while strings + (setq str (pop strings)) (unless (equal last-string str) ; Remove (consecutive) duplicates. (setq last-string str) (when group-fun @@ -2288,7 +2317,16 @@ completion--insert-horizontal (apply #'+ (mapcar #'string-width str)) (string-width str))))) ;; No space for `str' at point, move to next line. - (progn (insert "\n") (setq column 0)) + (progn + (insert "\n") + (when (and lines (> (line-number-at-pos) lines)) + (throw 'completions-truncated + (apply-partially + #'completion--insert-horizontal + ;; Add str back, since we haven't inserted it yet. + (cons str strings) group-fun length wwidth colwidth _columns nil + last-title))) + (setq column 0)) (insert " \t") ;; Leave the space unpropertized so that in the case we're ;; already past the goal column, there is still @@ -2309,7 +2347,7 @@ completion--insert-horizontal (defun completion--insert-vertical (strings group-fun _length _wwidth - colwidth columns) + colwidth columns _lines) (while strings (let ((group nil) (column 0) @@ -2359,9 +2397,12 @@ completion--insert-vertical (insert "\n")) (setq row (1+ row))))))) -(defun completion--insert-one-column (strings group-fun &rest _) - (let ((last-title nil) (last-string nil)) - (dolist (str strings) +(defun completion--insert-one-column (strings group-fun _length _wwidth _colwidth _columns lines + &optional last-title) + (let ((last-string nil) + str) + (while strings + (setq str (pop strings)) (unless (equal last-string str) ; Remove (consecutive) duplicates. (setq last-string str) (when group-fun @@ -2371,14 +2412,20 @@ completion--insert-one-column (when title (insert (format completions-group-format title) "\n"))))) (completion--insert str group-fun) - (insert "\n"))) + (insert "\n") + (when (and lines (> (line-number-at-pos) lines)) + (throw 'completions-truncated + (apply-partially + #'completion--insert-one-column + strings group-fun _length _wwidth _colwidth _columns nil + last-title))))) (delete-char -1))) (defun completion--insert (str group-fun) (if (not (consp str)) (add-text-properties (point) - (progn + (let ((str (completion-lazy-hilit str))) (insert (if group-fun (funcall group-fun str 'transform) @@ -2622,6 +2669,7 @@ minibuffer-completion-help (end (or end (point-max))) (string (buffer-substring start end)) (md (completion--field-metadata start)) + (completion-lazy-hilit t) (completions (completion-all-completions string minibuffer-completion-table @@ -4965,6 +5013,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 2d36062e9c2..12dac272129 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -10456,10 +10456,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 completions--lazy-insert-button)) (completion-list-mode) (when completions-highlight-face (setq-local cursor-face-highlight-nonselected-window t)) + (setq-local completions--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) @@ -10505,6 +10507,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 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 09 11:08:25 2025 Received: (at 74561) by debbugs.gnu.org; 9 Mar 2025 15:08:25 +0000 Received: from localhost ([127.0.0.1]:33820 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1trIGO-00084m-PV for submit@debbugs.gnu.org; Sun, 09 Mar 2025 11:08:25 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:30828) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1trIGK-00084O-PP for 74561@debbugs.gnu.org; Sun, 09 Mar 2025 11:08:22 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8AC5E10004C; Sun, 9 Mar 2025 11:08:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1741532893; bh=+0t/1YHV0NX7YYdsMEeYAQ0Slx0R2johf9YcFzRevuk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=F21qa90T1XLfW2XWDh0lbA02OlpSTsGCDL7in4gCdS4dhjPRW7J0RN8W5Eg4glGLz ZrqMoa9/4MhZpS2u7zxnfZrzx8pFDzUz3Y2Oglw6Y3q0MZX55DIEJMFduMciFr2gNe 4IyElXoVuii7sZ+OKa30xuEwMkadl7nF6nV/ODZNaXPcD2nvXZLdEf+yL14ZCfnG/Q xzTa62LdKE6VlqFWFeSSQ3/ErTWVfl3d/hxNNMnsABzTLJ1kDL7FWvYctlnxvxIBzF C+vSh23pIKaQ9V58j3y5Euf1vDfy4XnBFhMeIXbb1ZCTGiinrFglLl5B1pUNSpeJBP SWQo0+85fz8fQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 98B26100034; Sun, 9 Mar 2025 11:08:13 -0400 (EDT) Received: from pastel (unknown [104.247.242.5]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 506B812029A; Sun, 9 Mar 2025 11:08:13 -0400 (EDT) From: Stefan Monnier To: sbaugh@catern.com Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* In-Reply-To: <87tt88ya3y.fsf@catern.com> (sbaugh@catern.com's message of "Tue, 04 Mar 2025 17:33:06 +0000 (UTC)") Message-ID: References: <87r056ijui.fsf@catern.com> <8734gka5h9.fsf@catern.com> <86lducwl51.fsf@gnu.org> <87tt88ya3y.fsf@catern.com> Date: Sun, 09 Mar 2025 11:08:12 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.238 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: Spencer Baugh , juri@linkov.net, dmitry@gutov.dev, joaotavora@gmail.com, Eli Zaretskii , 74561@debbugs.gnu.org, Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Any further thoughts about this patch? LGTM, Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 20 10:54:21 2025 Received: (at 74561) by debbugs.gnu.org; 20 Mar 2025 14:54:21 +0000 Received: from localhost ([127.0.0.1]:58447 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tvHHo-0002e0-Tg for submit@debbugs.gnu.org; Thu, 20 Mar 2025 10:54:21 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:58115) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tvHHk-0002db-EK for 74561@debbugs.gnu.org; Thu, 20 Mar 2025 10:54:18 -0400 From: Spencer Baugh To: Stefan Monnier Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* In-Reply-To: (Stefan Monnier's message of "Sun, 09 Mar 2025 11:08:12 -0400") References: <87r056ijui.fsf@catern.com> <8734gka5h9.fsf@catern.com> <86lducwl51.fsf@gnu.org> <87tt88ya3y.fsf@catern.com> Date: Thu, 20 Mar 2025 10:54:11 -0400 Message-ID: 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=1742482451; bh=4fWJIKvoE3nvwGHlQ78CX71DCXzf+8egA0RHOshA37g=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=WQfwvupk80eQM3dReapuLItP1RbL6RFmuk2vkhN6ZPYGSLmnHgCXLjZW+8NH1hPGS JpdzTArDZRfp7Dy3DyqSz+YobZvHDHyrtJKG8krF+A8l1vS8vF2gXut9oFUdmlSN/n 9RQpmBjuryejF51h218DblL9BHeApWF24+ppmpm62jnPLPycxanxc9zwBrbOl29C0Q 9ErSdEHu12Rt3jFDQ3BvPtSF+KFm1YbIfAqTod6zgvyGEJ2YVB/ONzmEVzyRaEZ1m4 4hUbuf6viuzh3D94lBrp4rbLFUZpXvx2nvdcQbdWMr2zM38+eS3gPsGXEDuMz17jXx AsyehoDY8iQ3w== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74561 Cc: sbaugh@catern.com, juri@linkov.net, dmitry@gutov.dev, joaotavora@gmail.com, Eli Zaretskii , 74561@debbugs.gnu.org, Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Stefan Monnier writes: >> Any further thoughts about this patch? > LGTM, Could someone please install this change, then? (I can't do it myself) From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 21 17:26:18 2025 Received: (at 74561-done) by debbugs.gnu.org; 21 Mar 2025 21:26:18 +0000 Received: from localhost ([127.0.0.1]:39811 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tvjsf-0004tY-LW for submit@debbugs.gnu.org; Fri, 21 Mar 2025 17:26:18 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:56432) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tvjsd-0004tG-JE for 74561-done@debbugs.gnu.org; Fri, 21 Mar 2025 17:26:16 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 6707F10004C; Fri, 21 Mar 2025 17:26:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1742592367; bh=ICyvDu/BFoxgrChOEoRiyDv+94chMmx8xLK5apeokQI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=PusoOIWdhVZnKyNhB4vS+pYPvWFH7JM8GrkZB3jZBaHHCxx+fVGQI1cdUUUD6MEaD u8nPWBCfkmOLiOzh3g1qiCvAB6KNIbaOnkmGVFJvuW7naes35BI8XuNFd5RNkCXmD0 1fGQBMBO0nARlgiddBp77qaZ4OC2ICgaUtdUqd/0Bw2W+QiyIL8/TG6riOYoz3zZ2r EeYhRmzRhJfc4fcOkch9l0jbiEwPmvWrcEOHo9qf+mQp2gEdMGTHOHbzEbUDjj01VC OKWFvzvECdc3oMvC1cPqC8zo0rpmoB/Ls1WJtb5BzO7vrTYpzRdcx42Hg9xy9nQk8R /UJNiRqEemorg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 6BA84100034; Fri, 21 Mar 2025 17:26:07 -0400 (EDT) Received: from pastel (unknown [104.247.242.5]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2282D12023B; Fri, 21 Mar 2025 17:26:07 -0400 (EDT) From: Stefan Monnier To: Spencer Baugh Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* In-Reply-To: Message-ID: References: <87r056ijui.fsf@catern.com> <8734gka5h9.fsf@catern.com> <86lducwl51.fsf@gnu.org> <87tt88ya3y.fsf@catern.com> Date: Fri, 21 Mar 2025 17:26:06 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.379 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-done Cc: sbaugh@catern.com, 74561-done@debbugs.gnu.org, juri@linkov.net, dmitry@gutov.dev, joaotavora@gmail.com, Eli Zaretskii , Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain >>> Any further thoughts about this patch? >> LGTM, > Could someone please install this change, then? (I can't do it myself) Pushed with the additional patch below. Stefan --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=minibuffer.patch commit b21636580bed822bd9fb8bb84014311fa9b4c071 Author: Spencer Baugh Date: Fri Mar 21 17:24:50 2025 -0400 minibuffer.el: Fix warnings and coding style in last change * lisp/minibuffer.el: Cut lines to fit into 80 columns. (completion--insert-strings): Simplify `if` to `or`. (completion--insert-horizontal, completion--insert-one-column): Fix warning about used var starting with `_`. Avoid `apply-partially`. diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index 47b152ed35d..8fba0b88b20 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -2256,7 +2256,7 @@ completion--insert-strings ;; Windows can't show less than 3 lines anyway. (max 1 (/ (length strings) 2)))) (colwidth (/ wwidth columns)) - (lines (if completions-max-height completions-max-height (frame-height)))) + (lines (or completions-max-height (frame-height)))) (unless (or tab-stop-list (null completion-tab-width) (zerop (mod colwidth completion-tab-width))) ;; Align to tab positions for the case @@ -2264,15 +2264,17 @@ completion--insert-strings (setq colwidth (- colwidth (mod colwidth completion-tab-width)))) (let ((completions-continuation (catch 'completions-truncated - (funcall (intern (format "completion--insert-%s" completions-format)) + (funcall (intern (format "completion--insert-%s" + completions-format)) strings group-fun length wwidth colwidth columns lines) nil))) (when completions-continuation ;; If there's a bug which causes us to not insert the remaining ;; completions automatically, the user can at least press this button. (setq-local completions--lazy-insert-button - (insert-button "[Completions truncated, click here to insert the rest.]" - 'action #'completion--lazy-insert-strings)) + (insert-button + "[Completions truncated, click here to insert the rest.]" + 'action #'completion--lazy-insert-strings)) (button-put completions--lazy-insert-button 'completions-continuation completions-continuation)))))) @@ -2282,7 +2284,8 @@ completion--lazy-insert-strings (let ((completion-lazy-hilit t) (standard-output (current-buffer)) (inhibit-read-only t) - (completions-continuation (button-get button 'completions-continuation))) + (completions-continuation + (button-get button 'completions-continuation))) (save-excursion (goto-char (button-start button)) (delete-region (point) (button-end button)) @@ -2291,7 +2294,7 @@ completion--lazy-insert-strings (defun completion--insert-horizontal (strings group-fun length wwidth - colwidth _columns lines + colwidth columns lines &optional last-title) (let ((column 0) (first t) @@ -2306,26 +2309,28 @@ completion--insert-horizontal (unless (equal title last-title) (setq last-title title) (when title - (insert (if first "" "\n") (format completions-group-format title) "\n") + (insert (if first "" "\n") + (format completions-group-format title) "\n") (setq column 0 first t))))) (unless first ;; FIXME: `string-width' doesn't pay attention to ;; `display' properties. - (if (< wwidth (+ column (max colwidth - (if (consp str) - (apply #'+ (mapcar #'string-width str)) - (string-width str))))) + (if (< wwidth (+ column + (max colwidth + (if (consp str) + (apply #'+ (mapcar #'string-width str)) + (string-width str))))) ;; No space for `str' at point, move to next line. (progn (insert "\n") (when (and lines (> (line-number-at-pos) lines)) (throw 'completions-truncated - (apply-partially - #'completion--insert-horizontal - ;; Add str back, since we haven't inserted it yet. - (cons str strings) group-fun length wwidth colwidth _columns nil - last-title))) + (lambda () + (completion--insert-horizontal + ;; Add str back, since we haven't inserted it yet. + (cons str strings) group-fun length wwidth colwidth + columns nil last-title)))) (setq column 0)) (insert " \t") ;; Leave the space unpropertized so that in the case we're @@ -2397,8 +2402,8 @@ completion--insert-vertical (insert "\n")) (setq row (1+ row))))))) -(defun completion--insert-one-column (strings group-fun _length _wwidth _colwidth _columns lines - &optional last-title) +(defun completion--insert-one-column ( strings group-fun length wwidth colwidth + columns lines &optional last-title) (let ((last-string nil) str) (while strings @@ -2415,10 +2420,10 @@ completion--insert-one-column (insert "\n") (when (and lines (> (line-number-at-pos) lines)) (throw 'completions-truncated - (apply-partially - #'completion--insert-one-column - strings group-fun _length _wwidth _colwidth _columns nil - last-title))))) + (lambda () + (completion--insert-one-column + strings group-fun length wwidth colwidth columns nil + last-title)))))) (delete-char -1))) (defun completion--insert (str group-fun) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 24 11:41:41 2025 Received: (at 74561) by debbugs.gnu.org; 24 Mar 2025 15:41:41 +0000 Received: from localhost ([127.0.0.1]:57457 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1twjvo-0000Ld-Nc for submit@debbugs.gnu.org; Mon, 24 Mar 2025 11:41:40 -0400 Received: from mail.eshelyaron.com ([107.175.124.16]:51418 helo=eshelyaron.com) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1twjvl-0000LR-CK for 74561@debbugs.gnu.org; Mon, 24 Mar 2025 11:41:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1742830896; bh=M2exSI57DtLYnKSKd0EAf9zdTKeGkf2ts1d2AvMDqjk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=lTlUwEWIWy4gu76F7Ka3tC+8dkHoEtNZ9iEpHAjCcAq52xab2zCRc4nMf8a3yUMwq WpMiqiCxwLoqIF2T6ybgTpDq84Q4Z+kdX+nOymfMZh8a6akx9Ufk0bJa6VuFe37Z1j 9PqvTXpRFBgPekrAqtUwKDZJusKzj64+2cxtwdZrDKG2UjjxPFoo47H00UkRhscXBn 5crIFOt/LcznYoG9QjiTvtvz7fcD2odGQztHF1EYm5ZoX2vxjq9oChpvvaXhmikRSz qbLHjaGIz5Ec3x/eyEdUa/TUfmW1rFIzob264XfUfWrEuBl66uk9RBhnmM8YS9f5rO rEaJ3dWWZNjbw== From: Eshel Yaron To: 74561@debbugs.gnu.org Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* In-Reply-To: References: <87r056ijui.fsf@catern.com> <8734gka5h9.fsf@catern.com> <86lducwl51.fsf@gnu.org> <87tt88ya3y.fsf@catern.com> Date: Mon, 24 Mar 2025 16:41:33 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74561 Cc: sbaugh@janestreet.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi, Stefan Monnier writes: >>>> Any further thoughts about this patch? >>> LGTM, >> Could someone please install this change, then? (I can't do it myself) > > Pushed with the additional patch below. FYI this caused a small regression wherein it doesn't populate the *Completions* buffer when you try to scroll through it by repeatedly hitting TAB in the minibuffer. It seemed like a simple oversight, so I installed a fix in commit 119931a9cee. Regards, Eshel From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 24 11:53:07 2025 Received: (at 74561) by debbugs.gnu.org; 24 Mar 2025 15:53:07 +0000 Received: from localhost ([127.0.0.1]:57484 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1twk6t-0000rO-DE for submit@debbugs.gnu.org; Mon, 24 Mar 2025 11:53:07 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:42157) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1twk6q-0000qq-4T for 74561@debbugs.gnu.org; Mon, 24 Mar 2025 11:53:04 -0400 From: Spencer Baugh To: Eshel Yaron Subject: Re: bug#74561: [PATCH] Allow limiting the size of *Completions* In-Reply-To: (Eshel Yaron's message of "Mon, 24 Mar 2025 16:41:33 +0100") References: <87r056ijui.fsf@catern.com> <8734gka5h9.fsf@catern.com> <86lducwl51.fsf@gnu.org> <87tt88ya3y.fsf@catern.com> Date: Mon, 24 Mar 2025 11:52:58 -0400 Message-ID: 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=1742831578; bh=5ieUhmE8KruNm+dcIRZJQBXfWfA5W9L5+IpPkx0t3qo=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=KPRGmvYjm6e0l99kaj7kwVcZNARz76BKzfHU5OIsNZTwgnZxnFQuLg3HURCbV3K1n Q+aq+lFzNy3x9Qc4G57k0+HcalMKKiDVJBYyoX0Fs7F3fSH0HUCRF7Ad8+Cvk3Big+ ffb1eZzq6TJuPIYyv3D/cYWyIvDksdd3nP/EOEgqEoRIoGx09oRY7dzwl+4FjCP0Yw YQy5eclUsifkYPgdg81D2u9wpVpY7C5wQVksGeJiTZNTBOmg5ekZ0NEfDISvVWl0Qf Oxazogo+gk7eQmIAzrtWX5Xh+42+rysD5FTpdtV/vv7K0DMWhom4ol5jmKYq+qgt9D whAvDnr2tNTDg== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74561 Cc: 74561@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eshel Yaron writes: > Hi, > > Stefan Monnier writes: > >>>>> Any further thoughts about this patch? >>>> LGTM, >>> Could someone please install this change, then? (I can't do it myself) >> >> Pushed with the additional patch below. > > FYI this caused a small regression wherein it doesn't populate the > *Completions* buffer when you try to scroll through it by repeatedly > hitting TAB in the minibuffer. It seemed like a simple oversight, so > I installed a fix in commit 119931a9cee. Yes, thank you, your change seems like the right fix. From unknown Fri Jun 20 07:23:02 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 22 Apr 2025 11:24:14 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator