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

[Philip Kaludercic]

Dmitry Gutov <dgutov@yandex.ru> writes:

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

I think it would be possible to also support alists, hash tables,
vectors but I'm not sure if it is necessary. Functions might be
interesting to consider.

But this raises a more general question, of whether selecting-read and
completing-read should be drop-in replacements of one another. I would
hesitate, as completing-read isn't the cleanest interface. Instead it
might be cleaner to also provide a compatibility function with the same
interface as completing-read to translate into selecting-read.

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

Of course, this was the product of maybe 1-2 hours of programming. I
don't have much experience with designing Emacs UIs, so I didn't get
much done. Ideally the UI should either be configurable or multiple UIs
should be provided to please every taste.

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

Yes, I'd like to have that too, but I first wanted to get some comments
on the internal architecture, before I spend more time with the UI.

-- 
        Philip K.