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

[Arthur Miller <arthur.miller@live.com>]

Philip Kaludercic <philipk@posteo.net> writes:

>> 1. Where invoked -- anywhere in emacs vs minibuffer.
>>    2.  When invoked -- as in find-file and friends vs everywhere
>>       something prompts in the minibuffer.
>>       3. Using what? the various backends that populate the available
>>          choices.
>>          4. How displayed: How the choices are displayed -- horizontal,
>>             vertical, and perhaps 3-d in the future.
>>             5. How completed: tab, vs prefix vs  fuzzy completion vs ...
>

I think point 1, 2, 4 and 5, belong rather to same "layer": presentation
and user interaction, while point 3 is rather about internals, how they
process data internally.

What I personally would like to see Emacs provide is some mean to do 3.
in terms of concurency, so tools like Helm can search in different sets
of candidates in parallel. There are threads in Emacs already, but 
maybe it is too low level of interface. A tool could maybe give Emacs a
list of sets (places)and a list of regexes to search for and Emacs would
do this concurently and return a list of candidates.

For the presentation and interaction I don't think there needs to be
done much more. It is just buffers and windows and mode maps, Emacs
already has lots of tools to work with those. A tool can take a list of
candidates and present it in different ways, let user interact with that
list in buffer, minibufer or whatever author of the tool feel is the
universe's way of perfect interaction.

> they collect all the options of a collection

Can we just say they collect "candidates" or "completion candidates"
instead of "all the options of a collection"? I hope you don't mind,
just for a bit of clarity.

Helm does auto complete when the candidate is non-ambigous. But no framework
can auto complete if the choice of possible completions is non-ambigous,
i.e. there are more than one candidates.