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

[Dmitry Gutov <dgutov@yandex.ru>]

On 09.04.2021 08:56, Eli Zaretskii wrote:
>> I can imagine cases which pretty much*need*  selection-like
>> interface. xref-show-definitions-completing-read would be one
>> example (it's relatively awkward to make the choice using
>> completion, though certainly not impossible).
> I don't think I understand how xref-show-definitions-completing-read
> is different from, say, read-file-name.  Can you explain?

We've touched on this previously in the poll/discussion about the default:

https://lists.gnu.org/archive/html/emacs-devel/2021-01/msg00029.html

The values which xref-show-definitions-completing-read asks you to 
choose from are relatively complex, and hard to type out.

Further, there's often only 2-3 values to choose from (in the Elisp's 
case, at least), so choosing the first one should be a frequent enough 
occasion.

With a selection-based menu you look at all options and make a choice: 
often just press RET; maybe press TAB, or C-n, or <down> a few times 
before that.

With completing-read, you have to press TAB first, to see the choices, 
and then type some of your choice's contents, keeping in mind perhaps 
its distinguishing characteristics. That's simply more effort than the 
other approach.

File name completion is different because you're not as likely to simply 
choose the first option, there can be a *lot* of files in the dir, and 
typing an average file name is much easier.

Mind you, I generally prefer completion UIs that show the options before 
you start typing, but xref-show-definitions-completing-read makes a 
really strong case for it. Which is unfortunate, because otherwise it's 
my #1 choice for xref-show-definitions-function's default value, and 
changing Emacs's completion UI is not in the cards in any near future.

So I would only be happy if you disagree with this assessment.