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

[Daniel Mendler <mail@daniel-mendler.de>]

On 5/28/21 2:44 PM, Dmitry Gutov wrote:
> On 28.05.2021 14:55, Daniel Mendler wrote:
>> 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!).
> I get that it could be seen as convenient, but why can't the frontend 
> just request the fields it supports, one after the other?

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.

Then a tablist frontend could easily display those and allow sorting and
filtering by column. You may be aware of Embark, which already provides
a tablist frontend, but only with the columns candidate and suffix as of
now. It would be great to have more columns there, which are specific to
the backend.

> IME the overhead for the additional function calls is negligible, as 
> long as we're rendering only a dozen items or so, and not the full 
> collection (with thousands of items or more).
> 
> But maybe you want a collection of particular bits of data, 
> pre-formatted for display in a table, and basically not useful for 
> anything else. You could call it :info-columns-function, something like 
> that. Which would allow frontends not even care about which columns are 
> there, or what they contain, and just print them in the indicated order.
> 
> I'm not a fan of having a backend drive presentation like that, but as 
> long as nobody argues for elimination of "functional" attributes in 
> favor of the info presented in info-columns-function (meaning, I could 
> mostly ignore that addition), I'm not going to fight it.

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.

The current proposal is such that the frontend must explicitly request
the fields it would like to see, which precludes the use case I
described above.

> But also consider the possibility of having that logic extracted:
> 
> - 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.

> A possible drawback is that a completion function cannot unilaterally 
> add a new column without a corresponding change in 
> completion-info-columns-function. But that might arguably be a good thing.

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. There is a use case for this (Marginalia or ivy-rich) and from
what I've heard, people like to have such rich annotations. It helps a
lot with the self documentation aspect of Emacs.

And now if we would have an additional tablist frontend, the UI would be
even better, since people could take a look at the annotation fields and
sort/filter/hide each column separately like in a usual spreadsheet.

Daniel