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

["João Távora" <joaotavora@gmail.com>]

Daniel Mendler <mail@daniel-mendler.de> writes:

> On 5/25/21 12:07 AM, Juri Linkov wrote:
>> The next step would be to allow the option 'completions-format'
>> to accept an arbitrary frontend rendering function.  Then a new
>> possible value could be added such as:
>> 
>> 4. completion--insert-multi-column
>> 
>> So when affixation-function will return a list of multiple columns,
>> e.g. for buffers the same list of columns as used by list-buffers:
>> '("C" "R" "M" "Buffer" "Size" "Mode" "File") from the backend,
>> the new frontend rendering function completion--insert-multi-column
>> will accept such a list of all columns, set it to the buffer-local
>> variable 'tabulated-list-entries', and call 'tabulated-list-print'
>> to render it in the output buffer *Completions*.
>
> It would be great, if the backend can specify arbitrary custom columns,
> maybe with some hints (desired width, if it is a prefix/suffix, etc).
> Then we can define some "semantic names" as standard, which should be
> understood by the frontend, as Dmitry proposed.

To clarify, the analog in some markup format is specifying something as
"emphasis" and then the renderer usually decides that bold if it can, or
surround it in asterisks.  But the markup format doesn't usually say
"bold".  For the same reasons, what you're now calling "columns" should
probably be referred to as "fields" or something equivalently agnostic
as to the format in which they are display.

> But this can happen as a second step. What kind of
> `affixation-function` are you proposing, one that returns a plist?
> Would such a design be acceptable for João too?

I have no strong feelings on plist, versus alist, versus propertized
string, versus object, versus whatever.  Just slightly strong feelings
as to the fundamental mission of this function which is to do
annotation/affixation/whatchacallit, not filtering or reordering.

For reasons of "forward compatibility", as you called them, which is the
ability for newer backends to work on older Emacs that don't understand
these new things, if that work is done in `annotation-function` then it
needs to use propertized strings.  But if it's done in a new thing, say
called decoration-function, it doesn't.

João