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

[Eric Abrahamsen]

Philip Kaludercic <philipk@posteo.net> writes:

> I guess I can bring up a point I've been meaning to raise here for a
> while, and have discussed on other forums.
>
>> 1. Where invoked -- anywhere in emacs vs minibuffer.
>>    2.  When invoked -- as in find-file and friends vs everywhere
>>       something prompts in the minibuffer.
>>       3. Using what? the various backends that populate the available
>>          choices.
>>          4. How displayed: How the choices are displayed -- horizontal,
>>             vertical, and perhaps 3-d in the future.
>>             5. How completed: tab, vs prefix vs  fuzzy completion vs ...
>
> I have the feeling all these completion systems are encouraging
> confusion around how to use completing-read. That is the 0th point that
> is missing here: Are you completing (expanding text) or selecting
> (narrowing options).

[...]

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

FWIW I've come to the same conclusion in the past: that using
`completing-read' to select from a collection is essentially a (very
gentle) hack. More than once I've implemented my own mini-versions of
`selecting-read', and have always wanted something more general.

This would also allow us to expand our idea of how a thing is chosen:
instead of insisting that a string is completed, we could provide a more
general framework for choosing a "thing", where the things don't
necessarily have a meaningful string representation.

Anyway, I don't have a great solution to this problem. Here[0] is
something I wrote once to address this. I note this not because it's a
great solution (it isn't), but just as evidence of the need.

Eric

[0]: https://github.com/girzel/gnorb/blob/master/gnorb-utils.el#L222