[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Daniel Mendler
Subject: Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
Date: Wed, 21 Apr 2021 15:14:39 +0200

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]