Re: complexity in minibuffer

[Dmitry Gutov]

On 02.06.2021 18:37, João Távora wrote:

> > Some transformations will be more costly than others (even if the
> > current examples are pretty fast), so we shouldn't call them unless we
> > know a given completion will be displayed.
>
> You're again misunderstanding my suggestion, and bringing
> up the same concern, which I've already answered. Let me
> try again. Call the total group of completions A. Invoke the group func
> for every c in A, yes.  _Don'_t transform every completion until you know
> which ones to display, call this group D.  Instead allocate a transform
> function and attach it to each c in A.  Then call this transform for each
> c in D.

I think I get it now, thanks: key-and-transform, which you proposed 
group-function would return, would have a transformer _function_ in its 
CDR. So overall it should be approximately as powerful as the current 
approach. An allocation of 10000 lambdas in the interpreter takes about 
4 ms here, which is not too much.

I could still describe some downsides (opaque properties on strings: 
harder to examine them; longer backtraces - that is something you have 
criticized in another proposal of mine, in a different discussion).

Overall it's a valid idea, not without its elegance, but I don't think 
it's a definite enough improvement to ask everybody to rewrite their 
code, which uses the current definition of group-function.

> My suggestion can also scrap the double invocation X (getting
> the group may be expensive, for some backends).

If that ever turns out to be a problem, we can of course use text 
properties and/or a hash table somewhere. But this is an argument about 
the implementation strategy for minibuffer.el, whereas the 
group-function convention affects more than that.