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

[Dmitry Gutov <dgutov@yandex.ru>]

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?

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.

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.

That would allow, for example, to show the key bindings and descriptions 
always in the same place, across all completion functions.

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.