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

[Philip Kaludercic]

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

Most completion frameworks I have looked at seem to limit themselves to
the latter. To simplify, they collect all the options of a collection
using all-completions and then narrow it depending on user input. Ido
and all it's descendents (Ivy, Helm, Selectrum and now vertico) seem to
be based on that approach.

Try-completion for partial completion seems to only be used by the
default completion system, which I think is a shame. I noticed this when
implementing a completion-style based on Peter Norvig's spell
checker[0], that would recognize minor typos such as M-x
evla-buffer. IIRC this kind of behaviour is not strictly correct for a
completing style, but that is another matter.

The issue I see here is how packages (in and outside of Emacs) use
completing-read. When package developers that use these newer completion
frameworks test their functions, they might tend to assume that
completing-read means "selecting-read", i.e. the user is presented a
list of options that they can choose from. A personal example is a
package I created a while back to insert eastern emoticons[1]
(¯\_(ツ)_/¯, ´ ▽ ` )ﾉ, Σ ◕ ◡ ◕, ...), that was convenient to use with
Ivy but since I have stopped using it has become inconvenient, as I
don't have most of the letters on my keyboard to complete such an
emoticon.

Nevertheless completing-read seems to have satisfied an existing need
for a simple mechanism to implement selection. There are packages in
Emacs that do this, but they all have to re-implement selection
interfaces, as there is no default way of doing it (that I know
of). Think of recentf's menu or more complex examples such as reftex's
TOC, that includes hierarchical structures.

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.

[0] https://norvig.com/spell-correct.html
[1] https://git.sr.ht/~zge/kaomoji

-- 
        Philip K.