Better fuzzy search

[saveman71]

So I was motivated to solve #282 in a better way than #361 (not a Levenshtein distance, but the real thing like in sublime-text, as requested in the issue).

Sorry @nmitsou ^_^'

It looks like this for now:

Comparaison with #361:

• Highlighting of the matched text
• Maybe faster
• Cannot auto-correct typos (clogk -> clock)

This PR also adds support for multi-part highlighting.

Here is how the score is calculated:

• A positive match is given the base score of 20
• 30 points are given gradually with the percentage of characters matched
• 50 points are given gradually with the percentage of word starting characters matched (uppercase, or preceded by a whitespace). This allows queries that contain the beginning of a word to have a much better ranking.
• => This totals to a score going from 20 to 100
• The more fragmented the matches are, the less the result is significant (see this line for the actual formula).

Can someone test it and provide some feedback, especially on the ranking of the apps?

/cc @Neamar @nmitsou @emersion

[saveman71]

Note to self: aliases having a relevance of 10, they always are pushed back irrelevant results.

[nmitsou]

Yes I like it. Much better than #361.
Ordering between apps seemed fine to me.
Contacts were also higher ranked than apps which is good

[Neamar]

Thanks @saveman71 for this piece of content!
I'll add it to my own KISS and test it for a few days, since I don't want to rush any decisions regarding the ordering ;)

[Neamar]

OQ: do we want to enforce a capital letter for a first word?

[Neamar]

OQ: if appPos == 0, it may be worth boosting the app relevance too?

[saveman71]

OQ: do we want to enforce a capital letter for a first word?

There is no need to, appPos == 0 is there to handle that.

OQ: if appPos == 0, it may be worth boosting the app relevance too?

Well if appPos == 0 is true, we already add 1 to matchedWordStarts. Imo this is not necessary because it will allow something like Barcode Scanner to have the same score if we write Bar or Sca, and I think is a good thing.

[Neamar]

Works for me.

[saveman71]

Done /cc @Neamar

I removed the base score alltogether, should not pose any problem and I can't remember why it was there :(

I'll see with actual usage data if there is something to adjust.

[Neamar]

Been using it for a few days, seems good to me!

[nmitsou]

Hi @saveman71 and @Neamar ,
The recent crash on #387 must be related to this commit. Maybe the problem comes when the normalized app name has less characters than the original app name ?

The appPos variable in the for loop (AppProvider:38) ends on pojo.nameNormalized.length but inside the loop the counter has access to the pojo.name variable.

If pojo.name.length != pojo.nameNormalized.length then you get OutOfBounds

[saveman71]

Okay so this happens only if you have (at least) one app with some special characters in it, which I didn't have.
One solution would be to make Pojo.mapPosition() public so we can use it in AppProvider.
Another quick fix would be to stop using pojo.name alltogether, but we loose the ability to match an uppercase letter inside a word (e.g. "appProvider": we can't make a better score with the "P").

What could be done is to release the quickfix, and maybe sort out what can be done to fix the issue?

[nmitsou]

Yes, quickfix seems a good idea !