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

[Daniel Mendler]

On 5/28/21 3:57 PM, Dmitry Gutov wrote:
> On 28.05.2021 16:14, Daniel Mendler wrote:
> 
>> I am not particularly fixated on the specifics of how the frontend
>> retrieves the fields from the backend. I want something different - I
>> want the frontend to have the ability to request all field of a certain
>> type, for example strings.
>>
>> The frontend cannot request fields by names of which it does not know
>> the name. This is the flaw of the current proposal.
> 
> IOW, I guessed correctly, and you want the backend to make a 
> presentation-level choice for you: the list of columns to display.

Not according to my interpretion. If I have a database with a list of
columns, does the database specify the presentation? All I am saying is
that the backend should offer a list of available fields to the
frontend. 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.

>> Why do you think backend drivers the presentation then? The backend says
>> I have these fields associated with the particular candidate, please
>> display them as you wish, for example As a spreadsheet/table or as an
>> additional popup in Company.
> 
> That's "presentation" in my book, especially if the backend also 
> specifies positioning, which I think has been discussed in this thread 
> as well.
> 
> Or consider, for example, that you can have a file associated with each 
> completion (perhaps you're showing a list of definitions or references).
> 
> Someone might like to see the file in one of the columns. Do you show 
> it? How do you display it? Do you show the basename? Do you try to 
> "uniquify" those values? These are all presentation-level choices.

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.

>>> - Have c-a-p-f elements only include the "functional" attributes.
>>> - Add a middle layer, something like an option
>>> completion-info-columns-function, which takes (COMPLETION
>>> EXTRA-PROPERTIES) and returns a list of columnar instructions in the
>>> format you originally wanted. EXTRA-PROPERTIES is the value of
>>> completion-extra-properties when called by the default UI.
>>
>> This sounds a bit complicated.
> 
> It's an extra indirection, yes.
> 
> But I think some users might appreciate the ability to customize the set 
> and ordering of the columns in their completions.
> 
> And backend authors might appreciate not having to make those choices.

This is a serious limitation of Marginalia as of now. One could handle
this is on the UI level. An intermediate layer is more generic and would
work with different UIs. This is probably better, I agree with you about
that.

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

Daniel