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

[Philip Kaludercic]

Gregory Heytings <gregory@heytings.org> writes:

>>> 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.
>>
>
> Okay, I think I understand your viewpoint (a bit) better now.  But:
>
> 1. It seems to me that the UI you have in mind is closer to
> 'transient' than to 'completing-read'.

Perhaps, but my understanding of transient is that it tries to be a
better C-u.

> 2. That UI already exists to some extent in Emacs, for example dired,
> imenu (either in the menu bar or bound to a mouse event), ibuffer, the 
> speedbar, ...

How is this a "but"?

> 3. Such a UI probably wouln't fit in the (by definition) limited space
> of a minibuffer.

I think so, I don't think that it should have to.

-- 
        Philip K.