On Fri, May 28, 2021, 13:32 Daniel Mendler <mail@daniel-mendler.de> wrote:

>
> Unfortunately this is not a satisfactory solution. I would like to
> decouple the components. It is better if the frontend does not have to
> know everything and all the field names of the backend.
>

Of course. And this doesn't happen.

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

>> The "waste of processing" argument by Dmitry is okay - I am not against
> >> a way to limit the number of returned fields.
> >
> > It's more than just "okay": it's pretty fundamental. I don't think it's
> > a question of limiting the number of returned fields, if the frontend is
> > unlucky one of those fields may take ages to calculate based on the
> > processing needed (many backends operate through networks or processes
> > to request information about completions).
>
> It is still a technical detail. But since we agree on this one, there is
> no need to discuss this further.


I don't know if you understand that same frontends might misfunction if
they request your full list of marginalia data and the backend has included
a slow field there. So the free-form marginalia or table plist should be
specified to be very quick to calculate.

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.

But it is still way too costly to compute all
> annotations of all candidates at once. Marginalia works best when the
> frontend requests only a small number of annotations for the small
> subset of candidates being displayed, as is the case in Vertico or your
> newly revamped Icomplete-vertical-mode.
>

Yes but this is besides the point.

> Heh, :-) I think it is rather you who have to state the relevance of
> > that item to this discussion.  There are lots of packages out there.
> > More than "what does it do" we want to know how it is positively or
> > adversely impacted by the decisions taken here, if at all.
>
> Of course, but as soon as I point you to a package specifically you can
> take a quick look ;) It is just a datapoint in the discussion.
>

I did take a quick look, but I was confused. I couldn't confidently make
any assertion about it based on the knowledge I gathered from looking at
its README.