[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: Daniel Mendler
Subject: Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
Date: Wed, 7 Apr 2021 18:57:02 +0200

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


reply via email to

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