Re: handling many matches

[Eli Zaretskii]

> Cc: address@hidden, address@hidden, address@hidden,
>  address@hidden, address@hidden, address@hidden,
>  address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Sat, 2 May 2020 19:58:08 +0300
> 
> >>> Like I said, I think the hopes it will deliver a significant enough
> >>> improvement are overrated.  It will certainly bloat the lists of
> >>> candidates by factors, which is why I think it isn't a very good idea
> >>> as long as we don't have some smart scoring of candidates.
> >>
> >> The amount of "bloat" will be strictly limited by the number of aliases
> >> we add.
> > 
> > Yes, and I tend to think we will add a lot.
> 
> That's a self-defeating argument.
> 
> By the amount of resistance from your side, my impression so far is that 
> we'll end up adding none (again).

Read my lips: I do NOT resist.  I'm warning the enthusiasts that they
might end up with a situation that is not better and potentially worse
than what we have today, and that the existing C-h commands will still
need to be used a lot to make any sense out of the results.

Other than that, feel free to propose any number of aliases that you
think might make sense.  I promise not to object, just make comments
and speak my opinions about the proposed aliases.

> > When the first few candidates are what I want, predictability goes out
> > the window.  I'm a happy user when I find what I'm looking for fast.
> 
> That rules out the "browsing an API" use case, when we need the "first 
> 20" or "first 40" candidates to be good.

Yes, because that use case shouldn't be served by completion, IMO.  If
someone wants a complete list of APIs, we should present the list of
APIs.  Completion is for _using_ one of the candidates, not about
looking through the entire list.