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/23/21 11:37 AM, João Távora wrote:
>> Can you give a visual example of what it looks like for a given completion
>> table, ...
>
> I attached two screenshots:
>
> - M-x
> - `describe-symbol` if `completions-detailed` is set

Thanks, I wasn't aware of this new framework and think this looks very
nice and is extremely useful.  I could get your second example to work,
but not the first (the M-x one).  What am I missing?

>> It seems that neither affixation or annotation were present in non-vertical
>> icomplete.el before your patch.  Do you have an idea why?  Should they
>> be added there, too?
>
> There is not enough space in the vertical display.

You mean in the horizontal one-line display right?  In the vertical
display there is space, so we are enabling it there.

> The only annotations/affixations which would make sense are single
> character annotations, maybe icons. But people who like the compact
> Ido/Icomplete horizontal style probably would not want this additional
> noise.  Furthermore it makes the completions harder to read since you
> get prefix-completion-suffix, prefix-completion-suffix, where
> everything is mixed up. This is different from the vertical mode,
> where annotations and candidates are visually separate and easier to
> distinguish.

Yes, I agree with this.  Thanks for clarifying.

After my sig, I attach a very slightly simplified (and untested) version
of icomplete-affixate, using `cond` instead of nested `ifs`.  But the
main thing I wanted to note at this point, is that I find this
"affixation" design confusing and flawed.

Reading the documentation, I don't see why we couldn't just expand
annotation-function's protocol, instead of adding a new (akwardly) named
entry point with an priority mechanism.

I also don't understand why :affixation-function is given a full list of
completions, when it is presumably meant to return a list of exactly the
same length.  Seems like a potential hazard to allow this function to do
filtering.

So, unless I am missing something (known to happen), this seems like a
misdesign which would be nice to correct before the Emacs 28 release
and/or too many external packages start relying on this.

There was probably some discussion on this, so this ship may have salied
partially.  I'm switching this discussion back to emacs-devel@gnu.org
and CCing Juri as well.

My idea is that it is not too late to:

(1) scratch affixation-function

(2) make annotation function return potentially richer propertized
completion strings.

(3) Adjust the handful of users and consumers around this function.

João.

(defun icomplete--affixate (md prospects)
  "Affixate PROSPECTS with prefixes and suffixes, given completion metadata MD."
  (let ((aff-fun (or (completion-metadata-get md 'affixation-function)
                     (plist-get completion-extra-properties :affixation-function)))
        (ann-fun (or (completion-metadata-get md 'annotation-function)
                     (plist-get completion-extra-properties :annotation-function))))
    (cond (aff-fun (funcall aff-fun prospects))
          (ann-fun
           (mapcar
            (lambda (comp)
              (let ((suffix (or (funcall ann-fun comp) "")))
                (list comp ""
                      ;; The default completion UI adds the
                      ;; `completions-annotations' face if no
                      ;; other faces are present.
                      (if (text-property-not-all 0 (length suffix) 'face nil suffix)
                          suffix
                        (propertize suffix 'face 'completions-annotations)))))
            prospects))
          (prospects))))