| Summary: | Substring matches for keyword anchored at the beginning of the string are outscored by inexact fuzzy matches | ||
|---|---|---|---|
| Product: | [Plasma] krunner | Reporter: | Connor Chang <connorc0627> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alexander.lohnau, casta+kde, connorc0627, natalie_clarius, nate, sitter |
| Priority: | HI | Keywords: | regression, usability |
| Version First Reported In: | 6.5.3 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| See Also: |
https://bugs.kde.org/show_bug.cgi?id=511078 https://bugs.kde.org/show_bug.cgi?id=512400 |
||
| Latest Commit: | https://invent.kde.org/plasma/plasma-workspace/-/commit/e3ae34e298820572e0bb37ac796483b31d5380a5 | Version Fixed/Implemented In: | 6.5.5 |
| Sentry Crash Report: | |||
|
Description
Connor Chang
2025-11-20 18:03:24 UTC
vsc is too far away from vscode so it gets disqualified. changing this mans we'd include many more keyword matches Can we increase the priority of matches anchored to the beginning of the keyword, though? These wouldn't have to be prioritized as high as matches anchored to the beginning of the name, comment, or genericName. But they should be prioritized higher than matches *not* anchored to the beginning of any of those. Sure, but then we first have to make them matches which means they will cause extra results to show up. Case in point I've implemented exactly that meanwhile and it makes emoji explorer show up when searching for 'code' Ah, because it contains "unicode" in the keywords. But in that case it should be super de-prioritized compared to anything with "code" as an exact keyword match or substring-anchored-to-the-beginning keyword match, right? M maybe we can even make keywords match *only* if they're exact matches or substrings anchored to the beginning. No middle-of-keyword matching or fuzzy matching. Like, if I type "ynicode" and Emoji Picker comes up, that doesn't make much sense IMO. The problem with keywords is always that they make no sense because they have no basis in anything the user sees. So, yeah, I guess not letting them fuzzy may be a solution. A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6106 Git commit 99e129cd1ed5bbc84e6d0a7dbc01d0c22f5d5e1a by Harald Sitter. Committed on 19/12/2025 at 16:37. Pushed by sitter into branch 'master'. servicerunner: still consider keywords even when they are poor matches so long as they are either a perfect (albeit possibly substring) match and start with the search term M +14 -0 runners/services/autotests/servicerunnertest.cpp M +1 -1 runners/services/servicerunner.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/99e129cd1ed5bbc84e6d0a7dbc01d0c22f5d5e1a Git commit e3ae34e298820572e0bb37ac796483b31d5380a5 by Harald Sitter. Committed on 19/12/2025 at 16:50. Pushed by sitter into branch 'Plasma/6.5'. servicerunner: still consider keywords even when they are poor matches so long as they are either a perfect (albeit possibly substring) match and start with the search term (cherry picked from commit 99e129cd1ed5bbc84e6d0a7dbc01d0c22f5d5e1a) M +14 -0 runners/services/autotests/servicerunnertest.cpp M +1 -1 runners/services/servicerunner.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/e3ae34e298820572e0bb37ac796483b31d5380a5 |