bug#72826: 30.0.90; icomplete-in-buffer becomes unusably slow in large Eshell

[Eli Zaretskii <eliz@gnu.org>]

> From: Sean Whitton <spwhitton@spwhitton.name>
> 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 <spwhitton@spwhitton.name>
> >> 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.