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

[Philip Kaludercic]

Daniel Mendler <mail@daniel-mendler.de> writes:

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

I'm still thinking about all of this, and have to find the time to
implement a prototype. It might make sense to have a similar approach to
completing-read, where a variable like completing-read-function can
change everything.

A tree-like visualisation would probably make more sense, as long as it
can be manipulated using the keyboard. I mentioned org-mode thinking of
the org-cycle command, and how it allows you to hide and show subtrees.

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

I use the default completion system, so for me it is not about filtering
a data set but expanding a string. Just to reiterate, this is exactly
the point I am bringing this up.

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

It might be that it is too far fetched, but I have a (vague) idea how
selecting-read might look like and behave. A proper analysis of the
current situation and (imo) misuse of completing-read would probably be
necessary before actually building anything. 

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

I don't start with any set, I start with an (usually) empty prompt and
type a few letter, tab to check and then press enter. I try to avoid
unnecessary UI movement, which is why I have set
completion-cycle-threshold to t, so that I have to manually request a
"*Completions*" buffer. But even so, there are situations where
selection would be preferable. Usually when I don't know what my options
are.

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

Well FWIW I'm not. I used Ivy for a long while, but ultimately gave it
up. There has been a lot of talk about {Selectrum,Embark,Orderless,...}
recently but I am not convinced that the approach these packages take
are on the right level. The only way to find out is to try something
else on the level I suspect there might be more potential for a better
solution.

> Daniel
>

-- 
        Philip K.