emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: João Távora
Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and, annotations
Date: Fri, 28 May 2021 09:34:28 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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.

The only tiny thing I'm not in agreement with is the signature.  Mind
that it works fine with Juri's idea, but it requires the backend
programmer to be careful of its mapcar (this is exactly the same
foot-shoot situation that Stefan understates and I overstate).

But that's not a showstopper, I propose this small variation.
In the backend:

    :resolution-function
    (lambda (str 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))))

The frontends then decides what value of FIELD to pass to their multiple
invocations of this function for each completion.

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

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


João



reply via email to

[Prev in Thread] Current Thread [Next in Thread]