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

[Daniel Mendler]

On 4/21/21 11:20 AM, Philip Kaludercic wrote:
> > > It might therefore be necessary to actually implement a "selecting-read"
> > > function, that could be used more or less like completing-read, but that
> > > provides a better default UI not based around completing text but
> > > actually selecting objects/items.
> >
> > I attached a primitive version of selecting-read to this message. The UI
> > is horridly primitive, but the basic idea should be understandable.
>
> Here is an updated version, not with improved visuals:

I think it is interesting to experiment with actual use cases. Maybe it 
is a good demonstration to write a `read-buffer-function` and a 
`read-file-function` based on such a `selecting-read` API? The buffer 
selector is not hierarchical (at least as long as one leaves out 
perspectives or other levels), but there can be properties for 
filtering. In the case of the file selector one can experiment with 
hierarchical objects, and dynamic generation of the object tree. 
Partial-completion/initials can be used to filter/restrict the 
hierarchy. As with `completing-read` it should be possible to decouple 
the components in ui, filtering language and backend/object representation.

> I have also mentioned that a "translation function" could be written to
> translate completing-read calls into selecting-read. Here is an example
> that could be set to completing-read-function, even if it does not
> implement the entire interface:

This translation function implements only a small part of the 
`completing-read` interface (static completion tables). Did you look 
into how dynamic tables could be supported? Or is this something you 
would rather leave out to introduce a separation of `completing-read` 
and `selecting-read`? Separating the completion and selection use case 
may be technically cleaner. Going with a unified API could lead to a 
more consistent system overall?

Daniel