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

[Daniel Mendler]

On 5/26/21 11:45 PM, Juri Linkov wrote:
> Then instead of such ad-hoc meta functions:
> 
>   :annotation-function
>   (lambda (str) (if (fboundp (intern-soft str)) " <f>"))
>   :company-kind #'elisp--company-kind
>   :company-doc-buffer #'elisp--company-doc-buffer
>   :company-docsig #'elisp--company-doc-string
>   :company-location #'elisp--company-location))
> 
> we could have one function
> 
>   :resolution-function
>   (lambda (str fields)
>     (mapcar (lambda (field)
>               (pcase field
>                 ('suffix (if (fboundp (intern-soft str)) " <f>"))
>                 ('kind (elisp--company-kind str))
>                 ('doc-buffer (elisp--company-doc-buffer str))
>                 ('docsig (elisp--company-doc-string str))
>                 ('location (elisp--company-location str))))
>             fields))
> 
> called with e.g.
> 
>   (funcall (completion-metadata-get md 'resolution-function)
>            '(prefix suffix location kind))
> 
> When 'prefix' is not implemented by the backend, it just returns 'nil'.

The proposal of a `resolution-function` is an over generalization.
Throwing orthogonal functionality together in a single function will
hurt composability and will make the design less flexible. There is
already `metadata` which can be extended. Therefore there is no need to
add such an arbitrary query functionality in the form of a
`resolution-function`. The additional fields 'docsig, 'location and
'doc-buffer should not be added here.

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.

If a design like the `resolution-function` from above is used, the UI
would have to somehow check the type of each field value to determine if
and how it should be displayed. This does not look like a good and
simple solution to me.

Daniel