Re: feature/icomplete-vertical

[Ergus <spacibba@aol.com>]

On Sat, Sep 19, 2020 at 08:35:24AM +0000, Gregory Heytings via Emacs development discussions. wrote:
>
>>
>>There is another corner case that is when
>>
>>(frame-parameter nil 'minibuffer) is 'only. This was also a problem 
>>reported some days ago needed when using frames and not the 
>>minibuffer.
>>
>
>Hmmm... in that case (a corner case, indeed, which does not seem to be 
>covered by the current icomplete implementation), it means that the 
>minibuffer is not resized att all?  TBH, it seems to me that using 
>icomplete with a minibuffer-only frame does not have much sense.
>
Some users of maple-minibuffer-mode uses them with icomplete + the
external package.

>That being said, it is always possible to imagine more corner cases, 
>for example a completion candidate that would fill more than one line,
I know, for this the users set visual-line in minibuffer. Which I
probably will do to.

>or a completion candidate list with different fonts (I'm not sure that
>this is actually feasible)

This is the reason of the "format" approach I was trying; and why
working directly in pixels as it is simple to get the current line
height in pixels too and increment it more precisely. But I consider
this as a different feature too, so it is not in that patch.

>, or completion candidates with embedded newlines, or...

Covered with the format approach too, but also a new feature.
>
>>
>>The other problem with the patch is that due to rounding and floor 
>>when using different fonts there is too much extra space missing and 
>>sometimes missed a candidate at the end. This was also reported some 
>>days ago.
>>
>
>I don't think so, but I could be wrong.  I tested my code with many 
>different parameters, and did not see the "extra space" you mention, 
>in all cases the completions fit perfectly in the minibuffer, and the 
>prompt is never hidden.
>
Or I could, but I had issues before with this before.

>>
>>Look at the attached patch as it is partially simplified in my local 
>>branch.
>>
>
>Thanks, I'll have a look.
>
>Gregory
>