mirror of
https://github.com/nushell/nushell.git
synced 2025-01-22 14:18:55 +01:00
07a37f9b47
<!-- 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. --> |
||
|---|---|---|
| .. | ||
| nu_plugin_custom_values | ||
| nu_plugin_example | ||
| nu_plugin_formats | ||
| nu_plugin_gstat | ||
| nu_plugin_inc | ||
| nu_plugin_nu_example | ||
| nu_plugin_polars | ||
| nu_plugin_python | ||
| nu_plugin_query | ||
| nu_plugin_stress_internals | ||
| nu-cli | ||
| nu-cmd-base | ||
| nu-cmd-extra | ||
| nu-cmd-lang | ||
| nu-cmd-plugin | ||
| nu-color-config | ||
| nu-command | ||
| nu-derive-value | ||
| nu-engine | ||
| nu-explore | ||
| nu-glob | ||
| nu-json | ||
| nu-lsp | ||
| nu-parser | ||
| nu-path | ||
| nu-plugin | ||
| nu-plugin-core | ||
| nu-plugin-engine | ||
| nu-plugin-protocol | ||
| nu-plugin-test-support | ||
| nu-pretty-hex | ||
| nu-protocol | ||
| nu-std | ||
| nu-system | ||
| nu-table | ||
| nu-term-grid | ||
| nu-test-support | ||
| nu-utils | ||
| nuon | ||
| README.md | ||
Nushell core libraries and plugins
These sub-crates form both the foundation for Nu and a set of plugins which extend Nu with additional functionality.
Foundational libraries are split into two kinds of crates:
- Core crates - those crates that work together to build the Nushell language engine
- Support crates - a set of crates that support the engine with additional features like JSON support, ANSI support, and more.
Plugins are likewise also split into two types:
- Core plugins - plugins that provide part of the default experience of Nu, including access to the system properties, processes, and web-connectivity features.
- Extra plugins - these plugins run a wide range of different capabilities like working with different file types, charting, viewing binary data, and more.