Re: Simplification of `affixation-function`

[Dmitry Gutov <dgutov@yandex.ru>]

On 25.04.2021 21:08, Daniel Mendler wrote:
> On 4/25/21 7:58 PM, Dmitry Gutov wrote:
>> I guess my problem with it is, with the apparent end goal of 
>> flexibility, it ends up targeting only the default completion UI, and 
>> the more an alternative UI is different from it, the worse the result 
>> can look.
>>
>> And without semantic information, it fails to take advantage of the 
>> additional features the alternative UIs might provide.
> 
> You are right about that. As things stand now the 
> annotation/affixation-function only work well for the default 
> completions buffer and the vertical completion UIs.

Isn't Company a vertical completion UI?

> The 
> completion-at-point popups are very different from that, so it is only 
> fair if they try to invent their own metadata functions as you are doing 
> in Company with `company-kind` etc.

It's fair that they try to invent new stuff, but it's more economical to 
reuse the stuff when feasible.

> However I am a bit critical with regards to the "semantic information". 
> As far as I understood you use some icon names for that, but this 
> restricts the purpose of the annotations. Maybe it would be sufficient 
> to use a more crude solution, where you only specify that the 
> annotations/affixations must be sufficiently short in order to display 
> well in the popups, without going the full way to the semantic kinds.

There are currently only two places where affixation-function is used in 
the core.

One of them is the aforementioned help--symbol-completion-table.

Regardless of whether there will ever be a completing-read-function 
based on Company (it's not hard to do, actually; mostly the popup 
rendering method is holding it back, but I had it working with 
company-posframe), if help--symbol-completion-table-affixation plugged 
into :company-kind instead, the users could see the icons already 
familiar from completion code, from other backends, they wouldn't need 
to puzzle out what the "u", "a" and "c" characters mean. And other 
completion frameworks can pick up this feature too (maybe even reuse the 
icon mappings, we'll see). The user can also customize the icons' look, 
choose whether they should be SVG, text, icon font characters, or so on.

The other use is in read-char-by-name. And I can admit, seeing the 
characters in the first column is slightly better than following each 
completion. Not by much, they still work well enough as annotations, but 
seeing them in the first column is a bit tidier.

What would I do? First of all, keep them in annotations, because just 
one slightly better-looking use case does not justify the added 
complexity. If someone really wanted to improve positioning of 
annotations for that completion table, there are other options:

- Add a custom var that aligns all annotations to the right, then 
they'll also be in one column. Company has such an option already.

- Create a var specific for the default UI that would move the 
annotations to the left of the completions. read-char-by-name could bind 
it to t before calling completing-read. Then the *Completions* rendering 
code would do whatever is necessary to render it correctly at the 
requested side.

But since mule--ucs-names-affixation, aside from information, also 
contains presentation (spacing and alignment chars), it would be 
infeasible for a completion function that doesn't want extra stuff on 
the left to render its result on the right.

You can also note that the third (suffix) element is always an empty 
string in both of these use cases. So affixation-function was really 
added to be able to add a prefix.