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

[Drew Adams]

> If we have a tree structure one can have some
> tree-like visualization (like the sidebar tree browsers) or have an
> outline like in org-mode. But how would you actually navigate quickly?
> Using Avy-like keys? What if the structure does not fit on the screen
> easily, what if there are cycles, ...?

Just pattern-match against candidates that are "full".
You can even match circular/cyclic candidates, if you
use predicates.  (An infinite candidate can't be shown
as a printed representation, but it can be matched.)

> In the case of `completing-read` the current solutions are all pretty
> simple. If we ignore the special cases of dynamic completion tables, you
> just hand it this big flat list and filter until the data set becomes
> manageable.

Yes.

> While some use cases seem to be a bit pressed into that
> framework (like if you have a hammer...), I think it works surprisingly
> well in many scenarios with a large number of unstructured candidates.

Yes.

> To me it seems much harder to imagine something general which caters for
> all selection needs using an outline-like visualization.

The visualization is separate from how things are
matched.  Your eye can match something graphic,
but your input filtering can match against its
"name" (some textual way to identify it). or its
position in the completion list.

Wrt position: You can have candidates that are
different but that have the same textual
representation, and so are matched by the same
input.  When sorted you can traverse (cycle among)
a set of candidates in a given sort order to
choose one.

An example of this is Icicles search.  Your
input might match multiple candidates exactly -
they might have exactly the same text.  But
you can navigating among them (cycling), to
choose in context.