Re: feature/icomplete-vertical

[Stefan Monnier]

> That's why I work with pixels.

Yes, that's fine.

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

You don't want to go there.  You end up having to reimplement the job
done by the redisplay.  Instead, just output "a bit more" than
necessary, and then ask the redisplay code whether it fits (so you
reuse the redisplay code instead of reimplementing it).

>>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.
> I actually added the cl-count for the opposite reason; in case the user
> adds a separator with more than one \n.

That's not the opposite reason, that's the case I had in mind.  By using
1 instead of (cl-count ?\n icomplete--separator) you'll be
over-estimating (by the factor that would have been returned by
`cl-count`) the number of candidates that can fit when (cl-count ?\n
icomplete--separator) is greater than 1.

> So we need to add the exact amount of lines as accurate as possible.

I *strongly* recommend you design the behavior under the assumption that
it's OK if there are a few more lines in the (mini)buffer than are
actually visible.


        Stefan