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

[Philip Kaludercic]

Daniel Mendler <daniel@mendler.net> writes:

> On 4/7/21 4:15 PM, Philip Kaludercic wrote:
>> I think I've also mentioned that selection can be hierarchical. I think
>> this too would be applicable to insert-char, considering how unicode
>> divided into groups and subgroups.
>
> I agree that hierarchical selection can be useful when browsing
> through a structure. However when doing a quick selection, I perceive
> it as slower. For example there is imenu, where you have to step
> through multiple layers of the hierarchy to reach the destination.

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.

>> All of these features already exist, partially or only to the degree it
>> is found to be necessary. Eg. ibuffer has hierarchies and the ability to
>> filter by some preconfigured predicates. I think that there is a general
>> pattern here that can be exploited to make the overall experience more
>> uniform.
>
> I wonder how all these use cases could be unified under a common
> API. I would certainly not want to lose the current fast, flat
> selection mechanism via completion as offered by `completing-read'.

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.

> Regarding predicates, there is an idea how this could be integrated
> with completion. One can implement a completion style which support a
> filter language, depending on the completion category. The completion
> style can then execute the filter predicates on the corresponding
> objects. However such an approach certainly takes it a bit far as
> completion styles are concerned. I think Icicles offers options to
> filter within completion based on predicates?

I think there is more value in keeping completing-read simple, and focus
it on actual text expansion. Completing-read will probably never really
be overcome, just because there will always be software that continues
to use it.

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.

> Daniel Mendler
>
>

-- 
        Philip K.