Re: Simplification of `affixation-function`

[Dmitry Gutov]

On 27.04.2021 19:48, Juri Linkov wrote:
> > 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.
>
> affixation-function was an improvement over annotation-function,
> but nonetheless it has limitations too.  What would be a better thing is
> like Daniel proposed a new meta `group-function`, I'd imagine a similar
> meta `format-function` that could receive a candidate and return
> a string to insert to the completions buffer.

That would also conflate information with presentation, and thus only be 
usable for the default completion UI. And not ideal even for that purpose.

> Then the caller e.g. help--symbol-completion-table could define whether
> to append "u", "a" and "c" in parens by using on a candidate something like
> (format "%s (%s)" cand (cond ((fboundp (intern cand)) "f")) ...),
> or prepend a dimmed letter as a prefix, or to use an icon.

Do you use Company? Take a look at what elisp--company-kind does.

The fact that the space of allowed values is constrained makes the 
returned information really more useful.

And here since you do not document which values (strings, characters, 
etc) the prefix returned by affixation-function can take, their 
usefulness is limited. The user can't be sure what "c" means: it's 
"command" here, but could be meant as "constant" by another affixation 
function. Is "m" a "macro" or "method"? "f" stands for "function" or 
"field"?

And also because of that no completing-read UI can replace these 
characters with any alternative (e.g. graphical) representation.