Sort important completions and code actions first #657
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
krobelus
changed the title
krobelus
force-pushed
the
custom-completion-sorting
branch
from
619a995
to
467a1cf
Compare
krobelus
added a commit
to krobelus/kakoune
that referenced
this pull request
Dec 22, 2022
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
krobelus
added a commit
to krobelus/kakoune
that referenced
this pull request
Dec 22, 2022
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
krobelus
added a commit
to krobelus/kakoune
that referenced
this pull request
Dec 30, 2022
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
krobelus
added a commit
to krobelus/kakoune
that referenced
this pull request
Mar 5, 2023
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
krobelus
added a commit
to krobelus/kakoune
that referenced
this pull request
Apr 16, 2023
…ript 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
krobelus
added a commit
to krobelus/kakoune
that referenced
this pull request
May 19, 2023
…ript 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
krobelus
force-pushed
the
custom-completion-sorting
branch
from
467a1cf
to
da24729
Compare
7 tasks
This is inspired by a recent change in [Helix] that fixes sorting of
code actions.
We have the same problem; we use ":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 use ":prompt"
to 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.
A proposed Kakoune patch preserves completion input order (if the
query is empty). Use this to fix the order of above code actions.
[Helix]: helix-editor/helix#4134
When typing "someobject." there may be many valid completions. Some servers such as rust-analyzer send the sortText property which prescribes a completion ordering, usually to put commonly-used methods first. Let's use the proposed Kakoune patch to implement this ordering. Note that as soon as the user has typed a few characters, the fuzzy matching score will dominate any difference in ordering.
krobelus
force-pushed
the
custom-completion-sorting
branch
from
da24729
to
ab68ef4
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This depends on a proposed Kakoune patch
mawww/kakoune#4813mawww/kakoune#5035