Add completions.sort option #13311
Merged
Add completions.sort option #13311
Conversation
This file contains hidden or 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
fdncred
reviewed
Jul 6, 2024
|
It looks like LevenshteinDistance is gone, but I could be reading it wrong. I'm ok with that but I'm not sure others will be. |
|
I'd rename "alpha" to "alphabetical". Ať first, I thought it's some coefficient Greek letter alpha. Otherwise I'm fine with it. |
|
@kubouch Done |
fdncred
reviewed
Aug 4, 2024
|
If you can fix the conflicts, and tweak my last request we can probably land this and start using it. |
|
Alright, workflows are green again, shall I merge? |
fdncred
pushed a commit
that referenced
this pull request
Aug 26, 2024
<!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) and talk to the core team before making major changes. Description of your pull request goes here. **Provide examples and/or screenshots** if your changes affect the user experience. --> This issue was reported by kira in [Discord](https://discord.com/channels/601130461678272522/1276981416307069019). In #13311, I accidentally made it so that custom completions are filtered according to the user's configured completion options (`$env.config.completions`) rather than the completion options provided as part of the custom completions. This PR is a quick fix for that. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> It should once again be possible to override match algorithm, case sensitivity, and substring matching (`positional`) in custom completions. # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> Added a couple tests. # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. --> fdncred and I discussed this in Discord a bit and we thought it might be better to not allow custom completions to override the user's config. However, `positional` can't currently be set inside one's config, so you can only do strict prefix matching, no substring matching. Another PR could do one of the following: - Document the fact that you can provide completion options inside custom completions - Remove the ability to provide completion options with custom completions and add a `$env.config.completions.positional: true` option - Remove the ability to provide completion options with custom completions and add a new match algorithm `substring` (this is the one I like most, since `positional` only applies to prefix matching anyway) Separately from these options, we could also allow completers to specify that they don't Nushell to do any filtering and sorting on the provided custom completions.
ysthakur
added a commit
that referenced
this pull request
Nov 30, 2024
<!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description This PR makes it so that when a custom completer sets `options.sort` to true, completions aren't sorted. Previously, in #13311, I'd made it so that setting `sort` to true would sort in alphabetical order, while omitting it or setting it to false would sort it in the default order for the chosen match algorithm (alphabetical for prefix matching, fuzzy match score for fuzzy matching). I'd assumed that you'd always want to sort completions and the important thing was choosing alphabetical sorting vs the default sort order for your match algorithm. However, this assumption was incorrect (see #13696 and [this thread](https://discord.com/channels/601130461678272522/1302332259227144294) in Discord). An alternative would be to make `sort` accept `"alphabetical"`, `"smart"`, and `"none"`/`null` rather than keeping it a boolean. But that would be a breaking change and require more discussion, and I wanted to keep this PR simple/small so that we can go back to the sensible behavior as soon as possible. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> Here are the different scenarios: - If your custom completer returns a record with an `options` field that's a record: - If `options` contains `sort: true`, completions **will be sorted according to the order set in the user's config**. Previously, they would have been sorted in alphabetical order. This does mean that **custom completers cannot explicitly choose to sort in alphabetical order** anymore. I think that's an acceptable trade-off, though. - If `options` contains `sort: false`, completions will not be sorted. #13311 broke things so they would be sorted in the default order for the match algorithm used. Before that PR, completions would not have been sorted. - If there's no `sort` option, that **will be treated as `sort: true`**. Previously, this would have been treated as `sort: false`. - Otherwise, nothing changes. Completions will still be sorted. # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> Added 1 test to make sure that completions aren't sorted with `sort: false` explicitly set. # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. -->
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.
Description
More or less closes #13295, although I didn't mess with the help completer. This PR gets rid of the
SortByenum so that individual completers can no longer choose how they want to sort completions. Instead, a newsortfield is added toCompletionOptions(configurable through$env.config.completions.sort). If set to"default"(the default), completions will be sorted based on match algorithm (alphabetical order for prefix matching, fuzzy matcher score for fuzzy matching). If set to"alphabetical", completions will be sorted in alphabetical order.This is my first time adding a new config option, so let me know if I've missed anything.
User-Facing Changes
There's a new
$env.config.completions.sortoption to control sort order. Users will now see all their completions sorted either in alphabetical order or based on the fuzzy matcher score, based on their chosen match algorithm. Previously, some completers would've sorted in alphabetical order and some by levenshtein distance.Now, levenshtein distance isn't used at all. Note that the fuzzy matcher score will not provide the exact same results as levenshtein distance. I personally think the fuzzy matcher score is a better metric than levenshtein distance (it's easier for me to get the completions I want), but if anyone likes levenshtein distance, we can figure out a way to keep that too.
Additionally, with custom completions, if a provided completion has
sort: true, then the suggestions provided with it will be sorted in alphabetical order. Otherwise, they'll be sorted based on the user's chosen match algorithm. It would probably have made more sense to usesort: "alphabetical"/"default"here too, but I didn't want to completely break anything. Let me know what behavior would make more sense here.Tests + Formatting
algorithm = "fuzzy"withsort = "alpha".overlay. Previously, it completeddef(fromde), but now,debugand its subcommands are provided as completions beforedef, because they come before it in alphabetical order, even if previously, their levenshtein distance todewas greater.After Submitting
This PR recomputes fuzzy matcher scores when suggestions are to be sorted (they're already computed once when filtering the list of suggestions). It's possible to compute those scores only once, but that requires more extensive changes. I've got a PR for that lined up; I can open it if this is merged.