On 4/19/21 11:52 PM, Stefan Monnier wrote:
>> But if this get improved, people may throw more candidates at it and
>> then we will end up again with a threshold.
> 
> That's the main point, indeed: rather than try to handle larger sets, we
> want to avoid larger sets.  

I agree - it is always good to cut off a large amount of the work early on.

> That's why we have
> `icomplete-show-matches-on-no-input` and `company-minimum-prefix-length`
> (tho there can be other approaches like pushing the processing of sets
> to a separate async process).

Yes, these are reasonable settings. However many people like to see 
candidates up front, me included (at least currently, taste changes) - 
like in Ido, Ivy, Selectrum, Vertico etc. Then I am not very fond of 
operations happening after some idle time. Having an input limits feels 
more deterministic.

If Emacs can be made such that it fits for different usage patterns 
that's great. But I would not over do it in optimizing for a million 
candidates - therefore my poor man's "solution" of a threshold in Vertico.

Btw, I attached the updated patch for the boundaries. I am not sure if 
the approach I took there is a good one, this works only in restricted 
set of scenarios (not with partial-completion/initials unfortunately). 
So this should be discussed.

Then you mentioned test cases - to clarify, do you want to see some kind 
of integration test where a mockup minibuffer-completion-table is set-up 
and the results of `completion-all-sorted-completions` are checked, or 
some smaller tests of the helper functions? I looked briefly into 
test/lisp/minibuffer.el - the test should probably go there?

Daniel