Re: [PATCH] `completing-read`: Add `group-function` support to completion metadata (REVISED PATCH)

[Dmitry Gutov]

On 29.04.2021 20:16, Daniel Mendler wrote:
> On 4/29/21 7:09 PM, Dmitry Gutov wrote:
> > If affixation-function didn't return a three-element list (and instead
> > only returned some focused information pertaining to a single value),
> > you wouldn't have this problem.
>
> I don't understand the argument here.

It's an argument about being able to "do more with less", and as a 
side-effect not have to worry about resolving potential conflicts in 
duplication of information.

> From my perspective the
> `affixation-function` is good as is. It is a generalization of the
> `annotation-function` which allows transformation of all candidates at
> once and it additionally allows prefixes. However one could discuss if
> the affixation function should be allowed to transform the actual
> candidate string, as has been mentioned in the discussion before. I
> think one can set text properties but one is not allowed to change the
> candidate string - this will break `choose-completion`.

I don't think anything like this necessarily has to break 
'choose-completion': the UI can remember the mapping between 
"transformed" and actual completion strings. It's just extra complexity 
in implementation.

On the higher level, though, I do believe completion tables should not 
define _presentation_, only information (with some well-defined 
exceptions, maybe).