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

[Dmitry Gutov <dgutov@yandex.ru>]

On 10.04.2021 10:09, Eli Zaretskii wrote:

> I think our interpretation of "completion vs selection" are different,
> at least to some extent.  For me, completion is for when you (almost)
> know what you want to type, and type enough of it to have a single TAB
> more or less do the rest of the job.  IOW, it's a typing-saving tool.
> Selection is for when you don't know what to type, and need the full
> list to choose from.  IOW, it's a discovery tool.

I don't think we disagree too much, it's just there are cases where 
"completion" (as defined by you) is really inconvenient: you both don't 
know what you want to type, and the options are hard to type as well.

But there are also cases (IME) when you don't necessarily know what to 
type, but you want to continue typing. That is the scenario of an 
average (or, perhaps, a beginner) Java developer typing in a IDE: when 
you don't remember the method name, you try to guess by typing a 
relevant word, see what names match, and often enough get it right.

> With that in mind, completion for symbols in invoking M-. and
> completion for file names in invoking some file-related command have
> the same traits, at least for me.

I don't always know what file name I want to type either, and either 
guess by typing a part of the word and pressing TAB. Or type multiple 
relevant words at once, if the completion UI allows it (that's very 
helpful for choosing a project-relative file name in project-find-file).

> Where selection is needed, we pop
> up the XREF buffer at the end.  This default operation makes sense to
> me.

The problem with it is the user can end up in two different states: 
either having jumped to the target location (if there is just one), or 
having a list of all matching locations displayed. And then do extra 
work to get where they wanted to go.

Whereas we want (I think) the process to always end up at the location 
which the user intended to get to.

> By contrast, using xref-show-definitions-completing-read, I'm
> asked to choose twice: first in a "normal" completion context, then
> again in a strange way (it says "Choose" without showing me anything
> to choose from, and I need to type TAB to see a *Completions* buffer).
                       ^
                       this is the most puzzling aspect of it indeed,
                       as we've mentioned here.

> I guess to each their own, but the latter method strikes me as weird
> and inconvenient.

What I'm saying is the process is handicapped by the limitations of the 
default completion UI.

With Ivy (which I use only for 3 commands), the process becomes much 
more obvious and faster. Wish you could try it.

And it's not something I invented: a user contributed the first version 
of xref-show-definitions-completing-read, which we then tweaked for 
efficiency, and it turned out to result in a very sensible workflow. Not 
with the default completing-read, though.

> IMO, its place is in Company-style "completion"
> when writing code -- there one would like to see the list of
> pertinents alternatives to select from without typing anything, not
> when the user invokes a command and needs help in typing as few
> characters as possible.

Not 100% sure I understand, but if you meant the second step could use 
Company-style completion (which can also work as selection-type UI), 
then we're in agreement.

But Company is just as useful in "needs help in typing as few characters 
as possible" kind of scenarios.