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

[Daniel Mendler <mail@daniel-mendler.de>]

On 4/7/21 6:20 PM, Philip Kaludercic wrote:
> Well that is because imenu presents the options in the minibuffer, and
> you have to go through the menu step-by-step. What I'm talking about is
> a direct hierarchical visualisation, that should be navigable with the
> intuitiveness of org-mode.

This is a bit vague. 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, ...?

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

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

> I don't think that selecting-read should replace completing-read. Rather
> there are cases where completing-read is used like selecting-read, that
> would profit from actually being selected by everyone, and not just
> those who use completion frameworks that interpret completion as
> selection.
> I think there is more value in keeping completing-read simple, and focus
> it on actual text expansion. 

Agree. Regarding "interpreting completion as selection" and "text 
expansion", I am unsure if there is a big difference. You always start 
with a set of possible completions and only for very few styles a prefix 
completion is possible. This has been mentioned before in this thread, I 
think.
> In some sense the abundance of solutions around completion show that the
> community wants something else than what completing-read provides by
> default. I get why, as a lot of packages use completing-read. But it
> might be better to start from the position we want to achieve, instead
> of hacking our way towards that end.

I am actually quite satisfied with the status quo given the many package 
options, where everyone seems to find a good fit. But maybe the name 
`completing-read` does not reflect anymore what it is since it is often 
used for something else than simple prefix expansion. The prefix/basic 
completion is baked pretty deeply in the completion APIs, e.g., 
`all-completions` and this got relaxed afterwards.

Daniel