Re: feature/icomplete-vertical

[Ergus <spacibba@aol.com>]

On Sat, Sep 19, 2020 at 09:00:05AM -0400, Stefan Monnier wrote:
>> +                  (let ((minibuffer-parameter (frame-parameter nil 'minibuffer)))
>> +                    (min (floor (cond
>> +                                 ((eq minibuffer-parameter t)
>> +                                  (if (floatp max-mini-window-height)
>> +                                      (* max-mini-window-height (frame-pixel-height))
>> +                                    (* max-mini-window-height (frame-char-height))))
>> +                                 ;; TODO : minibuffer-parameter can have other values.
>> +                                 ((eq minibuffer-parameter 'only)
>> +                                  (frame-pixel-height)))
>> +                                (* (cl-count ?\n icomplete--separator) (line-pixel-height)))
>> +                         (+ 2 icomplete-prospects-height)))))

Hi Stefan:
>
>Why do we care about (cl-count ?\n icomplete--separator)?
>
>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.
>
That's why I work with pixels. Because we can get the height of every
added line and do a better estimation... but we need to add the text
properties before the increment... which is a different topic because
ATM this is not happening.

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

I actually added the cl-count for the opposite reason; in case the user
adds a separator with more than one \n.

Because the idea was to change the condition to enable vertical mode for
when the separator contains at least a \n. Because otherwise the
horizontal formatting could be more accurate. So having both (format and
separator) may conflict unless we prioritize one of them; which IMO
should be the separator as it is the already existent variable.

My intention is to remove the icomplete-format variable completely and
use the right condition based only on the user's separator because
that's something that 2 users mentioned when I asked in this mailing
list to try the branch. This is needed to keep compatibility with the
external package.

OTOH the problem of adding too many candidates (IIUC) is the hiding
prompt issue which comes from there but also the ... will be hiden. So
we need to add the exact amount of lines as accurate as possible.