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

[Dmitry Gutov]

On 10.04.2021 17:40, 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.

Hi Philip,

I've tried this new code, and it seems to work: the function pops a 
buffer which responds to RET, which in turn returns the appropriate item 
to the caller.

I'm not sure how to discuss or critique it. Some thoughts:

- It uses data structures quite different from what completing-read 
uses. That's pretty inconvenient, and requires a mental switch. I'd 
rather the two functions (or some future versions of them) were more 
similar in shape, yet (obviously) different in behavior.

- It's not pretty/comfortable to use (yet?). A lot of discussion and 
decisions might come from trying reaching the state where people like it.

Speaking of what I see in selecting-read-mode-map, in particular

  (define-key map (kbd "/")           #'selecting-read-narrow)

, it invokes the image of a more ponderous, explicit interaction than 
the snappy selection UIs I've used and liked in the past.

> Because I'm not just now primarily concerned with what completing-read
might look like, it doesn't do "automatic narrowing" like Helm or
Ivy.

It doesn't do quick cycling with TAB either, though.