# Description
This PR updates nushell to the latest commit of reedline that fixes some
rendering issues on window resize.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# 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
> ```
-->
# 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.
-->
- This PR should fix/close:
- #11266
- #12893
- #13736
- #13748
- #14170
- It doesn't fix#13736 though unfortunately. The issue there is at a
different level to this fix (I think probably in the lexing somewhere,
which I haven't touched).
# The Problem
The linked issues have many examples of the problem and the related
confusion it causes, but I'll give some more examples here for
illustration. It boils down to the following:
This doesn't type check (good):
```nu
def foo []: string -> int { false }
```
This does (bad):
```nu
def foo [] : string -> int { false }
```
Because the parser is completely ignoring all the characters. This also
compiles in 0.100.0:
```nu
def blue [] Da ba Dee da Ba da { false }
```
And this also means commands which have a completely fine type, but an
extra space before `:`, lose that type information and end up as `any ->
any`, e.g.
```nu
def foo [] : int -> int {$in + 3}
```
```bash
$ foo --help
Input/output types:
╭───┬───────┬────────╮
│ # │ input │ output │
├───┼───────┼────────┤
│ 0 │ any │ any │
╰───┴───────┴────────╯
```
# The Fix
Special thank you to @texastoland whose draft PR (#12358) I referenced
heavily while making this fix.
That PR seeks to fix the invalid parsing by disallowing whitespace
between `[]` and `:` in declarations, e.g. `def foo [] : int -> any {}`
This PR instead allows the whitespace while properly parsing the type
signature. I think this is the better choice for a few reasons:
- The parsing is still straightforward and the information is all there
anyway,
- It's more consistent with type annotations in other places, e.g. `do
{|nums : list<int>| $nums | describe} [ 1 2 3 ]` from the [Type
Signatures doc
page](https://www.nushell.sh/lang-guide/chapters/types/type_signatures.html)
- It's more consistent with the new nu parser, which allows `let x :
bool = false` (current nu doesn't, but this PR doesn't change that)
- It will be less disruptive and should only break code where the types
are actually wrong (if your types were correct, but you had a space
before the `:`, those declarations will still compile and now have more
type information vs. throwing an error in all cases and requiring spaces
to be deleted)
- It's the more intuitive syntax for most functional programmers like
myself (haskell/lean/coq/agda and many more either allow or require
whitespace for type annotations)
I don't use Rust a lot, so I tried to keep most things the same and the
rest I wrote as if it was Haskell (if you squint a bit). Code
review/suggestions very welcome. I added all the tests I could think of
and `toolkit check pr` gives it the all-clear.
# User-Facing Changes
This PR meets part of the goal of #13849, but doesn't do anything about
parsing signatures twice and doesn't do much to improve error messages,
it just enforces the existing errors and error messages.
This will no doubt be a breaking change, mostly because the code is
already broken and users don't realise yet (one of my personal scripts
stopped compiling after this fix because I thought `def foo [] -> string
{}` was valid syntax). It shouldn't break any type-correct code though.
# Description
fixes
[this](https://github.com/nushell/nushell/pull/14303#issuecomment-2525100480)
where lsp and ide integration would produce the following error
---
```sh
nu --ide-check 100 "/path/to/env.nu"
```
with
```nu
const const_env = path self
```
would lead to
```
Error: nu:🐚:file_not_found
× File not found
╭─[/path/to/env.nu:1:19]
1 │ const const_env = path self
· ────┬────
· ╰── Couldn't find current file
╰────
```
# Tests + Formatting
- 🟢 `cargo fmt --all`
- 🟢 `cargo clippy --workspace`
<!--
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.
-->
In this PR I exposed the struct `ToHtml` that comes from `nu-cmd-extra`.
I know this command isn't in a best state and should be changed in some
way in the future but having the struct exposed makes transforming data
to html way more simple for external tools as the `PipelineData` can
easily be placed in the `ToHtml::run` method.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
None.
# 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
> ```
-->
I did `fmt` and `check` but not `test`, shouldn't break any tests
regardless.
# 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.
-->
For the demo page or my jupyter kernel would this make my life easiert.
Alternative solution to:
- #12195
The other approach:
- #14305
# Description
Adds ~`path const`~ `path self`, a parse-time only command for getting
the absolute path of the source file containing it, or any file relative
to the source file.
- Useful for any script or module that makes use of non nuscript files.
- Removes the need for `$env.CURRENT_FILE` and `$env.FILE_PWD`.
- Can be used in modules, sourced files or scripts.
# Examples
```nushell
# ~/.config/nushell/scripts/foo.nu
const paths = {
self: (path self),
dir: (path self .),
sibling: (path self sibling),
parent_dir: (path self ..),
cousin: (path self ../cousin),
}
export def main [] {
$paths
}
```
```nushell
> use foo.nu
> foo
╭────────────┬────────────────────────────────────────────╮
│ self │ /home/user/.config/nushell/scripts/foo.nu │
│ dir │ /home/user/.config/nushell/scripts │
│ sibling │ /home/user/.config/nushell/scripts/sibling │
│ parent_dir │ /home/user/.config/nushell │
│ cousin │ /home/user/.config/nushell/cousin │
╰────────────┴────────────────────────────────────────────╯
```
Trying to run in a non-const context
```nushell
> path self
Error: × this command can only run during parse-time
╭─[entry #1:1:1]
1 │ path self
· ─────┬────
· ╰── can't run after parse-time
╰────
help: try assigning this command's output to a const variable
```
Trying to run in the REPL i.e. not in a file
```nushell
> const foo = path self
Error: × Error: nu:🐚:file_not_found
│
│ × File not found
│ ╭─[entry #3:1:13]
│ 1 │ const foo = path self
│ · ─────┬────
│ · ╰── Couldn't find current file
│ ╰────
│
╭─[entry #3:1:13]
1 │ const foo = path self
· ─────┬────
· ╰── Encountered error during parse-time evaluation
╰────
```
# Comparison with #14305
## Pros
- Self contained implementation, does not require changes in the parser.
- More concise usage, especially with parent directories.
---------
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
- fixes flakey tests from solving #14241
# Description
This is a preliminary fix for the flaky tests and also
shortened the `--max-time` in the tests.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
---------
Signed-off-by: Alex Kattathra Johnson <alex.kattathra.johnson@gmail.com>
