|
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 selection. I think there is more value in keeping completing-read simple, and focusit 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
[Prev in Thread] | Current Thread | [Next in Thread] |