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

[Daniel Mendler]

On 5/28/21 2:15 PM, João Távora wrote:
> OK, I think understand and I already addressed this.
> 
> The frontend/backend protocol being discussed doesn't preclude your
> intentions, in any way, I think As I said, make a "marginalia" field,
> specified to take the value of a list of strings.  But then you have to
> convince frontends to support it.  Icomplete supports 'prefix and
> 'suffix right now, make a patch to support 'marginalia.  We'll figure
> out the relatively priority if a backend wants to return both
> 'marginalia and 'prefix.

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.

I am not speaking against special casing certain named fields in the
frontend if the frontend wants to give those fields special support.
This is perfectly fine as in the case of the Company fields.

I am talking about the common case of arbitrary fields of type
string/number/..., which can be supported automatically by a frontend
which can show (possibly truncated) strings.

So no, you did not address this. You enforce a strong coupling between
backend and frontend.

>> 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. Of course there can be expensive
annotations, where this matters a lot.

For example in Marginalia we take some care to not compute particularly
expensive annotations. 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.

>> What about taking a look then? Convincing the frontends on a
>> case-by-case basis is not a workable solution. You are the good example
>> here, your answer is "I don't know Marginalia", so how are you supposed
>> to be convinced?
> 
> 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.

Marginalia would not be adversely affected by the `decoration-function`.
But there would also be zero positive impact in comparison to the
`affixation-function`. From what I've seen, Marginalia could use a
`decoration-function` returning a suffix and prefix, which would result
in just a slightly different implementation than the current  one using
the `affixation-function`.

If the `decoration-function` would be allowed to return arbitrary
fields, then the UI could take care to list all these fields in a
tablist. Of course there are other possible UIs. But let's just pick
that one.

For example in the case of `describe-symbol`, there would be these columns:

* keybinding (only supplied for commands)
* type (customizable-variable, command, function, variable, face, ...)
* description (first line of docstring)
* maybe more?

So it would be a positive impact if candidates could be annotated with
arbitrary fields, which the frontend does not know beforehand. The only
thing the frontend must support is the type of the fields. There could
be frontends supporting strings, numbers, images, audio, ...

>From how I understood Juri in a mail a while ago, he was talking about
exactly such a tablist frontend. So I would like to hear his opinion on
this question.

Daniel