Re: complexity in minibuffer

[Daniel Mendler <mail@daniel-mendler.de>]

On 6/2/21 5:38 PM, Stefan Monnier wrote:
>> By that time, you have already traversed the completion list many times.
>> What's the problem with having the completions themselves contain
>> all that's needed to render them?
> 
> If you have 10K completions, the time need to compute their rendering
> becomes very significant, so we want to only compute the rendering for
> those completion which actually reach the glass.

Yes, it is crucial to only compute
annotations/affixations/group-transformed-candidates only for the
visible candidates, since all these computations may be expensive.

I think we should make this part of the `completing-read` definition,
that these functions are allowed to do more expensive work, since they
are always called on a small subset of candidates, which are going to be
displayed.

>>> I don't have a strong opinion here, except that I think it would make
>>> sense to handle `group-function` and `annotation/affixation-function` at
>>> the same place.
>> You do have to call the first on all of the completions and the latter only
>> on a subset to be displayed.  That's a constraint of the problem itself.
> 
> Not necessarily: you could also decide to only group those completions
> which are displayed.

For the default completion UI this is the case. But this is not how
grouping works for UIs like Vertico, Selectrum and Icomplete-vertical,
where the first grouping step has to happen after sorting on all
candidates. The grouping candidate transformation can then come later
only for the visible candidates and can then be comparatively more
expensive.

Daniel