Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and, annotations

["João Távora" <joaotavora@gmail.com>]

Daniel Mendler <mail@daniel-mendler.de> writes:

> On 6/1/21 8:47 PM, João Távora wrote:
>> I really doubt this "matters when scrolling", as grouping would be
>> called once per filtering, and scrolling is just getting at each
>> candidate's transform.  If anything, if you take the last option, it
>> could _speed up_ scrolling (and the cost of some more initial latency).
> Yes, you are right about that. It matters when refiltering the candidate
> list, which happens quite often in Vertico or other continuously
> updating UIs.

Indeed, and losing 20 seconds (example above) for each refiltering is
normally prohibitive.  That's why icomplete (and probably all these
other ui's have while-no-input), effectively interrupting the
processing.  So it also doesn't matter when rapidly typing.  It's only
when the user "settles" on a value.

>> I've told you the point.  A simpler minibuffer.el code, possibly with
>> less branching and logic, which might even be faster.
> I doubt that you manage to make it simpler. If you indeed manage to
> make [it] simpler I will propose a counter patch based on the current
> definition which is as simple.

If I or you or anyone else manages to make X or Y simpler, we judge that
work based its merits and drawbacks.  Tends to work better.

> There is also no need to rediscuss a fine solution without making a
> better and proper counter proposal.

My proposal's merits are a simpler protocol and simplified
minibuffer.el.  Its drawbacks are what I think are a negligble
performance hit in non-essential scenarios.  You may not agree with this
assessment, but there's nothing "improper" about it.

> I have made many material arguments and you ignore them.

A bizarre claim: you pointed to performance loss and to a specific
function that iterates all completions, and I spent the effort to look
at that function, benchmark variations on it and share my results with
you.  I found that even with a very large set of completions only a
small amount of time is lost (around 3-5%) even if you happen hit an
unlucky GC.

Sure you may think that's unacceptable. But when? In what circumstances?
For example, you once said it "matters when scrolling", but then we
established that it doesn't.

> I benchmarked this heavily in my Vertico UI. So I can assure you that I
> looked into this. I rely on this for the performance of Vertico and for
> the performance of other continuously updating UIs.

I'd rather learn details of those experiments and their results.  The
only thing I have are measurements and methodology that I shared with
you and which don't point to anything serious.

João