Re: feature/icomplete-vertical

[Ergus]

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