|Date:||Sat, 19 Sep 2020 13:59:18 +0000|
|User-agent:||Alpine 2.22 (NEB 394 2020-01-19)|
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.
|[Prev in Thread]||Current Thread||[Next in Thread]|