Bug 510039

Summary: fuzzy matching in application search gives nonsensical results for short queries
Product: [Plasma] plasmashell Reporter: Nicolas Fella <nicolas.fella>
Component: Application Launcher (Kickoff) widgetAssignee: Plasma Bugs List <plasma-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: 4wy78uwh, mikel5764, nate, nicolas, noahadvs, postix
Priority: NOR Keywords: regression
Version First Reported In: 6.4.80   
Target Milestone: 1.0   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In: 6.5.0
Sentry Crash Report:
Attachments: Screenshot
teams vs steam

Description Nicolas Fella 2025-09-29 08:06:30 UTC
Created attachment 185354 [details]
Screenshot

Since the introduction of fuzzy matching in the application search the results have become very poor and unpredictable, particularly with short search terms.

For example:

"ru" gives "Systemmonitor" as first result instead of something sensible like "Ruqola"
"do" gives "Oracle Virtualbox" instead of something sensible like "Dolphin"
"e" gives "Kate" instead of something sensible like "Element"
Comment 1 Bug Janitor Service 2025-09-29 08:22:45 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5871
Comment 2 postix 2025-09-29 12:37:18 UTC
What about a combination of both: Use the old algorithm for short terms and fuzzy for longer?
Comment 3 Bug Janitor Service 2025-10-01 10:10:44 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5880
Comment 4 Bug Janitor Service 2025-10-08 11:56:43 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5903
Comment 5 Nicolas 2025-10-09 07:54:26 UTC
I'm not sure if related, but searching for "team" or "teams" seems to always prefer "Steam" over "Microsoft Teams", which is unintuitive, I expected to always prefer the latter as one of the words in the results starts with the query
Comment 6 Marco Martin 2025-10-14 12:37:19 UTC
Git commit e6c7d9f870ab4be0f08e6a65ffde7954543f7bd1 by Marco Martin.
Committed on 14/10/2025 at 12:37.
Pushed by mart into branch 'master'.

servicerunner: calculate the distance of the "beginning" of the items too

bitap worked in a way that strongly favored matches trough the end of the word, rather than treating them the same
When matching the various entries, change how bitap works, and now end instead of the end of the word where it maches, calculate the end of the pattern when we have a match, this giving equal tretment where the match is

M  +22   -17   runners/services/autotests/bitaptest.cpp
A  +14   -0    runners/services/autotests/fixtures/Set Resolution 2560x1440.desktop
A  +14   -0    runners/services/autotests/fixtures/Set Resolution 3440x1440.desktop
A  +17   -0    runners/services/autotests/fixtures/org.kde.dolphin.desktop
A  +18   -0    runners/services/autotests/fixtures/org.kde.rkward.desktop
M  +26   -0    runners/services/autotests/servicerunnertest.cpp
M  +12   -11   runners/services/bitap.h
M  +1    -1    runners/services/servicerunner.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/e6c7d9f870ab4be0f08e6a65ffde7954543f7bd1
Comment 7 Marco Martin 2025-10-14 12:38:05 UTC
Git commit 52c9cb6b161b1e7d5c0e85e6ca301a05da2fcc10 by Marco Martin.
Committed on 14/10/2025 at 12:37.
Pushed by mart into branch 'Plasma/6.5'.

servicerunner: calculate the distance of the "beginning" of the items too

bitap worked in a way that strongly favored matches trough the end of the word, rather than treating them the same
When matching the various entries, change how bitap works, and now end instead of the end of the word where it maches, calculate the end of the pattern when we have a match, this giving equal tretment where the match is


(cherry picked from commit e6c7d9f870ab4be0f08e6a65ffde7954543f7bd1)

67698e95 servicerunner: calculate the distance of the "beginning" of the items too
1d09283b different approach: change how bitap woorks
7b3228fe bitap.end becomes bitap.size

Co-authored-by: Marco Martin <notmart@gmail.com>

M  +22   -17   runners/services/autotests/bitaptest.cpp
A  +14   -0    runners/services/autotests/fixtures/Set Resolution 2560x1440.desktop
A  +14   -0    runners/services/autotests/fixtures/Set Resolution 3440x1440.desktop
A  +17   -0    runners/services/autotests/fixtures/org.kde.dolphin.desktop
A  +18   -0    runners/services/autotests/fixtures/org.kde.rkward.desktop
M  +26   -0    runners/services/autotests/servicerunnertest.cpp
M  +12   -11   runners/services/bitap.h
M  +1    -1    runners/services/servicerunner.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/52c9cb6b161b1e7d5c0e85e6ca301a05da2fcc10
Comment 8 Harald Sitter 2025-10-19 13:38:02 UTC
Git commit 25ca340b81984c7ab262714357a18a98637cf9b3 by Harald Sitter.
Committed on 19/10/2025 at 13:37.
Pushed by sitter into branch 'Plasma/6.5'.

servicerunner: outscore krunner's launch count system

(only applies to 6.5)

6.5 may be used against a krunner that has a constextless launch count
system where an entry that was used a lot gets a bump, that is however
problematic because of the lack of context. just because rkward was used
a lot on the search 'rk' it doesn't mean it's the preferred choice on
'ward'

M  +6    -1    runners/services/servicerunner.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/25ca340b81984c7ab262714357a18a98637cf9b3
Comment 9 Nicolas 2025-10-29 10:13:35 UTC
Created attachment 186283 [details]
teams vs steam

I still think this issue is not resolved completely, the search prefers "steam" when typing "teams"
Comment 10 Nate Graham 2025-10-29 17:03:06 UTC
That would be Bug 511235; let's track it there.