[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: handling many matches

From: Dmitry Gutov
Subject: Re: handling many matches
Date: Sat, 2 May 2020 19:13:18 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 02.05.2020 16:52, Eli Zaretskii wrote:

If by "look" you mean to the user, then I envision a list of
completion candidates that somehow "knows" what I'm after, and places
those likely guesses near the beginning of the list.

All fuzzy completion systems do that. Generally by scoring how well each string resembles the input string. Whether there are gaps between the matched characters, and so on. Our 'flex' completion style has this feature as well.

and only after that consider changes, like the
proposed "namespacing" of APIs, that will allow users to use
completion as a substitute for Help commands.

Namespacing of APIs is a step that should help the users with the
current default completion strategy.

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. I think there's a general agreement that we shouldn't go overboard.

It is IMO a bad idea to
flood the completion lists with many dozens of candidates and force
users to wade through them.  I certainly wouldn't call that "progress"
for Emacs.

Is that what fido-mode does? People seem to like it.

I don't have a good idea of what fido-mode does, but the rather foggy
idea I do have says it just applies fuzzy search criteria, attempting
to find non-literal matches.  If this is so, then I don't think fido
cuts it.

You can try it. It uses 'flex', and thus it sorts the matches based on scores.

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.

But it's good to have it customizable.

Compare with the Internet search: it almost always brings me hundreds
of hits, but I normally find what I was after among the first dozen.
Even more spectacularly, when I type a search phrase into the search
box, it guesses what my search phrase will be, and the guesses are
almost always very accurate, so much so that if I don't see a long
enough list of reasonable candidates, I usually go looking for some
typo in what I typed (and almost always find it).  Some of the
candidates are based on my previous search phrases, and the ones I
typed are always ready to be reused, with a special indication to let
me know I recently used them.

Right. There's some benefit in that. But also note that Internet searches can't really use fuzzy matching, at all. I'd venture to say that it will be difficult to combine fuzzy searches and historical scoring, too.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]