From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Sean Whitton Newsgroups: gmane.emacs.bugs Subject: bug#72826: 30.0.90; icomplete-in-buffer becomes unusably slow in large Eshell Date: Sat, 05 Oct 2024 08:21:56 +0800 Message-ID: <87cykfxuu3.fsf@melete.silentflame.com> References: <87seuqjuk4.fsf@melete.silentflame.com> <86r0aai1an.fsf@gnu.org> <8734ldxntq.fsf@melete.silentflame.com> <8634ldz07h.fsf@gnu.org> <87frpcwwge.fsf@melete.silentflame.com> <86y134xuqx.fsf@gnu.org> <871q0w44wu.fsf@melete.silentflame.com> <86r08wxhpq.fsf@gnu.org> <87a5fkyvuk.fsf@melete.silentflame.com> <86o740xeyy.fsf@gnu.org> <87bk00x8lp.fsf@melete.silentflame.com> <86frpcx7ip.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39807"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: joaotavora@gmail.com, 72826@debbugs.gnu.org, juri@linkov.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 05 02:23:23 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1swsZt-000ACA-R2 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 05 Oct 2024 02:23:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1swsZX-0005yR-Ug; Fri, 04 Oct 2024 20:22:59 -0400 Original-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 1swsZW-0005yH-Rz for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2024 20:22:58 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1swsZW-0007sK-JE for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2024 20:22:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=PQuSeO+dxYlwWHEvaxdBbxDvsf5FSHBfeKcUEt3MWKQ=; b=TmJVtu3fJYGBL3vT8AHdSf9BdVkaidbMVwkqwBsNAngqtbX696U680QQMCMdGTC0bxi8KAlbIMu6FOnwl+hk9bVAfLAghAagMQ/HVktWjosvd67VXZbmnVu96rPuwCEwOvs7yoim8oKnHoAchodkgPNCNCaMiuIxVPDbLBLooqdh6j/Kh+9AbN2Eq6bhGoXi9+3jMIHAfIZ+kFqtkquVq/AT114AODbgorvi/lmriKNBiRR2+O0IUL6+IQBBEcfH+I3KIN4QQZvgLFsKgq2IZzOrOSf2tNzqAjQQYoAcci4TfHNPOFmyo9ZlQ3T0CWX3ajsUUl1+K1/0mXxRZ4uB9Q==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1swsZa-0007FX-Aw for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2024 20:23:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Sean Whitton Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Oct 2024 00:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72826 X-GNU-PR-Package: emacs Original-Received: via spool by 72826-submit@debbugs.gnu.org id=B72826.172808773527780 (code B ref 72826); Sat, 05 Oct 2024 00:23:02 +0000 Original-Received: (at 72826) by debbugs.gnu.org; 5 Oct 2024 00:22:15 +0000 Original-Received: from localhost ([127.0.0.1]:36898 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1swsYp-0007Dz-3G for submit@debbugs.gnu.org; Fri, 04 Oct 2024 20:22:15 -0400 Original-Received: from sendmail.purelymail.com ([34.202.193.197]:52168) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1swsYm-0007Dj-OG for 72826@debbugs.gnu.org; Fri, 04 Oct 2024 20:22:13 -0400 DKIM-Signature: a=rsa-sha256; b=Qkw0wdZV4eZ5wSULDSA03Kol490dK1BtOzTMuMGnBPX66AniaXDG/JadABdhUwjDfRccdXkirS21fT1gC8JgIYJ5k7iU6HRC1Vc4ulPdeUV33LnswvtWl67xgdyT6Uyf6rl2o28Fyxb7f363Gtruz5syccYRz3L+1d2EzzotaPkRKEBvNM3wBgT5ZsFVs49CTm7OFKfwNbLkna7hODS8KvrJfRBLSmwf3FPFJna+suHmGKrKkQko/YQuZbrO5BXQnwgkqsiOauIgeUO2y94QB163UAVnxUBwBOGFlR9zwYgZ+I0mw7smSDhTEZKMHWOzkZ/tsHq5FCSPAJm0qa568g==; s=purelymail2; d=spwhitton.name; v=1; bh=ZbbJ6BgoalpSPX00Q0wjEiMMPuK5L4+hlHQeBaUXk0Y=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=YA9f0j7nM9u0NtCjsaLZhBts9vjpaxLq7PUkVCdkdizPeGwueTFOSNckBtLCKKcBgKrKaRlg9S/FAV21vbMog/Apn3jSa7M+IdfDKNXeOIuoYkh89/AZrQSEc7oW6cqWClAk32ZYBxLJgatqo89USo7pNaygtJdzb/iVChScCsA4vHy3Axl2l+t2xdrs/ZHvJrU8h3KfyajU3TxOQ1hSsfzJI55oVBXWeWmUsrnkWzwSR8hWysn3EcKQ6pnOMhgQYT92yb1/9kGGSZj/XTElMSo7yRAd+BQWNNaXkTyK6gljlp5X3cS30Srv3RyFEImQroDWhZgFE4BqbSjmbYqnmw==; s=purelymail2; d=purelymail.com; v=1; bh=ZbbJ6BgoalpSPX00Q0wjEiMMPuK5L4+hlHQeBaUXk0Y=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 72826@debbugs.gnu.org Original-Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -1998333993; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 05 Oct 2024 00:21:58 +0000 (UTC) Original-Received: by melete.silentflame.com (Postfix, from userid 1000) id 10B3C7E4B43; Sat, 5 Oct 2024 08:21:56 +0800 (CST) In-Reply-To: <86frpcx7ip.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 04 Oct 2024 17:33:18 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:292983 Archived-At: Hello, On Fri 04 Oct 2024 at 05:33pm +03, Eli Zaretskii wrote: > Thanks. But the difference between the two cases is larger than the > difference between the first and the second line of the prompt. How > do you explain that? Also, why doesn't the first image show more > candidates, so as to use all of the second screen line in the > mini-window? is that expected? It's expected, indeed. The explanation for all the cases you ask about here is that the parts of the algorithm subsequent to the computation of prospects-max do not try especially hard to fill up prospects-max. My patch to address this bug only attempts to correct the computation of prospects-max, not to make any change to how that value is subsequently used. If you think the latter should be changed, I think that should be a separate bug report. (Speaking as a longterm Icomplete user, I don't especially think it needs to change.) I've prepared two diffs that display the problem and how my patch fixes it. Apply the first diff and then try the (completing-read ...) examples from my previous message. In the case of the multiline prompt, you can see that the XXXXXXX do not extend as far as they should. Then apply the second diff, and try the (completing-read ...) again. Even though the algorithm doesn't aggressively use up prospects-max, the XXXXXX extend to the correct position, demonstrating the correctness of my reworked computation of prospects-max. --8<---------------cut here---------------start------------->8--- diff --git a/lisp/icomplete.el b/lisp/icomplete.el index 2ea5e36fa88..e2607812d5e 100644 --- a/lisp/icomplete.el +++ b/lisp/icomplete.el @@ -1074,11 +1079,19 @@ icomplete-completions (put-text-property 0 (length first) 'face 'icomplete-first-match first) (push first prospects))) - (concat determ - "{" - (mapconcat #'identity prospects icomplete-separato= r) - (concat (and limit (concat icomplete-separator ell= ipsis)) - "}"))) + (let ((res + (concat determ + "{" + (mapconcat #'identity prospects icomplete-s= eparator) + (concat (and limit (concat icomplete-separa= tor ellipsis)) + "}")))) + ;; Show the space out of prospects-max we didn't use. + (if (window-minibuffer-p) + (concat res (make-string (- prospects-max + (length res) + (string-width (buffer-st= ring))) + ?X)) + res))) ;; Restore the base-size info, since completion-all-sorted-com= pletions ;; is cached. (if last (setcdr last base-size)))))))) --8<---------------cut here---------------end--------------->8--- --8<---------------cut here---------------start------------->8--- diff --git a/lisp/icomplete.el b/lisp/icomplete.el index 2ea5e36fa88..c37788d85e3 100644 --- a/lisp/icomplete.el +++ b/lisp/icomplete.el @@ -1002,12 +1002,18 @@ icomplete-completions ((< compare (+ 2 (string-width ellipsis)= )) most) (t (concat ellipsis (substring most comp= are)))) close-bracket))) + (temp (string-width + (buffer-substring + (save-excursion + (goto-char (icomplete--field-beg)) + (pos-bol)) + (icomplete--field-end)))) ;;"-prospects" - more than one candidate (prospects-len (+ (string-width (or determ (concat open-bracket close-br= acket))) (string-width icomplete-separator) (+ 2 (string-width ellipsis)) ;; take {= =E2=80=A6} into account - (string-width (buffer-string)))) + temp)) (prospects-max ;; Max total length to use, including the minibuffer conte= nt. (* (+ icomplete-prospects-height @@ -1074,11 +1080,19 @@ icomplete-completions (put-text-property 0 (length first) 'face 'icomplete-first-match first) (push first prospects))) - (concat determ - "{" - (mapconcat #'identity prospects icomplete-separato= r) - (concat (and limit (concat icomplete-separator ell= ipsis)) - "}"))) + (let ((res + (concat determ + "{" + (mapconcat #'identity prospects icomplete-s= eparator) + (concat (and limit (concat icomplete-separa= tor ellipsis)) + "}")))) + ;; Show the space out of prospects-max we didn't use. + (if (window-minibuffer-p) + (concat res (make-string (- prospects-max + (length res) + temp) + ?X)) + res))) ;; Restore the base-size info, since completion-all-sorted-com= pletions ;; is cached. (if last (setcdr last base-size)))))))) --8<---------------cut here---------------end--------------->8--- > But if your analysis is correct, does the value returned by > string-pixel-width divided by default-font-width produce the correct > result? Do you mean to propose (/ (string-pixel-width (buffer-string)) (default-font-width)) as an alternative to my fix? I've just tried that, and while it appears to be slightly faster than the existing code, Icomplete in a large buffer remains unusably slow. --=20 Sean Whitton