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

[Dmitry Gutov]

On 08.04.2021 01:59, Philip Kaludercic wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
>
> > What I was disagreeing in the previous message, is whether it's worth
> > to create a semantic distinction between completing-read and
> > selecting-read. How would a Lisp author choose between the two? The
> > former should actually be more powerful (it will retain support for
> > TAB completion, and yet it could still be supported by selection-style
> > frameworks such as Company or Ivy);
>
> completing-read can be more powerful, as it includes expanding text and
> selecting items, but I if you are not interested in text-expansion you
> should probably limit yourself to selection,

Am "I" in this example the user, or the author of the caller code?

>  so that everyone is ensured
> to have the same presentation.

If that's the goal, why don't we make sure to include a "selection" 
interface that supports text-expansion as well, like both Company and 
Ivy do?

What's the purpose of having that distinction?

> > the latter, on the other hand, would effectively mandate a minimum
> > "niceness" of the UI (though not necessarily nicer than the former,
> > depending on user customization), but would be unable to support more
> > advanced completion tables. Such as ones with "fields" (which includes
> > file name completion).
>
> What do you mean by "niceness",

Niceness is subjective, hence the quotes, but we can probably agree that 
the UIs that do selection usually look fancier than the ones than don't. 
Or at least that's what I meant.

> and why would it not be able to support
> more complex tables?

If it can, that goes back to my question of why have the distinction.

If it allow selection UIs to not guarantee support for certain 
completion tables, I suppose that would allow people to create some 
specialized single-purpose UIs (perhaps mouse-driven?). Not sure if it's 
worth it, though.