Re: handling many matches

[Dmitry Gutov <dgutov@yandex.ru>]

On 02.05.2020 19:31, Eli Zaretskii wrote:

>> All fuzzy completion systems do that. Generally by scoring how well each
>> string resembles the input string.
> 
> That criterion alone is not enough, IME.  It is also important
> (sometimes much more important) what I'm doing, in what major mode,
> my previous completion attempts, etc.

Your argument here has merit. The difficulty is in writing an 
appropriate scoring algorithm.

The "what I'm doing" and "what major mode" conditions could be solved by 
pre-filtering in a lot of cases, though.

>>> 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).

>>> We need scoring that "learns" from what I do/did recently,
>>> and from my habits.  Otherwise the list of candidates will remain
>>> hopelessly long, with no promise of having what I'm really looking for
>>> anywhere near the beginning.
>>
>> There are systems like that, including in third-party Emacs packages.
>> Personally, I'm not fond of the idea (the unpredictability, first of
>> all), and I'd rather we polish the current scoring algo first.
> 
> 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.

IOW, the algorithms should be everything to everyone. Which is 
difficult, but we should try to approach it.