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.