Re: complexity in minibuffer

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

> Let's have it so that at a certain point, a collection of completions
> (whatever the format of collection and/or completion) is  enough to draw
> them, no more dependency on global state or multiple funky arguments
> that are hard to mock.  Less if's. Great for automated testing, too.

That can be done once you know which completions can be displayed, yes.

Basically, we need a function that takes a (potentially large) set of
"raw candidates" and turns it into the (hopefully smallish) set of
rendered candidates which we'll actually display.

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


        Stefan