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

[Sean Whitton <spwhitton@spwhitton.name>]

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