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

[Daniel Mendler <mail@daniel-mendler.de>]

On 4/25/21 9:35 PM, Dmitry Gutov wrote:
> The result looks nice (when enabled), though this function still doesn't 
> work very well with the default completing read. So whether this feature 
> works okay will depend on the alternative UI used.

Dmitry, thank you for looking at the patch!

What do you mean exactly by "it does not work well"? There was an issue 
with `choose-completion` which I just fixed in the revised version of 
the patch, where the command `choose-completion` returned the 
transformed candidate.

> I wonder if there can be other examples of group-function usage added 
> which work okay with the default completion UI.

I am sure we can find more uses. But this functionality is also targeted 
at package authors who want to write commands with an UI enhanced by 
grouping.

> Speaking of group-function's implementation there, the text-properties 
> approach seems like an overkill since we can reliably string-match 
> anyway. But it's a minor thing.

I've chosen the text property approach such that the group title 
retrieval does not lead to allocations (transform=nil). The 
transform=nil call is performance critical for continuously updating UIs 
like Icomplete, Vertico etc., since the candidates are grouped after 
sorting. When displaying the set of candidates in the *Completions* 
buffer or a subset of the candidates in the minibuffer, the allocations 
do not hurt as much.

> Another minor issue is that the docstring still says "Return title of 
> candidate" rather than "group title" or "group name".

Okay, I will change this.

Daniel