Re: feature/icomplete-vertical

[Gregory Heytings]

> I mean, the purpose of this code AFAIK is to *estimate* an upper bound 
> on the number of candidates that will be visible.  Depending on various 
> factors (special fonts, text-properties, you name it), this estimate 
> will at time be wrong, so in any case we will have to make sure that the 
> resulting behavior is still acceptable when we end up displaying more 
> (or less) candidates than fits.
>
> Using 1 instead of (cl-count ?\n icomplete--separator) will err on the 
> side of putting too many rather than too few candidates, which should 
> have as sole negative impact a negligible performance hit.

Alas an estimate is not enough in this case.  As Ergus just wrote, if 
there are too many candidates the prompt disappears, leaving the cursor at 
the beginning of the minibuffer, which is counterintuitive.  A simple 
example: after (setq max-mini-window-height 1), with "M-x a" the "M-x" 
prompt and the "a" disappear.  Likwise after (setq icomplete-separator 
"\n").  IOW, to avoid this it is necessary to compute the number of 
completion candidates that will be shown in the minibuffer, depending on 
its height, its font size, and so forth.