Hello,

On Fri 04 Oct 2024 at 02:52pm +03, Eli Zaretskii wrote:

> 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.

I played around with this a bit.

Firstly, I previously mentioned newlines in the input or candidates.
But Icomplete isn't really meant to work at all with candidates
containing newlines, so this part of the display algorithm certainly
doesn't.  So let's ignore that.  It's an extreme edge case.
(I'm not sure any of the completion infrastructure in Emacs is meant to
be able to handle candidates containing newlines.)

So, what we are interested in is the case of embedded newlines in the
minibuffer prompt, where the last line of the prompt is shorter than
previous lines, such that (string-width (buffer-string)) would give an
answer that's too large.

1. emacs -q
2. M-x icomplete-mode
3. (setopt icomplete-show-matches-on-no-input t)
4. (completing-read "Here we go: " obarray)