|
From: | Dmitry Gutov |
Subject: | Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico |
Date: | Sun, 11 Apr 2021 03:18:41 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |