Fuzzy application search is not consistent

[gandalf3]

Environent

• Albert version: 0.9.3
• Operating system: Archlinux
• Desktop environment: Openbox
• Qt version: 5.8.0
• Source: AUR

Steps to reproduce

1. Enable "Fuzzy" in the application search plugin settings.

Expected behaviour

Application search to return results for partial matches and matches in application descriptions, while still prioritizing results where the search string matches the name from the beginning.
For instance, searching for "bump" or "normal" would find

AwesomeBump
Program designed to generate normal, height, specular, ambient occlusion . . .

But would list from-the-beginning name matches first, e.g. "Bumpyride" or "Normalcy" (names are imaginary, for the sake of example).

Actual behaviour

On my machine, no results or incorrect are returned "bump" and "normal". (awesomeBump is a real program I have installed and searching for "aw" or "awesome" etc. finds it as expected):

Where a search string beings matches a middle part of the name, I sometimes get no results.

"office" finds "LibreOffice" (though interestingly not "LibreOffice Writer", "LibreOffice Calc", etc.) "bump" does not find "AwesomeBump".

Where a search string matches part of the description, I get no (meaningful) results. In this particular case I get three results which don't seem to contain the search string at all:

Additionally, immediately after "Fuzzy" was enabled, no application results would be returned at all until Albert had been restarted.

[ManuelSchneid3r]

I dare to say that this is not 0.9.3 descripton matching has been disabled https://github.com/albertlauncher/albert/commit/b036848499725241b1feac2cc72fe880c09ddd01

[gandalf3]

@ManuelSchneid3r albert --version returns albert v0.9.3. The "expected behavior" section I wrote is mostly based on how I imagine fuzzy matching would work, and likely has no relation to how it may actually be intended to work.

By the way, your link leads to a 404 for me.

[ManuelSchneid3r]

https://www.apt-browse.org/browse/debian/wheezy/main/amd64/kfloppy/4:4.8.4-1/file/usr/share/applications/kde4/KFloppy.desktop

The generic name is floppy formater. Normal is prefix of formatter (tolerating two errors) Libre Math: Keywords=Equation;OpenDocument Formula;Formula;odf;MathML;

[gandalf3]

Perhaps the source of this "bug" is really my lack of understanding what the fuzzy option is supposed to do. I thought it would enable partial matches and description matches, but I'm guessing this is incorrect?

[ManuelSchneid3r]

Hmm I have to write an article in the docs on how the fuzzy works. Basically it is the same as the general way to match items (prefix match) but it allows word.length/3 errors, i.e. a search allows "normal".length/3=2 errors.

[gandalf3]

I see, thanks. I guess the reason for "bump" not matching "AwesomeBump" is still unexplained then?

[ManuelSchneid3r]

Bump is not a prefix of AwesomeBump.

I see there is the need to have more tolerant searches. But for extensions like files this will never be realizable because applying a regex on several ten thousands of file strings is way to slow. The current offline indexes allow to search through this amount of items in a few ms. Its a trade off. However this is future work. The applications extension could use another search algorithm, since the input set (installed apps) will never be that big.

[gandalf3]

Ah, I understand now. Thanks for the clarification. Would it be of use to create a proper feature request for special tolerant application search handling?

[ManuelSchneid3r]

You could leave a comment in #163