You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Support opt-in priority field in shell script candidates
This is inspired by a recent change in [Helix] that fixes sorting of
code actions.
We have the same problem because kak-lsp uses ":prompt
-shell-script-candidates" to show code actions.
For example, on this Rust file:
fn main() {
let f: FnOnce(HashMap<i32, i32>);
}
with the cursor on "HashMap", a ":lsp-code-actions" will offer two
code actions (from rust-analyzer):
Extract type as type alias"
Import `std::collections::HashMap`
The first one is a refactoring and the second one is a quickfix.
If fuzzy match scores are equal, Kakoune sorts completions
lexicographically, which is suboptimal because the user will almost
always want to run the quickfix first.
Allow users to influence the order via a new "-priority" switch.
When this switch is used, Kakoune expects a second field in
shell-script-candidates completions, like so:
Extract type as type alias"|2
Import `std::collections::HashMap`|1
The priority field is taken into account when computing fuzzy match
scores. Due to the lack of test cases, the math to do so does not
have a solid footing yet. Here's how it works for now.
- "distance" is the fuzzy match score (lower is better)
- "priority" is the new user-specificed ranking, a positive integer (lower is better)
- "query_length" is the length of the string that is used to filter completions
effective_priority = priority ^ (1 / query_length) if query_length != 0 else priority
prioritized_distance = distance * (effective_priority ^ sign(distance))
The ideas are that
1. A priority of 1 is neutral. Higher values increase the distance (making it worse).
2. The longer the query, the lower the impact of "priority".
---
Used by kakoune-lsp/kakoune-lsp#657
[Helix]: helix-editor/helix#4134
Part of mawww#1709
0 commit comments