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

[Philip Kaludercic]

Gregory Heytings <gregory@heytings.org> writes:

>> 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).
>>
>
> I've been thinking about this, and I'm not sure I understand what the
> real difference between "completing" and "selecting" is.  Do I
> understand correctly that the difference is between, for example,
> expanding command names (completing), and choosing an emoji in a list
> (selecting)?

I think the main difference is in the UI. The default completion UI for
Emacs will expand text in-place. M-x tdoe <TAB> becomes
toggle-debug-on-error, with the initials style. This appears to make
sense for well structured text, such as commands or files.

Selection are probably situations where you want more visual feedback,
and it would make sense to present a list/tree by default. I don't think
that this has to be strictly about text.

Generally speaking, you can complete the textual representation of
anything or select the object themselves. I don't think that either is
always better, but I think we can do better than selecting textual
representations.

>> 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.
>>
>
> Given that Emacs is primarily keyboard-driven, it seems to me that the
> most efficient way to select an item is, and will always be, to use a 
> textual representation of the items in the list to select them.  C-x 8
> RET does this, you (can) select an unicode character with its name.
> For example C-x 8 RET inf RET inserts the infinity symbol.  Or course
> you could also navigate through the ~45000 unicode characters to
> select the one you want, but that would be far less efficient.

I don't think that something like selecting-read should just present a
list of string. One might imagine using methods to allow an extensible
way to control the presentation. Currently the standard procedure is to
generate a collection and it's labels before passing it to
completing-read. That's what insert-char does using ucs-names. I could
imagine that selecting-read takes a list of characters, and uses a
method to generate the textual representation of every entry. Ideally it
could lazily only calculate those entries that are currently being
displayed.

By not limiting yourself to precomputed text, the interaction can also
be improved. Taking insert-char as an example again, you might be
interested in the kind of character data that C-u C-x = provides. That
might just be a tab away. You might also be able to filter more
effectively, by narrowing the selection based on such properties.

I think I've also mentioned that selection can be hierarchical. I think
this too would be applicable to insert-char, considering how unicode
divided into groups and subgroups.

All of these features already exist, partially or only to the degree it
is found to be necessary. Eg. ibuffer has hierarchies and the ability to
filter by some preconfigured predicates. I think that there is a general
pattern here that can be exploited to make the overall experience more
uniform.

-- 
        Philip K.