[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
Subject: Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
Date: Thu, 8 Apr 2021 00:56:42 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]