Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico

[Stefan Monnier]

>> Most completion frameworks I have looked at seem to limit themselves to
>> the latter. To simplify, they collect all the options of a collection
>> using all-completions and then narrow it depending on user input. Ido
>> and all it's descendents (Ivy, Helm, Selectrum and now vertico) seem to
>> be based on that approach.
> I don't think that's true.

I don't think the frequency of refreshing the list of candidates is what
he was referring to, but rather the support for "TAB completion" which
corresponds to the `(completion-)try-completion` operation which is
expected to extract the commonality between the various candidates.

Most completion frameworks minimize the importance of this operation (or
don't support it at all) and instead focus on displaying the set of
candidates, filtering them, and finally picking one of them.

Seen from the point of view of the implementation, I can understand why
it's done this way: the more sophisticated your completion style is, the
harder it gets to implement `try-completion` (and often the less useful
it gets as well.  E.g. for things like `flex` it's very common for there
to be no commonality at all to extract).

So removing the `try-completion` operation makes for a simpler API
and a simpler implementation (it also simplifies significantly the
quote/unquote handling) and users who like things like `flex` won't even
notice the difference.


        Stefan