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

[Dmitry Gutov]

On 28.05.2021 17:10, Daniel Mendler wrote:

> What about the possibility for the backend to return some kind
> of description of the available data?
>
> (:kind 'icon :keybinding 'string :description 'string ...)
>
> But maybe that's also overkill.

I could get behind something like this. Though it does look like extra 
work for backend writers.

My thinking was more along the lines of having the attribute types 
simply be described in the docs (then only the "known" attributes would 
be rendered by different frontends), but you and the Marginalia 
community can probably make a better choice between these options than 
myself (*).

Note that this is still compatible with my suggestions of 
completion-info-columns-function, the latter could still be used for 
some presentation-level choices (like which columns to display and in 
which order; but also be able to show arbitrary columns). But it becomes 
less necessary for sure.

(*) From where I'm standing, there should be a limited set of columns 
you'll want to show in such table. Then we could basically document them 
all at once and forego the introspection capability. But I definitely 
can be wrong about this.

> Okay, I think I understand what you mean. Of course there is already a
> bit of presentation performed by the backend depending on how it returns
> the data, in particular if the backend returns generic fields of type
> string. In order to fix this one would have to distinguish 'string from
> 'file field types.

Another use for field types could be to render some of the fields 
differently, e.g. apply the help-key-binding face to key bindings.

> > >   From my experience this is not a good thing. The completion table should
> > > have the ability to add arbitrary annotation columns depending on the
> > > data.
> >
> > Well, it definitely shouldn't choose the presentation of "kind"
> > annotations on its own, like in your earlier example.
>
> My idea is rather that the completion table returns a field of type,
> which can then be interpreted depending on its type by the UI. The
> question is how fine grained these types should be. As you argued string
> is not generic enough, one would require a special 'kind type and a
> 'filename type. In the case of the 'kind type the discussion becomes a
> bit mood since then one has a field 'kind of type 'kind. But this is not
> the common case, I think one could catch many annotations with some
> common types.

Yes, probably.