From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#72826: 30.0.90; icomplete-in-buffer becomes unusably slow in large Eshell Date: Fri, 04 Oct 2024 14:52:21 +0300 Message-ID: <86o740xeyy.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39272"; mail-complaints-to="usenet@ciao.gmane.io" Cc: joaotavora@gmail.com, 72826@debbugs.gnu.org, juri@linkov.net To: Sean Whitton Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Oct 04 13:55:22 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 1swgu2-000A1q-1R for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 04 Oct 2024 13:55:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1swgtg-0004A6-Pv; Fri, 04 Oct 2024 07:55:00 -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 1swgtf-00049x-38 for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2024 07:54:59 -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 1swgte-0004bW-RK for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2024 07:54:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=Cd/Z1jskZmJNeup4RpBw1jduhRBQVYFdTHqCiYoxxoA=; b=EknXkfpqUMFJDPuWm7RLxfweKaE3ea2QxM1GSOQc2M1N70ev5/ZkzOKAS89ApGN2sJkXHpkMUYLKINnrje/xn+2eST0QhtWS8kXnqF6Tty6/44K3HQjztUrRm2Q2Vw9OELaYRGtT7wa0paikyQ5iDYlc+xDG7CGuo5WDCz0mrUuvBmrxkigQ61KvqChPmeWN8u6C6W+ad551f338gr3kRPkwwEw1apnFzK8NoNI5M1FH7GehMkJBbCkffVuDY/LzCzAZN2tEc8shMGJhQc1NOrTELFNx4+6FByHXvSjoWNKMmxwuo9T8vOkZfxji6yMr+hxkdS8c3f3qOA9ajEQT7w==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1swgth-0000Sd-SY for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2024 07:55:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Oct 2024 11:55:01 +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.17280428891744 (code B ref 72826); Fri, 04 Oct 2024 11:55:01 +0000 Original-Received: (at 72826) by debbugs.gnu.org; 4 Oct 2024 11:54:49 +0000 Original-Received: from localhost ([127.0.0.1]:34573 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1swgtV-0000S4-68 for submit@debbugs.gnu.org; Fri, 04 Oct 2024 07:54:49 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:41664) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1swgtT-0000Rn-Dq for 72826@debbugs.gnu.org; Fri, 04 Oct 2024 07:54:48 -0400 Original-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 1swgrC-0004Ky-5M; Fri, 04 Oct 2024 07:52:26 -0400 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=Cd/Z1jskZmJNeup4RpBw1jduhRBQVYFdTHqCiYoxxoA=; b=edaLntlbTyYf fAHmYzOVUfz03syHIYkuafOhqUofntPy77MivlqREZnDQ5QI8WNmOTWhNxpzBIoJb7rxaJWfF6Lc5 zvT3pktdiECo/hd4oqlqjitjJz/CVO+wmYNBtbo1fcnGrLpXAB7ccyWC9KYKUhdr/LcNsZLsYDlOc d4U+YC2M3A3U7jXYsKVyOhpWLajxnKZocfUaiBqqF80WYHd3uxLZ15N2Jn0Z6IvwMTKfoBUgz9Ime J7x4Mz8Y3JEEPVmVsxKaXDIDfQcEFRCu6kXmnr12sWq24GaTWra3LtMX1bUcIyhtqwOeWUc07FEzZ bUtXPhMn6doQ9XZCvhEZ9Q==; In-Reply-To: <87a5fkyvuk.fsf@melete.silentflame.com> (message from Sean Whitton on Fri, 04 Oct 2024 19:02:27 +0800) 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:292959 Archived-At: > From: Sean Whitton > Cc: joaotavora@gmail.com, 72826@debbugs.gnu.org, juri@linkov.net > Date: Fri, 04 Oct 2024 19:02:27 +0800 > > On Fri 04 Oct 2024 at 01:53pm +03, Eli Zaretskii wrote: > > >> From: Sean Whitton > >> Cc: joaotavora@gmail.com, 72826@debbugs.gnu.org, juri@linkov.net > >> Date: Fri, 04 Oct 2024 17:02:25 +0800 > >> > >> Cases where the old code and new code are different are when the > >> minibuffer prompt contains line breaks. The new code effectively > >> ignores all parts of the minibuffer prompt except its last line. I > >> think that's correct, and the old code could have calculated an overly > >> large width if previous lines of the minibuffer prompt were longer than > >> the final line. > > > > So you are saying that the old code never worked correctly for > > minibuffer prompts that include embedded newlines? Then how come no > > one complained about that before? This bug is not about incorrect > > result, it's about slow responses, and that's something entirely > > different. > > Well, not many people use Icomplete mode, and not many minibuffer > prompts have embedded newlines. > > If you prefer I could conditionalise the code so it does exactly the > same as it always did in the minibuffer, and only does something > different when completing in a region in a non-minibuffer? That's not exactly my problem. I actually wonder whether the current code does TRT when there are embedded newlines, regardless of whether it's slow or not. Can you look at that? If the current code works correctly, then I think your analysis of what is wrong with it might not be correct/complete, and there's some other factor at work here. IOW, I think we should understand the issue and its root causes completely before we discuss the solution.