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

[Daniel Mendler]

On 5/28/21 1:41 PM, João Távora wrote:
>> There should be a possibility for the UI to request all annotations and
>> then it can display the fields it supports.
> 
> Why would the UI request annotations for fields it _doesn't_ support?
> In that case I have to side with Dmitry, who says it's a waste of
> processing.  Why would Icomplete request 'doc-buffer', which is
> potentially slow and needs a network request in some backend, if it
> doesn't need to show it, or even know how to show it?

I would like the backend to have the ability to define arbitrary fields
which are strings and can be printed by the frontend for example in a
table. There is a difference between supporting specific fields or
specific field types. I would like to have the ability for the frontend
to specify arbitrary fields of field type string. Then a frontend can
display those in a tablist for example.

Juri talked about exactly this use case. He considered adding a
formatting function for the default completion UI which uses the tablist.

The "waste of processing" argument by Dmitry is okay - I am not against
a way to limit the number of returned fields. But there should also be a
way to request all available fields, such that a UI can show the ones it
supports (but not based on name but based on type!).

>> Did you see my submission of the GNU ELPA Marginalia package? The
>> package annotates the candidates with multiple annotations which are
>> currently displayed in columns. But this formatting happens inside
>> Marginalia. It would be great if Marginalia could instead return an
>> arbitrary list of annotations which are then formatted by the frontend,
>> for example in a table. The list of annotation fields is not fixed.
> 
> I don't know Marginalia, sorry.  You want a catch-all for arbitrary
> string annotations that some frontends will do their best to display in
> a table? If so, in this scheme, make a field called 'lotsa-strings (or
> some better name, maybe "marginalia" is a good one).  Then convince
> frontends (maybe starting with the ones you control) to give prominence
> to that field over other ones.

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?

All I am asking is a possibility for the backend to return a list of
string fields which can then be displayed by frontends which support
such a tabular view, or maybe a tooltip.

Daniel