Not quite sure why the previous version used a subshell expression when
the output could just as easily be piped to `Invoke-Expression`.
This is more akin to how `source` works in Fish as opposed to the Bash
builtin.
This also splits the instructions for dynamic completions into separate
lines. I think that helps better understand what's going on (PowerShell
lacks temporary environment variables) and avoid scrolling.
On Windows, PowerShell scripts are not allowed to be executed by default
due to the default execution policy `Restricted`. This includes the
`$PROFILE` script (even though PowerShell will still happily attempt to
source it if it exist, resulting in "running scripts is disabled on this
system" errors every time it starts... go figure...).
To avoid this, you generally need to set the execution policy to at
least `RemoteSigned` (which will only block scripts downloaded from the
internet which are not signed; this is the default on Windows Server).
This can be done by running
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
as an administrator, though there tends to be [discussions][1] about the
security tradeoffs of scope and granularity, so I think it is best to
link to the MS documentation on execution policies to allow users to
draw their own conclusions.
This issue does not affect PowerShell users on Linux or macOS.
[1]: https://superuser.com/questions/106360/how-to-enable-execution-of-powershell-scripts
1.90 was just released, so this seems reasonable, and it finally lets us
use let-chains. This includes all the clippy fixups too, and some small
changes suggested by Ilya.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
As suggested by @PhilipMetzger
The word "grey" is whitelisted because
- we have a contributor of that name
- we use a library that uses "Grey" as a member of an enum
- I refuse to believe "grey" is not US English
The optional arguments for each shell were deprecated in #2945 and v0.19.0.
The `shell` argument is now required, and Bash completions are no longer generated by
default if `jj util completion` is run without any arguments.
To avoid redundant computation, users who run `COMPLETE=fish jj | source`
in their ~/.config/fish/config.fish should eventually remove that, or move it
to ~/.config/fish/completions/jj.fish which overrides the default completions.
Ref: https://github.com/fish-shell/fish-shell/pull/11046
The CI seems to correctly use rustc 1.84.1 (and not 1.84.0) with this.
For reference, we last updated the MSRV to 1.76 in 5b517b5. According to
https://releases.rs/docs/1.76.0/, this was when it barely became stable.
`flake.nix` seems to be using a nightly toolchain now, so it seems there
is no need to update the version there.
The more precise clippy command used was:
cargo clippy --workspace --all-targets --fix
In recent times multiple users showed up and were confused _why_ some
completions didn't show up, so make it explicit that they're opt-in
until the Clap upstream has made it so.
Also remove the link to the dynamic completions improvements issue, as it was closed
a while ago.
It was not clear if users should activate both sets of completions if they
wanted the dynamic ones.
The shell commands for activating the dynamic completions are aligned with the
static version. Users can choose / are responsible themselves to add the
activation to their shell config if they want them in every shell instance.
For fish specifically, `script | source` is more idiomatic than
`source (script | psub)`.
We have our MSRV recorded in `Cargo.toml`, but at least with Rust
versions < 1.71, the build fails before the MSRV is checked (IIUC),
and you get a cryptic message like this:
```
error: Package jj-lib v0.22.0 (<some path>) does not have feature git2.
```
The message is clearer from 1.71, but that doesn't help users who have
an older version. Let's mention the MSRV everywhere we tell the user
to run `cargo` in the installation instructions.
