[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.
- Simplification of `affixation-function`, Daniel Mendler, 2021/04/24
- Re: Simplification of `affixation-function`, Juri Linkov, 2021/04/24
- Re: Simplification of `affixation-function`, Stefan Monnier, 2021/04/24
- Re: Simplification of `affixation-function`, Dmitry Gutov, 2021/04/24
- Re: Simplification of `affixation-function`, Daniel Mendler, 2021/04/24
- Re: Simplification of `affixation-function`, Dmitry Gutov, 2021/04/25
- Re: Simplification of `affixation-function`, Daniel Mendler, 2021/04/25
- Re: Simplification of `affixation-function`,
Dmitry Gutov <=
- Re: Simplification of `affixation-function`, Juri Linkov, 2021/04/27
- Re: Simplification of `affixation-function`, Daniel Mendler, 2021/04/27
- Re: Simplification of `affixation-function`, Juri Linkov, 2021/04/27
- Re: Simplification of `affixation-function`, Daniel Mendler, 2021/04/27
- Re: Simplification of `affixation-function`, Dmitry Gutov, 2021/04/27
- Re: Simplification of `affixation-function`, Juri Linkov, 2021/04/28
- Re: Simplification of `affixation-function`, Dmitry Gutov, 2021/04/28