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

[João Távora]

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

> Ah, I forgot to tell you that. The M-x annotations are guarded by
> `suggest-key-bindings`.

Thanks, I see it.

> I have not been involved in the initial design of this, the
> `affixation-function` is there for quite a while already.

6 months, not very long in Emacs release terms.  But indeed you're right
that it wasn't last week..

> I would also be happy with an extension to the `annotation-function`,
> where the returned annotation string is the suffix and can be
> propertized with an additional string for the prefix.

Either that, or it could return a list instead of a string, and then the
list would be interpreted as "affixation function" results.

>> 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.
>
> It is not allowed by the definition of the function.

Yes, but users love to foot-shoot and who is going to enforce that?
Your icomplete patch doesn't, for example.  Whereas if it were a unary
function of a completion string, the hazard wouldn't exist.

In the meantime, I've read some of

   https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg00613.html

and it seems one purported advantage of having `affixation-function` see
all the candidates is to be able to do layout decisions since it knows
the longest and shortest candidate.  At least this is what I read from

  https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg01009.html

But I don't understand why these decision should be done in the data
backend.  The backedn should only annotate a completion with a possible
_hint_ on how to layout ("prefix" and "suffix" are hints). It's the
frontend, who is who knows what to display and where, who should be
responsible for the layout.

>> 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.
>
> For what is worth, my packages already rely on this. But I would have
> this changed quickly given a modified definition of the
> `annotation-function`. I am not aware of other packages already using
> this functionality (I searched around for this at some point).

That's valuable information.  Let's wait for Juri and Stefan on this.

João