Created attachment 135322 [details] Bug SUMMARY (Look at the attachment) Searching for `chrom` yields `peek` before `chromium`. This makes the search basically unuseable. I'm wondering why peek even shows up here at all. There is not a single occurrence of the word `chrom` in the peek package (`rg -i chrom $(xbps-query -f peek)`) STEPS TO REPRODUCE 1. Do some searching and observe EXPECTED RESULT Since `chromium` contains a longer subsequence of the search term than `peek`, it should logically also be the first result. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.20.90 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2
:( I am thinking we should maybe remove the relevance magic in KRunner, because at the moment it only causes issues. I made https://phabricator.kde.org/T13989, there are some possibilities discussed. @Nate @Kai what do you think?
Can't reproduce here. Can you upload the desktop file of peek from /usr/share/applications? It doesn't contain any "chrom" here either but also doesn't show up in results.
Created attachment 135323 [details] Desktop File
(In reply to Kai Uwe Broulik from comment #2) > Can't reproduce here. Can you upload the desktop file of peek from > /usr/share/applications? It doesn't contain any "chrom" here either but also > doesn't show up in results. Added it as an attachment! https://bugs.kde.org/attachment.cgi?id=135323
The ~/.config/krunnerrc or ~/.local/share/krunnerstaterc (it it exists) files are also important. There the section [PlasmaRunnerManager] -> LaunchCounts contains the info we need for debugging. Please check if there is privacy relevant information contained before adding it here.
Created attachment 135324 [details] krunnerstaterc (In reply to Alexander Lohnau from comment #5) > The ~/.config/krunnerrc or ~/.local/share/krunnerstaterc (it it exists) > files are also important. There the section [PlasmaRunnerManager] -> > LaunchCounts contains the info we need for debugging. > > Please check if there is privacy relevant information contained before > adding it here. I cross-checked with plasma 5.20.90 on my laptop and the search results were exactly as expected (correct). I compared the configuration files and found that something in ~/.local/share/krunnerstaterc causes the issue. Removing the file results in an unbroken search. What confuses me is, that I did not manually tamper with it before the bug occurred, so I guess some KDE components messed it up.
I feel like this an old issue which gets more noticeable when you use KRunner a lot/longer. >Removing the file results in an unbroken search. Did you post the file after you have removed it to unbreak the search?
(In reply to Alexander Lohnau from comment #7) > I feel like this an old issue which gets more noticeable when you use > KRunner a lot/longer. > > >Removing the file results in an unbroken search. > > Did you post the file after you have removed it to unbreak the search? I posted the broken file (of course).
Can reproduce this issue; the only real fix would be to remove this behavior and discuss alternatives in the Phab task.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/krunner/-/merge_requests/55
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 262837 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 262837 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