Re: complexity in minibuffer

[João Távora]

On Wed, Jun 2, 2021 at 4:06 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> > Yes (but on only)  And those were the functions who now get an optional
> > group-fun arg (also often 'if'ed against sometimes only threaded).
>
> I suspect they should get an `md` argument instead (which will include
> the `group-function`, of course).

That works, of course.  Many things work, but this is not the simplest.

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? A negligible amount of allocation in
a ocean of allocations? Why do we have to pass down the API call
all to way to the display?

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.

> > I think it has to do with the way Juri (or someone else) implemented
> > affixation function and annotation function, which was what I was trying
> > to touch to experiment with resolution-function ideas. Sometimes as 
> > completion
> > is represented by a cons (string annotation-prefix annotation-suffix)
> > sometimes only a string.  It could be a string always, with properties.
> > Or a struct.  But let's leave it at string and never cons.
>
> 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.

João