Bug 431609

Appears to be an issue with https://invent.kde.org/plasma/plasma-workspace/-/commit/9f2abd0a54d51d9234a5a9489d1342b261429fa3, at least this is the last relevant commit.

Does deleting the PlasmaRunnerManager group in ~/.local/share/krunnerstaterc make a difference? (of course do not delete the [History] subgroup and make sure to restart KRunner :))

Yes, that fixes the issue.

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 432339, 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 432339, 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