[Top][All Lists]

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

Re: Simplification of `affixation-function`

From: Dmitry Gutov
Subject: Re: Simplification of `affixation-function`
Date: Mon, 26 Apr 2021 01:31:53 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1

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.

reply via email to

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