# Description
Adds `random choice` suggested in #16241.
# User-Facing Changes
New `random` module in `std-rfc` with the `choice` subcommand.
# Tests + Formatting
Unsure how do to do tests. Sampling and a histogram should be enough,
but they'll be non-deterministic.
# 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.
-->
---------
Co-authored-by: sholderbach <sholderbach@users.noreply.github.com>
# Description
Changes the behavior of `--ignore-case` and `--multiline` options for
`find`, to make them more consistent between regex mode and search term
mode, and to enable more options for using find.
# User-Facing Changes
Search term mode is now case-sensitive by default.
`--ignore-case` will make the search case-insensitive in search term
mode. In regex mode, the previous behavior of adding a (?i) flag to the
regex is preserved.
`--multiline` will no longer add a (?m) flag in regex mode. Instead, it
will make the search not split multi-line strings into lists of lines.
closes#16317closes#16022
# Description
`explore` was reading the byte length for computing:
- `:` command input cursor positions
- `/`/`?` search mode cursor positions
- `:try` input box cursor positions
- search highlighting
Fixed this for the majority of cases by using `unicode_width`, this is
only best effort as terminals don't need to follow those expectations
but for the most cases (traditional language scripts etc.) this should
lead to better result. The only way around the uncertainty would be to
perform the highlighting/cursor marking as we go, but this may not be as
compatible with the `ratatui` framework.
Closes#16312
# User-Facing Changes
Fixed cursor position and search highlighting for non-ASCII characters,
with the caveat mentioned above.
# Tests + Formatting
Manually tested
# Description
Allows custom bindings (non-chord) to send a `edit_mode: vi` mode change
via the new `ReedlineEvent::ViChangeMode`
Takes https://github.com/nushell/reedline/pull/932
# User-Facing Changes
You can now set bindings which change the Vi mode. (This still has the
same rules for defining the key-combination: Only modifiers and single
keys are supported)
To do so send a `vichangemode` event with the `mode` field to set
`normal`, `insert`, or `visual`
```nushell
$env.config.keybindings ++=
[{
name: modechangetest
modifier: control
keycode: "char_["
mode: [vi_normal, vi_insert]
event: {send: vichangemode, mode: normal}
}]
```
# Description
Adds an example that documents how to use `input --reedline` to collect
multiple lines of input from the user
I also removed an extraneous and inconsistent space in the following
example.
# User-Facing Changes
Documentation addition
# Tests + Formatting
I did not run any tests or autoformatters because of the docs-only
nature of the change, and the fact that I copy-pasted the format from an
existing example. If the autoformatter is unhappy, I apologize.
# After Submitting
This PR should automatically update the docs site at the next release,
so no need to do anything there.
---------
Co-authored-by: Stefan Holderbach <sholderbach@users.noreply.github.com>
# Description
As title, this pr introduce `-h` flag to testbin, so if I want to see
which testbin I should use, I don't need to look into source code.
### About the change
I don't know if there is any way to get docstring of a function inside
rust code. So I created a trait, and put docstring into it's `help`
method:
```rust
pub trait TestBin {
// the docstring of original functions are moved here.
fn help(&self) -> &'static str;
fn run(&self);
}
```
Take `cococo` testbin as example, the changes are:
```
original cococo function --> Cococo struct, then
1. put the body of `cococo` function into `run` method
2. put the docstring of `cococo` function into `help` method
```
# User-Facing Changes
`-h/--help` flag in testbin is enabled.
```
> nu --testbin -h
Usage: nu --testbin <bin>
<bin>:
chop -> With no parameters, will chop a character off the end of each line
cococo -> Cross platform echo using println!()(e.g: nu --testbin cococo a b c)
echo_env -> Echo's value of env keys from args(e.g: nu --testbin echo_env FOO BAR)
echo_env_mixed -> Mix echo of env keys from input(e.g: nu --testbin echo_env_mixed out-err FOO BAR; nu --testbin echo_env_mixed err-out FOO BAR)
echo_env_stderr -> Echo's value of env keys from args to stderr(e.g: nu --testbin echo_env_stderr FOO BAR)
echo_env_stderr_fail -> Echo's value of env keys from args to stderr, and exit with failure(e.g: nu --testbin echo_env_stderr_fail FOO BAR)
fail -> Exits with failure code 1(e.g: nu --testbin fail)
iecho -> Another type of echo that outputs a parameter per line, looping infinitely(e.g: nu --testbin iecho 3)
input_bytes_length -> Prints the number of bytes received on stdin(e.g: 0x[deadbeef] | nu --testbin input_bytes_length)
meow -> Cross platform cat (open a file, print the contents) using read_to_string and println!()(e.g: nu --testbin meow file.txt)
meowb -> Cross platform cat (open a file, print the contents) using read() and write_all() / binary(e.g: nu --testbin meowb sample.db)
nonu -> Cross platform echo but concats arguments without space and NO newline(e.g: nu --testbin nonu a b c)
nu_repl -> Run a REPL with the given source lines
relay -> Relays anything received on stdin to stdout(e.g: 0x[beef] | nu --testbin relay)
repeat_bytes -> A version of repeater that can output binary data, even null bytes(e.g: nu --testbin repeat_bytes 003d9fbf 10)
repeater -> Repeat a string or char N times(e.g: nu --testbin repeater a 5)
```
# Tests + Formatting
None, all existed tests can guarantee the behavior of testbins doesn't
change.
# After Submitting
NaN
# Description
Fixes#15485
This PR changes pipeline checking to keep track of all possible output
types instead of only first type matching input type which appears in
the input/output types. For example, in this command:
```nushell
def foo []: [int -> string, int -> record] {
# ...
}
```
An `int` input to the command may result in a string or a record to be
output. Before this PR, Nushell would always assume that an `int` input
would cause a `string` output because it's the first matching
input/output type pair. This would cause issues during type checking
where the parser would incorrectly determine the output type. After this
PR, Nushell considers the command to output either a string or a record.
# User-Facing Changes
* Parse-time pipeline type checking now properly supports commands with
multiple pipeline output types for the same pipeline input type
# Tests + Formatting
Added a couple tests
# After Submitting
N/A
---------
Co-authored-by: Bahex <Bahex@users.noreply.github.com>
# Description
As title: this pr is try to introduce 2 functions to `PipelineData`:
1. PipelineData::list_stream --> create a PipelineData::ListStream
2. PipelineData::byte_stream -> create a PipelineData::ByteStream
And use these functions everywhere.
### Reason behind this change
I tried to implement `pipefail` feature, but this would required to
change `PipelineData` from enum to struct. So use these functions can
reduce diff if I finally change to struct. [Discord message
here](https://discord.com/channels/601130461678272522/615962413203718156/1396999539000479784)
is my plan.
# User-Facing Changes
NaN
# Tests + Formatting
NaN
# After Submitting
NaN
- fixes#16200
# Description
| | Select | Fuzzy |
| -- | ---------------- | --------------- |
| ❌ | ![select-before] | ![fuzzy-before] |
| ✅ | ![select-fixed] | ![fuzzy-fixed] |
[select-before]:
8fe9136472/select-before.svg
[select-fixed]:
8fe9136472/select-after.svg
[fuzzy-before]:
8fe9136472/fuzzy-before.svg
[fuzzy-fixed]:
8fe9136472/fuzzy-after.svg
Using a custom `dialoguer::theme::Theme` implementation, how `input
list` renders items are overridden.
Unfortunately, implementing one of the methods requires
`fuzzy_matcher::skim::SkimMatcherV2` which `dialoguer` does not export
by itself.
Had to add an explicit dependency to `fuzzy_matcher`, which we already
depend on through `dialoguer`. Version specification is copied from
`dialoguer`.
# Tests + Formatting
No tests added.
Couldn't find existing tests, not sure how to test this.
---------
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
Fix commit ID hex formatting in gstat, closes#16307
Leading zeros are preserved, maintaining the correct hex representation
This issue is relatively easy to fix, but it's not very easy to verify.
However, I have already tested several scenarios, it works for commit
sha like `000baeef`, `000003c7` and `00000002` etc.
Fixes#16185
# Description
Stepped range literals where `..=` precedes the second value no longer
cause a parser panic:
```diff
random int 1..=3..5
-Error: x Main thread panicked.
- |-> at crates/nu-protocol/src/engine/state_working_set.rs:400:48
- `-> slice index starts at 8 but ends at 7
+Error: nu::parser::parse_mismatch
+
+ × Parse mismatch during operation.
+ ╭─[entry #1:1:15]
+ 1 │ random int 1..=3..5
+ · ─┬
+ · ╰── expected number
```
Currently we run this locally on whatever machine the person doing it is
using. With this we have all three major platforms covered and don't
block a personal machine before the release. Also any failures are
visible to everyone if we need to fix something.
<!--
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.
-->
As a bonus to #16174, I realized it would be trivial to add a similar
check to where.
Before:
```nushell
1..100 | where 1
# => no output...
```
After:
```nushell
1..100 | where 1
# => Error: nu::parser::type_mismatch
# =>
# => × Type mismatch.
# => ╭─[entry #3:1:16]
# => 1 │ 1..100 | where 1
# => · ┬
# => · ╰── expected bool, found int
# => ╰────
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
* `where` should now error on row condition expressions which are not
booleans
# 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 test
# 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.
-->
N/A
Restricts custom completion from universal to internal arguments only.
Pros:
1. Less memory
2. More flexible for later customizations, e.g. #14923
Cons:
1. limited customization capabilities, but at least covers all currently
existing features in nushell.
# Description
Mostly vibe coded by [Zed AI](https://zed.dev/ai) with a single prompt.
LGTM, but I'm not so sure @ysthakur
# User-Facing Changes
Hopefully none.
# Tests + Formatting
+3
# After Submitting
---------
Co-authored-by: Yash Thakur <45539777+ysthakur@users.noreply.github.com>
- fixes#16129
# Description
## Problem
Parsing a multi span value as RowCondition always produces a RowCondition
expression that covers all the spans.
Which is problematic inside OneOf and can produce multiple expressions with
overlapping spans.
Which results in funky highlighting that duplicates text.
## Solution
Only reason for including `SyntaxShape::Closure` in the signature (#15697) was
for documentation purposes, making it clear in `help` texts that a closure can
be used as the argument.
As our current parser is shape directed, simplifying the command signature
means simplifies the parsing, so using a RowCondition on its own, and instead
making it always look like a union with `closure(any)` solves the issue without
any changes in the parser.
Also, RowCondition always accepts closure values anyway, so its textual
representation should indicate that without the need to wrap it in OneOf.
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
This code didn't compile, fixed provisionally by always running the
codepath with tilde expansion.
@IanManske worth discussing what we may want to fuzz here.
This pull request fixes a typo in the description of a `glob` example:
**Before:**
```
Search for files for folders that do not begin with c, C, b, M, or s
> glob "[!cCbMs]*"
```
**After:**
```
Search for files or folders that do not begin with c, C, b, M, or s
> glob "[!cCbMs]*"
```
cc: @blindFS @ysthakur
# Description
Enable `nucleo`'s `prefer_prefix` configuration option.
Ranks suggestions with matches closer to the start higher than
suggestions that have matches further from the start.
Example: suggestions based on `reverse`:
<table>
<tr>
<td width=200>Before</td>
<td width=200>After</td>
</tr>
<tr>
<td>
```
bytes reverse
polars reverse
reverse
str reverse
```
</td>
<td>
```
reverse
str reverse
polars reverse
bytes reverse
```
</td>
</tr>
</table>
# User-Facing Changes
More relevant suggestions with fuzzy matching algorithm.
(`$env.config.completions.algorithm = "fuzzy"`)
# Tests + Formatting
We might want to add tests to make sure this option keeps working in the
future.
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
# Description
Fixes#15308. Surprisingly, I can't find any more issues that bring this
up.
This PR adds a check for interrupt before evaluating each IR
instruction. This makes it possible to ctrl-c out of things that were
difficult/impossible previously, like:
```nushell
loop {}
```
@devyn also [mentioned
previously](https://discord.com/channels/601130461678272522/615329862395101194/1268674828492083327)
that this might be a feasible option, but mentioned some performance
concerns.
I did some benchmarking previously but it turns out tango isn't the
greatest for this. I don't have hard numbers anymore but based on some
experimenting I shared in the Discord it seems like no experimental
option and limiting this to specific instructions should keep the
performance impact minimal.
<details>
<summary>Old benchmarking info</summary>
I did some benchmarks against main. It seems like most benchmarks are
between 1-6% slower, with some oddball exceptions.
The worst case seems to a giant loop, which makes sense since it's
mostly just jumping back to the beginning, meaning we hit the check over
and over again.
With `bench --pretty -n 100 { for i in 0..1000000 { 1 } }`, it seems
like the `ir-interrupt` branch is ~10% slower for this stress case:
```
main: 94ms 323µs 29ns +/- 1ms 291µs 759ns
ir-interrupt: 103ms 54µs 708ns +/- 1ms 606µs 571ns
(103ms + 54µs + 708ns) / (94ms + 323µs + 29ns) = 1.0925720801438639
```
The performance numbers here aren't great, but they're not terrible
either, and I think the usability improvement is probably worth it here.
<details>
<summary>Tango benchmarks</summary>
```
load_standard_lib [ 2.8 ms ... 2.9 ms ] +3.53%*
record_create_1 [ 101.8 us ... 107.0 us ] +5.12%*
record_create_10 [ 132.3 us ... 135.6 us ] +2.48%*
record_create_100 [ 349.7 us ... 354.6 us ] +1.39%*
record_create_1000 [ 3.7 ms ... 3.6 ms ] -1.30%
record_flat_access_1 [ 94.8 us ... 99.9 us ] +5.35%*
record_flat_access_10 [ 96.2 us ... 101.3 us ] +5.33%*
record_flat_access_100 [ 106.0 us ... 111.4 us ] +5.07%*
record_flat_access_1000 [ 203.0 us ... 208.5 us ] +2.69%
record_nested_access_1 [ 95.3 us ... 100.1 us ] +5.03%*
record_nested_access_2 [ 98.4 us ... 104.6 us ] +6.26%*
record_nested_access_4 [ 100.8 us ... 105.4 us ] +4.56%*
record_nested_access_8 [ 104.7 us ... 108.1 us ] +3.23%
record_nested_access_16 [ 110.6 us ... 115.8 us ] +4.71%*
record_nested_access_32 [ 119.0 us ... 124.0 us ] +4.20%*
record_nested_access_64 [ 137.4 us ... 142.2 us ] +3.47%*
record_nested_access_128 [ 176.7 us ... 181.8 us ] +2.87%*
record_insert_1_1 [ 106.2 us ... 111.9 us ] +5.35%*
record_insert_10_1 [ 111.2 us ... 116.0 us ] +4.28%*
record_insert_100_1 [ 134.3 us ... 139.8 us ] +4.06%*
record_insert_1000_1 [ 387.8 us ... 417.1 us ] +7.55%
record_insert_1_10 [ 162.9 us ... 171.5 us ] +5.23%*
record_insert_10_10 [ 159.5 us ... 166.2 us ] +4.23%*
record_insert_100_10 [ 183.3 us ... 190.7 us ] +4.04%*
record_insert_1000_10 [ 411.7 us ... 418.7 us ] +1.71%*
table_create_1 [ 117.2 us ... 120.3 us ] +2.66%
table_create_10 [ 144.9 us ... 152.2 us ] +5.02%*
table_create_100 [ 476.0 us ... 484.8 us ] +1.86%*
table_create_1000 [ 3.7 ms ... 3.7 ms ] +1.55%
table_get_1 [ 121.6 us ... 127.0 us ] +4.40%*
table_get_10 [ 112.1 us ... 117.4 us ] +4.71%*
table_get_100 [ 124.0 us ... 129.5 us ] +4.41%*
table_get_1000 [ 229.9 us ... 245.5 us ] +6.75%*
table_select_1 [ 111.1 us ... 115.6 us ] +4.03%*
table_select_10 [ 112.1 us ... 118.4 us ] +5.65%*
table_select_100 [ 142.2 us ... 147.2 us ] +3.53%*
table_select_1000 [ 383.5 us ... 370.3 us ] -3.43%*
table_insert_row_1_1 [ 122.5 us ... 127.8 us ] +4.35%*
table_insert_row_10_1 [ 123.6 us ... 128.6 us ] +3.99%*
table_insert_row_100_1 [ 124.9 us ... 131.2 us ] +5.05%*
table_insert_row_1000_1 [ 177.3 us ... 182.7 us ] +3.07%*
table_insert_row_1_10 [ 225.7 us ... 234.5 us ] +3.90%*
table_insert_row_10_10 [ 229.2 us ... 235.4 us ] +2.69%*
table_insert_row_100_10 [ 253.3 us ... 257.6 us ] +1.69%
table_insert_row_1000_10 [ 311.1 us ... 318.3 us ] +2.32%*
table_insert_col_1_1 [ 107.6 us ... 113.3 us ] +5.35%*
table_insert_col_10_1 [ 109.6 us ... 115.3 us ] +5.27%*
table_insert_col_100_1 [ 155.5 us ... 159.8 us ] +2.71%*
table_insert_col_1000_1 [ 476.6 us ... 480.8 us ] +0.88%*
table_insert_col_1_10 [ 167.7 us ... 177.4 us ] +5.75%
table_insert_col_10_10 [ 178.5 us ... 194.8 us ] +9.16%*
table_insert_col_100_10 [ 314.4 us ... 322.3 us ] +2.53%*
table_insert_col_1000_10 [ 1.7 ms ... 1.7 ms ] +1.35%*
eval_interleave_100 [ 485.8 us ... 506.5 us ] +4.27%
eval_interleave_1000 [ 3.3 ms ... 3.2 ms ] -1.51%
eval_interleave_10000 [ 31.5 ms ... 31.0 ms ] -1.80%
eval_interleave_with_interrupt_100 [ 473.2 us ... 479.6 us ] +1.35%
eval_interleave_with_interrupt_1000 [ 3.2 ms ... 3.2 ms ] -1.26%
eval_interleave_with_interrupt_10000 [ 32.3 ms ... 31.1 ms ] -3.81%
eval_for_1 [ 124.4 us ... 130.1 us ] +4.60%*
eval_for_10 [ 124.4 us ... 130.3 us ] +4.80%*
eval_for_100 [ 134.5 us ... 141.5 us ] +5.18%*
eval_for_1000 [ 222.7 us ... 244.0 us ] +9.59%*
eval_for_10000 [ 1.0 ms ... 1.2 ms ] +13.86%*
eval_each_1 [ 146.9 us ... 153.0 us ] +4.15%*
eval_each_10 [ 152.3 us ... 158.8 us ] +4.26%*
eval_each_100 [ 169.3 us ... 175.6 us ] +3.76%*
eval_each_1000 [ 346.8 us ... 357.4 us ] +3.06%*
eval_each_10000 [ 2.1 ms ... 2.2 ms ] +2.37%*
eval_par_each_1 [ 194.3 us ... 203.5 us ] +4.73%*
eval_par_each_10 [ 186.4 us ... 193.1 us ] +3.59%*
eval_par_each_100 [ 213.5 us ... 222.2 us ] +4.08%*
eval_par_each_1000 [ 433.4 us ... 437.4 us ] +0.93%
eval_par_each_10000 [ 2.4 ms ... 2.4 ms ] -0.40%
eval_default_config [ 406.3 us ... 414.9 us ] +2.12%*
eval_default_env [ 475.7 us ... 495.1 us ] +4.08%*
encode_json_100_5 [ 132.7 us ... 128.9 us ] -2.88%*
encode_json_10000_15 [ 35.5 ms ... 34.0 ms ] -4.15%*
encode_msgpack_100_5 [ 85.0 us ... 83.9 us ] -1.20%*
encode_msgpack_10000_15 [ 22.2 ms ... 21.7 ms ] -2.17%*
decode_json_100_5 [ 431.3 us ... 421.0 us ] -2.40%*
decode_json_10000_15 [ 119.7 ms ... 117.6 ms ] -1.76%*
decode_msgpack_100_5 [ 160.6 us ... 151.1 us ] -5.90%*
decode_msgpack_10000_15 [ 44.0 ms ... 43.1 ms ] -2.12%*
```
</details>
</details>
# User-Facing Changes
* It should be possible to ctrl-c in situations where it was not
previously possible
# Tests + Formatting
N/A
# After Submitting
N/A
# Description
Type-check all closure arguments, not just required arguments.
Not doing so looks like an oversight.
# User-Facing Changes
Previously, passing an argument of the wrong type to a closure would
fail if the argument is required, but be accepted (ignoring the type
annotation) if the argument is optional:
```
> do {|x: string| $x} 4
Error: nu:🐚:cant_convert
× Can't convert to string.
╭─[entry #13:1:21]
1 │ do {|x: string| $x} 4
· ┬
· ╰── can't convert int to string
╰────
> do {|x?: string| $x} 4
4
> do {|x?: string| $x} 4 | describe
int
```
It now fails the same way in both cases.
# Tests + Formatting
Added tests, the existing tests still pass.
Please let me know if I added the wrong type of test or added them in
the wrong place (I didn't spot similar tests in the nu-cmd-lang crate,
so I put them next to the most-related existing tests I could find...
# After Submitting
I think this is minor enough it doesn't need a doc update, but please
point me in the right direction if not.
# Description
This script as example for demonstration
```nushell
def miku [] { print "Hiii world! 初音ミクはみんなのことが大好きだよ！" }
def main [leek: int, fn: closure] {
print $"Miku has ($leek) leeks 🩵"
do $fn
}
```
---
`escape_for_string_arg` quoting strings misses, where `|` and `;` did
split the command into 2+ commands
```console
~:► nu ./miku.nu '32' '{miku}'
Miku has 32 leeks 🩵
Hiii world! 初音ミクはみんなのことが大好きだよ！
~:► nu ./miku.nu '32' '{miku};ls|' where type == dir
Miku has 32 leeks 🩵
Hiii world! 初音ミクはみんなのことが大好きだよ！
╭────┬─────────────┬──────┬────────┬──────────────╮
│ # │ name │ type │ size │ modified │
├────┼─────────────┼──────┼────────┼──────────────┤
│ 0 │ Desktop │ dir │ 4.0 kB │ 5 months ago │
│ 1 │ Documents │ dir │ 4.0 kB │ a day ago │
│ 2 │ Downloads │ dir │ 4.0 kB │ a day ago │
│ 3 │ Music │ dir │ 4.0 kB │ 9 months ago │
│ 4 │ Pictures │ dir │ 4.0 kB │ 3 weeks ago │
│ 5 │ Public │ dir │ 4.0 kB │ 9 months ago │
│ 6 │ Templates │ dir │ 4.0 kB │ 3 months ago │
│ 7 │ Videos │ dir │ 4.0 kB │ 9 months ago │
│ 8 │ __pycache__ │ dir │ 4.0 kB │ 3 weeks ago │
│ 9 │ bin │ dir │ 4.0 kB │ 3 days ago │
│ 10 │ repos │ dir │ 4.0 kB │ a day ago │
│ 11 │ trash │ dir │ 4.0 kB │ 3 days ago │
╰────┴─────────────┴──────┴────────┴──────────────╯
```
# User-Facing Changes
This adjustment won't need a change, aside from clarifying the following
behavior, which is unintuitive and potentially ambiguous
```console
~:► nu ./miku.nu '32' {miku}
Miku has 32 leeks 🩵
Hiii world! 初音ミクはみんなのことが大好きだよ！
~:► nu ./miku.nu '32' { miku }
Error: nu::parser::parse_mismatch
× Parse mismatch during operation.
╭─[<commandline>:1:9]
1 │ main 32 "{ miku }"
· ─────┬────
· ╰── expected block, closure or record
╰────
~:► nu ./miku.nu '32' '{' miku '}'
Miku has 32 leeks 🩵
Hiii world! 初音ミクはみんなのことが大好きだよ！
```
# Description
I added a debug-only check that makes sure only non-other I/O errors get
converted.
Since tests run in debug mode, that should help us catch these errors early.
I left the check out in release mode on purpose so we don't crash users who
have nu as their main shell. It's similar to the debug assertions in the same
file that check for unknown spans.
# Description
This PR depends on #16147, use `git diff 132ikl/shell-warning
132ikl/isolation-warn` to see only changes from this PR
People seem to get tripped up by this a lot, and it's not exactly
intuitive, so I added a warning if you try to set
`$env.config.history.isolation = true` when using the plaintext file
format:
Warning: nu:🐚:invalid_config
⚠ Encountered 1 warnings(s) when updating config
Warning: nu:🐚:incompatible_options
⚠ Incompatible options
╭─[source:1:33]
1 │ $env.config.history.isolation = true
· ──┬─
· ╰── history isolation only compatible with SQLite format
╰────
help: disable history isolation, or set $env.config.history.file_format = "sqlite"
# User-Facing Changes
* Added a warning when using history isolation without using SQLite
history.
# Tests + Formatting
Added a test
# Description
Adds a proper `ShellWarning` enum which has the same functionality as
`ParseWarning`.
Also moves the deprecation from #15806 into `ShellWarning::Deprecated`
with `ReportMode::FirstUse`, so that warning will only pop up once now.
# User-Facing Changes
Technically the change to the deprecation warning from #15806 is user
facing but it's really not worth listing in the changelog
