Version: unspecified (using KDE 4.5.95) OS: Linux GNOME-Do matches for substring, however KRunner matches for subsequence. (see http://en.wikipedia.org/wiki/Subsequence#Substring_vs._subsequence) I have always found the GNOME-Do approach much more handy. For example, I have "LibreOffice 3.3 Writer", "LibreOffice 3.3 Impress" and "Libreoffice 3.3 Draw" on my Linux. GNOME-Do allows me to type just "lib" then "writer", which leaves "Libreoffice 3.3 Writer" as the only candidate. However on KRunner, to match exactly "Libreoffice 3.3 Writer", I have to type its full name. I know I can use arrow keys to navigate the list of candidates, but that would be much less precise, much less effective and much more awkward. Reproducible: Always Steps to Reproduce: (not relevant) Actual Results: (not relevant) Expected Results: (not relevant) (not relevant)
I would be very happy, too, to see this feature implemented!
Confirmed. This seems like it is simple to implement, specially since we will only be doing it for the applications runner.
It's been a while but I've added a diff for this: https://phabricator.kde.org/D13988
Have requested the diff on phabricator be moved to https://invent.kde.org/plasma/plasma-workspace/-/merge_requests as it was accepted but never merged.
Git commit 9f2abd0a54d51d9234a5a9489d1342b261429fa3 by Nate Graham, on behalf of Michael Eden. Committed on 03/12/2020 at 15:27. Pushed by ngraham into branch 'master'. Use subseq matching for service runner Summary: This changes krunner to use sub-sequence matching fixing bug 262837. Some usage examples are shown below: {F6052081} {F6052084} Depends on D13670 Reviewers: rthomas, #plasma_workspaces, #plasma, broulik, ngraham Reviewed By: ngraham Subscribers: meven, justinzobel, cfeck, ngraham, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D13988 M +5 -5 runners/services/servicerunner.cpp https://invent.kde.org/plasma/plasma-workspace/commit/9f2abd0a54d51d9234a5a9489d1342b261429fa3
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/629
Git commit dc65943e0ad3e393e838b511e4c2925206861a2e by Harald Sitter. Committed on 04/02/2021 at 10:19. Pushed by sitter into branch 'master'. Revert "Use subseq matching for service runner" This reverts commit 9f2abd0a54d51d9234a5a9489d1342b261429fa3. Scores are adjusted by launch count, so pulling more matches into a context increases the chance of one of them outscoring the other even though they have nothing to do with it. Notable example: Flatpaks have extremely long Exec lines meaning they match just about any subsequence match once we've reached 3 query characters. So then a konversation flatpak matches the query 'tel' same as telegram. Now if you are more into IRC than into telegram you may have a higher launch count applying to konversation and all of a sudden the objectively better match for the query is no longer at the top. In lieu of a way to prevent this from happening with krunner 5.78 we'll need to undo the subsequencing for now. For future reference: Kai and I believe Exec and Comment shouldn't be subsequence matched at all because Exec just makes no sense to begin with and Comment can be so very long so it will suffer the same problem as outlined. The more text there is the higher the chance of it matching the subsequence simply having having all the characters appear anywhere. Further future reference: subseq needs a test case added to the unit test if it makes a return! Related: bug 431609, bug 432339 FIXED-IN: 5.21.0 M +5 -5 runners/services/servicerunner.cpp https://invent.kde.org/plasma/plasma-workspace/commit/dc65943e0ad3e393e838b511e4c2925206861a2e
Git commit 2e01a2519692c0d67cc279b65b9d12f42c870ae6 by Harald Sitter. Committed on 04/02/2021 at 10:20. Pushed by sitter into branch 'Plasma/5.21'. Revert "Use subseq matching for service runner" This reverts commit 9f2abd0a54d51d9234a5a9489d1342b261429fa3. Scores are adjusted by launch count, so pulling more matches into a context increases the chance of one of them outscoring the other even though they have nothing to do with it. Notable example: Flatpaks have extremely long Exec lines meaning they match just about any subsequence match once we've reached 3 query characters. So then a konversation flatpak matches the query 'tel' same as telegram. Now if you are more into IRC than into telegram you may have a higher launch count applying to konversation and all of a sudden the objectively better match for the query is no longer at the top. In lieu of a way to prevent this from happening with krunner 5.78 we'll need to undo the subsequencing for now. For future reference: Kai and I believe Exec and Comment shouldn't be subsequence matched at all because Exec just makes no sense to begin with and Comment can be so very long so it will suffer the same problem as outlined. The more text there is the higher the chance of it matching the subsequence simply having having all the characters appear anywhere. Further future reference: subseq needs a test case added to the unit test if it makes a return! Related: bug 431609, bug 432339 FIXED-IN: 5.21.0 (cherry picked from commit dc65943e0ad3e393e838b511e4c2925206861a2e) M +5 -5 runners/services/servicerunner.cpp https://invent.kde.org/plasma/plasma-workspace/commit/2e01a2519692c0d67cc279b65b9d12f42c870ae6
Alas, this caused severe problems with match relevance by exacerbating the problem outlined in https://phabricator.kde.org/T13989 that launch count can outscore any otherwise better match. Specifically any complex enough Exec or Comment line would now match any short query term because of subsequencing. I reckon this cannot actually get fixed before the aforementioned task has been dealt with on the krunner side - something we couldn't do for Plasma 5.21
Yeah probably not. :(