Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and, annotations

[Daniel Mendler]

On 5/28/21 3:17 PM, João Távora wrote:
> If some filtering inside the marginalia is needed, just make the
> marginalia field be a plist instead of a flat list.
> Dmitry's completion-info-columns-function is the same idea in a separate
> API. Also works, but I prefer this one, as columns is constraining
> design on the backend side.
> 
>     So no, you did not address this. You enforce a strong coupling between
>     backend and frontend.
> 
> 
> Check again. 

You are talking about the introduction of a `marginalia` field. Such a
field should not be necessary. The frontend should not have to know
about the existence of a `marginalia` field.

What you probably want to say here is that the name does not matter and
we could also call this generically `auxiliary-annotation-columns` and
then the frontends could support this field containing another list of
fields if the frontend likes that or not.

>     For example in Marginalia we take some care to not compute particularly
>     expensive annotations.
> 
> 
> Which is a drawback. A frontend with async capabilities can choose to
> request the expensive ones, too, for example. 

Of course. I am not against such a query based API. But one should take
into account that other expensive metadata can be provided via other
query functions.

There is no advantage in requesting some `expensive-field` from a
`resolution/decoration-function` in contrast to calling an
`expensive-field-function` which is specified in the metadata.

I fail to see what the hypothetical `resolution/decoration-function`
improves. The use case with the columns I described won't be supported
out of the box. Prefix/suffix is supported with the only change over the
affixation function that the prefix/suffix must be requested explicitly.

Daniel