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

[Philip Kaludercic <philipk@posteo.net>]

Daniel Mendler <mail@daniel-mendler.de> writes:

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

I will try to look into this as practical examples, after the
performance has been improved and the query language is more than just
regular expressions. It hope that it would demonstrate limitations of
the current interface.

> As with `completing-read` it should be possible to decouple the
> components in ui, filtering language and backend/object
> representation.

Of course, the current implementation also provides this with the
generic functions on the one side and selecting-read-function on the
other. The current UI is pretty hacky, so I'd expect people with more
experience and enthusiasm when it comes to come up with better
solutions.

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

The translation function is currently more of a POC, as there were some
messages on that topic in previous thread. It is entirely debatable if
selecting-read should provide a super-set of features that
completing-read provides, or it should just have an intersection.

I haven never really used dynamic tables for completing-read, so I'll
have to look into that and see how it might apply to selecting-read, if
at all.

> Daniel
>
>

-- 
	Philip K.