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

[Dmitry Gutov]

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.

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

Aware: yes. Seen the screenshots, haven't tried it myself so far.

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

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

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.

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

Well, it definitely shouldn't choose the presentation of "kind" 
annotations on its own, like in your earlier example.

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

Worst case, Marginalia could define its own 
completion-info-columns-function. But yes, it would add an extra bit of 
rigidity to the system.