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

[Dmitry Gutov]

On 07.04.2021 17:44, Stefan Monnier wrote:
> > > 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.

I don't know if they really do minimize it: the TAB binding in 
company-active-map, pressing TAB once in Ivy, and likely equivalent 
bindings in other systems, all complete the "common" part to let the 
user continue typing to resolve ambiguities.

That's something a pure "selection UI" wouldn't have. And I do think it's

> 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.

A try-completion operation might indeed be complex to implement for some 
completion styles, but it's not like we really tried it. Perhaps it 
would be difficult to design the "externally filtering" completion 
style, together with this new operation, but I feel like we've never 
even reached the point if trying to do that, having met other 
difficulties along the way.

Perhaps we could dispense with this feature when designing a new 
completion table interface, just for simplicity's sake (though I don't 
see why we couldn't add it as an option in a later revision).

What I was disagreeing in the previous message, is whether it's worth to 
create a semantic distinction between completing-read and 
selecting-read. How would a Lisp author choose between the two? The 
former should actually be more powerful (it will retain support for TAB 
completion, and yet it could still be supported by selection-style 
frameworks such as Company or Ivy); the latter, on the other hand, would 
effectively mandate a minimum "niceness" of the UI (though not 
necessarily nicer than the former, depending on user customization), but 
would be unable to support more advanced completion tables. Such as ones 
with "fields" (which includes file name completion).

So it seems the guiding principle might be: use selecting-read for 
"simple" completion tables. But I don't see why this direction is desirable.