Re: Simplification of `affixation-function`

[Juri Linkov]

> I think it is slightly confusing and unnecessarily complicated. But if you
> want to retain backward compatibility, there is no way back. However since
> the `affixation-function` has only been introduced recently, there should
> still be a time window to change the definition? There is no released
> version of Emacs with `affixation-function` support.
>
> (If it is decided to change the definition it should be feasible to go over
> all ELPA/MELPA and apply patches to all packages which already make use of
> the `affixation-function`.)

I'm not sure if breaking the existing API is worth the trouble.

We could just change the documentation of ‘affixation-function’ to define
only one supported way of using the “completion + prefix + suffix” format
to reduce confusion.

>> More than three elements are already supported since e.g. the
>> total length is calculated as a sum of lengths of all strings:
>>    (apply #'+ (mapcar #'string-width str))
>
> I see. So all the later elements are suffixes and concatenated? This seems
> like an unnecessary completion given that the completion-table implementor
> can already concatenate all the suffixes.

This is just implementation detail, there is no intention to support
more suffixes.

> Or is the idea that the UI can show all these suffixes in some kind of
> table-like view?

Currently I'm trying to use tabulated-list-mode in the completions buffer.
But even in this case there is no need to add more suffixes for more
table columns.

> My proposal is to only allow three-element lists and remove support to
> specify only the suffix.

Supporting only the suffix still is necessary for the ‘annotation-function’.

> And one could keep the door open by allowing more than three element lists
> for additional annotations. Let's say you want to specify some additional
> help/tool-tip text for example.

I'd prefer to support additional text using keywords, e.g.

  ("completion" "prefix" "suffix" :help "Help text")