feat: add subsequent & fuzzy search

[Jan-Koll]

Implements an extended and more forgiving search mentioned in #204.

[jrpie]

I think the approach of having multiple lists breaks down at this point. The approach with two list was mainly used to avoid sorting, but I think the code is getting very hard to read now.
I'd suggest calculating a score for each app, remove all where the score is too high, then sort them by score (and secondarily by name).

[Dynge]

Would greatly appreciate this feature.

Any way I can help move it along ?

[jrpie]

Any way I can help move it along ?

Thanks for reaching out (and sorry for the very late reply). Frankly, the main problem is that I'm not very convinced by this feature. In particular, the interaction between this and auto-launch (which I consider a vital feature) is very confusing and hard to explain imho.
Admittedly, this feature only kicks in situations where list of results would be empty otherwise, but how often does one get to that state anyway?
I guess my main problem is that I don't really understand how fuzzy search might be usefull at all. After all, this is not about searching a huge body of text, but only a list of - very short - app labels. For me the current approach works extremely well. But maybe on smaller screens there is a larger problem with typos?

Some thoughts:

1. I've been thinking about adding settings to give users a more granular control of how search works. For example, we could provide a list of decreasingly specific match algorithms, say

• match in beginning
• substring
• subsequence
• <some fuzzy algorithm>

The user could then select an arbitary, non-empty subset of these algorithms.
µLauncher would sort apps primarily by the most specific matching algorithm and secondarily alphabetically (the current behaviour would correspond to {beginning, substring}). This might make it more clear to the user what is going on (?)
However, when enabling the fuzzy algorithm this would make auto-launch useless; I doubt that that is a good trade-off (?)
We could additionally add a setting for "sensitivity of autolaunch" letting the user select one of the above algorithms and trigger auto-launch when the selected algorithm finds a single matching app. This would have the benefit, that one could also set auto-launch sensitivity to the "match in the beginning" algorithm, making auto-launch even faster for users who only use search in this way.
I think this might make it more clear what is going on and give users more control. (Stuff like this should definitely go in an "advanced settings" section)
On the other hand, this adds a lot of complexity and complicated settings. Still, I think I'd prefer it to a single "use fuzzy search" toggle, which enables a rather peculiar behaviour that is explained nowhere.

2. Maybe there is some better way of explaining this feature as is. For example, the setting could be called "use fuzzy search when there are no regular search results". This would make it clear that fuzzy results are only used in one specific situation and could help to understand the interaction with auto-launch (?) This point could be reinfoced further by giving fuzzy results a distinct visual appearance (e.g. grey text color or an italic font).

3. If this is only about typos, I think the feature might as proposed here might not be the best solution.

• users who struggle a lot with typos probably don't use auto-launch at all (?) ~> one could avoid the fuzzy-search-vs-auto-launch problem by making the auto-launch and fuzzy search settings mutually exclusive.
• to help with typos one could use a more sophisticated algorithm for this specific problem, the proposed subsequence and character count algorithms don't seem optimal for that.

[Dynge]

Thanks for the long detailed reply.

I agree with your points and admittedly I have not thought it though as much as you clearly have, thanks for that!

Personally I do not use it because of typos but rather for making searches that are more 'ergonimic' or intuitive (for me). E.g. to match "Ente Photos" when I also have "Ente Auth" installed, it would be easier to write "enp" to match the first part of ente and first part of photos. However with exact matches I have to write the entirety of "ente" or begin in the middle of the name which is not intuitive at all (to me).

I agree that a naive fuzzy match would hinder the effectiveness of auto-launch, but I like your idea of only fuzzy searching when no exact match can be found.

For me the auto-launch makes me explore how I can easily find and open the correct app as easily as possible, fuzzy matching opens the possibilities for more intuitive matches because you have more room to explore.

[jrpie]

Personally I do not use it because of typos but rather for making searches that are more 'ergonimic' or intuitive (for me). E.g. to match "Ente Photos" when I also have "Ente Auth" installed, it would be easier to write "enp" to match the first part of ente and first part of photos.

Have you considered renamig apps for this purpose? (Might look ugly though)

but I like your idea of only fuzzy searching when no exact match can be found.

This is actually what is implemented in this PR (the discussion has some history, see #204 )

[Dynge]

Have you considered renamig apps for this purpose? (Might look ugly though)

Sounds like a manual and tedious approach 😅 Would much rather have fuzzy search to solve it.