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: Fri, 04 Oct 2024 17:02:25 +0800 Message-ID: <871q0w44wu.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8225"; 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 Fri Oct 04 11:03:15 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 1sweDS-0001ww-Up for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 04 Oct 2024 11:03:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sweDH-00043b-G4; Fri, 04 Oct 2024 05:03:03 -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 1sweDD-00043E-Nm for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2024 05:02: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 1sweDD-0001H1-Dc for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2024 05:02:59 -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=sXkdvk8hdoMcb8JTRZaWnMgjOMa0yg/waM6ssWQrcR0=; b=psJWjzUkqqzW73Ot0s35o2CWFLiOWcRI2k1yLDJjsdNHJyP8af81VqcZHIjvCbyVGjvII6qxJ8cD/8uA/cKgwz8yFEtm681gCtnh6vVXD5TRBvTEHjBPMscNWaz7B7yjjG3Qs1KMwB4u4ncLsiCwHC/AKmST85aPcFl58DgcEVMxPgPsxcT4mw/vXv0KgiflCMCJL7t5zBFTT5qdk36MO0wkhdXuVIsPTov9q1uef+AvYEqUy4VCmHzmdSJMYhkN6AcpcYjAbKWcHULJOv9J525XTTKUWxJ1w/SM9mXnYOhMEVih1dQVluUebW9mig63GIrB2Glhnwy8kHaZ0U7UXA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sweDF-0008Fz-UR for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2024 05:03:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Sean Whitton Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Oct 2024 09:03: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.172803256131695 (code B ref 72826); Fri, 04 Oct 2024 09:03:01 +0000 Original-Received: (at 72826) by debbugs.gnu.org; 4 Oct 2024 09:02:41 +0000 Original-Received: from localhost ([127.0.0.1]:34406 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sweCv-0008F8-51 for submit@debbugs.gnu.org; Fri, 04 Oct 2024 05:02:41 -0400 Original-Received: from sendmail.purelymail.com ([34.202.193.197]:38544) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sweCs-0008Er-Pa for 72826@debbugs.gnu.org; Fri, 04 Oct 2024 05:02:39 -0400 DKIM-Signature: a=rsa-sha256; b=hF7so/3cRoGAUbJhFUGScJ84LJ9Dkougwjvc55d3AJuYREsd2NCA7jHNn1HnLTVNnxo8eBkT4fedEu/0FHhRhkpuF42BmEZfYa+fr6HUgeFI2Ip6r4TZRfEvHNjxaWVJCD3Gmd4pyJwdgg2rl8SDboS+QJImXliBJWvdYxmapqRrkzA2NezYna1Kh5xbTECcCnLtu5keP5i5FSl5dRfN95rxgEPEPVpufXxCwHyxiy1wya8RjEVcpS2RZ6sdfbhAuoqxp7npvbTc412ZmDKrVI6KJTXdy35/ooTRgZG5DabsUfCEpHl/wjxwdovnCMw5BLmXKuzhE/dfchppi5UOLg==; s=purelymail2; d=spwhitton.name; v=1; bh=LGCHCTNte8H+uOxtnlYu2qrvgUmA1uk9Ekx6Ch4HQcM=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=DIw0sAKtwns3r3DgJNIOGkSbMYe6R/UhRr6g0B2qQjGmJj5HXQR2R5ZZLriL4W/4D5E90ASDJitKFycmfS3uZEiVmfiGPkPvvhpf47IXrHkPtPKHLlC8pNXdrHDosOIowTsRnpFUWptg5i/wgJZX+jtWznallMpevhbWVYqLlcb3ksScfaajou45V4Y0Tb6vueU9SZfTyBXf54H6omCZGS3bRPya8rRYzrUCII2t45Q0Dp2cBTIZq37c96o0vF979/nA7oSpDtyz6+bGF/h44C0SbaKm0V7o2lx4A/k4Fzhdutik9umCutrbjvmd/Fz6x1uVmyXLDua4WYloZsNYVA==; s=purelymail2; d=purelymail.com; v=1; bh=LGCHCTNte8H+uOxtnlYu2qrvgUmA1uk9Ekx6Ch4HQcM=; 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 -391652913; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 04 Oct 2024 09:02:29 +0000 (UTC) Original-Received: by melete.silentflame.com (Postfix, from userid 1000) id 7D2137E36DB; Fri, 4 Oct 2024 17:02:25 +0800 (CST) In-Reply-To: <86y134xuqx.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 04 Oct 2024 09:11:34 +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:292954 Archived-At: Hello, On Fri 04 Oct 2024 at 09:11am +03, Eli Zaretskii wrote: > Can you explain why taking a substring of the buffer text is TRT in > this case and how it makes such a big difference without omitting text > whose width should be measured? IOW, are you saying the current code > produces too large width? if so, how can the layout of completion > candidates be correct? Here is my thinking: I think that the current code was not written with icomplete-in-region in mind, which makes sense, because icomplete-in-region was added later. The current code simply calculates the width taken up by the minibuffer prompt and (minibuffer-contents), and starts the candidates to the right of those. Ignoring icomplete-in-region, (buffer-string) is exactly what we want, because there is nothing else in the minibuffer. So, how can we perform an equivalent calculation that will work in the case that we might not be in a minibuffer? Well, the characters between (icomplete--field-beg) and (icomplete--field-end) are the equivalent of (minibuffer-contents). Then going back to (pos-bol) before (icomplete--field-beg) is the equivalent of including the width of the minibuffer prompt. 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. One case I am not sure about is when the existing input takes up more than one line. I believe the old and new code will always do the same thing, but I'm not sure it's correct. -- Sean Whitton