[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: feature/icomplete-vertical

From: Stefan Monnier
Subject: Re: feature/icomplete-vertical
Date: Sat, 19 Sep 2020 09:00:05 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

> +                  (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)))))

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.

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]