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/28/21 10:34 AM, João Távora wrote:
>> Daniel Mendler <mail@daniel-mendler.de> writes:
>>>
>>> A better design for the problem of annotations, which we are actually
>>> discussing here is a `decoration-function` as proposed João. This
>>> decoration function has the sole purpose of providing additional
>>> decorations. Unrelated features should be provided by unrelated
>>> additional functions. The decoration function should return a
>>> plist/alist of all decoration fields. Then one may want to add a
>>> `fields` argument to restrict the set fields in case the UI only needs
>>> the prefix and suffix. A tabular list UI can then present all the fields
>>> as returned by the decoration function.
>> 
>> There has to be a misunderstanding here, because naming aside, this is
>> exactly how I read Juri's proposal of a resolution-function, which I'm
>> fine to call decoration-function or fancification-function etc.
>
> No, there is no misunderstanding here. The example sent by Juri contains
> 'doc-buffer, 'docsig and 'location, which are all Company extensions and
> which cannot be considered annotations or decorations.

Really?  The names of the function mention Company, because at the time
company frontend was their only consumer of them, but the point here is
to make other frontends consume them.  Anyway, as I understood it they
were only examples.

>
> The name `resolution-function` does not suggest that the function is
> supposed to return annotations or decorations.

Ok, change the name.  Name it `decoration-function` or `annotation-function`.

> It can return anything - this is the over-generalization I am talking
> about.

I like that it can return arbitrary pieces of information attached to a
single completion.  That is a generalization, I don't understand the
"over" problem.

>> Again, I can't understand this.  In the frontend:
>> 
>>     (let ((res-fun
>>              (or (completion-metadata-get md resolution-function)
>>                  (plist-get completion-extra-properties :resolution-function))))
>>       (let* ((fields-i-know-how-to-handle '(suffix location))
>>              (str candidate-i-am-about-to-decorate)
>>              (field-values
>>                (mapcar (lambda (f) (funcall res-fun str)) fields-i-know-how-to-handle)))
>>          ...))
>
> This is not an extensible design. I would like that the frontend has the
> ability to show arbitrary fields, not only fields it already knows of.

That's generally impossible.  How can a frontend know how to display the
field 'magical-animated-gif-boomerang-video-url' I'm thinking of
attaching to the completions of my completion backend?  Eventually, very
fancy frontends will be able to do that, and it's my job to convince
them that this is a super-important piece of information to show the
user, but some frontends can't or won't show video for example.

To restate, now that I have Icomplete mostly fixed for verticality and
nice scrolling behaviour and also reworked for easy annotation support,
I think Juri's idea is a fine one (with the cardinality adjustment --
one field per call).

João