Follow up on #63775: disabling WebKit touch callouts did not fully
prevent iOS Safari from selecting the entire GPUI canvas alongside the
app's text selection.
Remote Web Inspector captured a viewport-sized DOM range containing the
canvas while its computed `-webkit-touch-callout` was `none` but
`-webkit-user-select` was `text`. Set both standard and WebKit-prefixed
`user-select` to `none` directly when GPUI creates the canvas, without
relying on the embedding application's stylesheet. This leaves
touch-event handling and the hidden IME textarea unchanged.
Closes DEL-2016
## Validation
- On an iPhone, injecting ordinary inline `-webkit-user-select: none`
prevented the issue; switching it back to `text` reproduced it. No
`!important` was necessary. This tested the equivalent runtime style,
not a rebuilt app containing this commit.
- `cargo fmt -p gpui_web -- --check` passed.
- `RUSTC_BOOTSTRAP=1 cargo check -p gpui_web --target
wasm32-unknown-unknown` passed. The bootstrap flag is required by the
existing `wasm_thread` dependency.
Release Notes:
- Fixed unintended whole-canvas selection when long-pressing in GPUI web
applications on iOS.
On iOS, WebKit presents a native touch callout when a user long-presses
a canvas. For GPUI Web this selected the full application canvas while
GPUI independently selected the intended word, producing two pairs of
selection handles, a native edit menu, and haptic feedback.
Set `-webkit-touch-callout: none` on the canvas created by `gpui_web`.
GPUI already owns touch gesture recognition on this surface, so WebKit
should not provide a competing canvas interaction.
Tested with:
- `cargo fmt --check --package gpui_web`
- `RUSTC_BOOTSTRAP=1 cargo check -p gpui_web --target
wasm32-unknown-unknown`
- A Delta Web WASM build using the local Zed checkout
- Manual verification on an iPhone that long-press word selection no
longer selects the full canvas
Release Notes:
- N/A
`KeyBinding::set_default_visibility` lets applications suppress
keybinding labels, but the current visibility value is private to
`KeyBinding::render`. Applications that compose related modifier hints
from lower-level UI elements cannot follow the same presentation policy.
Expose the existing visibility query without changing its behavior. This
lets those callers omit their complete hint, including accompanying text
and spacing, while sharing the same application-wide source of truth.
Release Notes:
- N/A
The local `scratch` override lives under `corgi-patches`, but the Nix
build source filter omitted that directory. As a result, `nix develop`
failed while loading the patched dependency.
Include `corgi-patches` in the filtered source and preserve the patch
implementation in Crane's dummy dependency source. The latter is
required because `cxx-build` calls `scratch::path` while dependency
artifacts are built.
## Testing
- `nix fmt -- --ci nix/build.nix`
- `nix develop --command true`
- `nix develop --command cargo fmt --check`
Release Notes:
- N/A
`KeyBinding` elements currently always render their shortcut labels.
Applications with a touch-oriented interface cannot remove those
keyboard-only visual affordances without changing each consumer or
unregistering the shortcuts themselves.
This adds an application-wide visibility policy to the reusable
`KeyBinding` component, so context menus and other consumers follow the
same setting. Registered keybindings and `aria-keyshortcuts` remain
intact, and labels remain visible by default.
## Testing
- `cargo nextest run -p ui --lib`
- `cargo fmt --check`
- The final unused-override cleanup was not rerun because `nix develop`
currently fails while building the existing `zed-editor-deps`
derivation: `corgi-patches/scratch/Cargo.toml` is absent from its Nix
source.
Release Notes:
- N/A
Zed's `fs_embed!` macro normally reads assets from the checkout in debug
builds. The new `util/debug-embed` feature is intended to compile those
assets into debug binaries, but it previously changed only the
`rust_embed::Filenames` variant while leaving file loading on the
runtime path.
That breaks downstream workspaces such as Delta: the runtime loader
identifies Delta as the repository root, then looks for Zed grammar
assets under Delta's checkout. Tests consequently panic when language
configuration files cannot be found.
This makes `util/debug-embed` select a compile-time `RustEmbed`
expansion in every profile. Builds without the feature retain live
filesystem loading in debug mode. The runtime iterator no longer depends
on a feature-specific `rust_embed::Filenames` variant, so Cargo feature
unification remains safe when another package enables
`rust-embed/debug-embed` directly. The regression fixture uses a
deliberately invalid runtime path when `debug-embed` is enabled, so it
proves that the embedded path is used rather than passing only because
the Zed checkout contains the test assets.
Testing performed:
- `cargo fmt --all -- --check`
- `cargo nextest run -p util --lib`
- `cargo nextest run -p util --lib --features debug-embed`
- `cargo check -p remote_server --features debug-embed`
- `./script/clippy -p util`
- Delta's previously failing
`tools::edit_file::tests::test_edit_file_rejects_scratch_paths_as_read_only`
against this PR's head commit
Release Notes:
- N/A
GPUI's touch gesture recognizer handles taps and pans, but its
long-press event was only a placeholder. Applications therefore could
not distinguish a deliberate press-and-hold from a tap or scroll using
the portable touch path.
This adds deadline-driven long-press recognition and dispatches a phased
event stream through GPUI's existing capture and bubble listener path. A
listener claims the gesture by preventing the initial event's default
behavior and capturing it for an entity. Unclaimed gestures remain
eligible for the existing tap and pan behaviors, while claimed gestures
receive movement and termination events without also producing taps or
scrolling.
The timer is cancelled when the pending gesture resolves. `gpui_web` now
translates reusable browser pointer identifiers into touch identifiers
that remain unique for each touch lifetime, preventing an old timer from
acting on a newer touch. Native macOS trackpad scrolling remains on its
existing `ScrollWheelEvent` path and does not enter touch gesture
recognition.
Testing performed:
- `cargo fmt --all -- --check`
- `cargo nextest run -p gpui --lib long_press` (10 passed)
- `RUSTC_BOOTSTRAP=1 cargo check -p gpui_web --target
wasm32-unknown-unknown`
Release Notes:
- N/A
Touch pans currently preserve small amounts of movement on both axes,
including in the synthetic momentum generated after release. In a nested
scrolling layout, a mostly vertical fling that starts over a
horizontally scrollable child can therefore move the child horizontally
while its ancestor moves vertically.
This locks each touch pan to the dominant axis of its accumulated
movement when it crosses the touch-slop threshold. Initial movement,
predicted updates, release correction, velocity, and momentum are
projected onto that axis, so every scroll listener sees the same
one-dimensional gesture for its full lifetime.
The existing trackpad and wheel behavior remains unchanged; the new rule
is applied by the portable raw-touch recognizer before it emits semantic
scroll events.
Testing:
- `cargo nextest run -p gpui --lib gestures::tests`
- `cargo fmt --all -- --check`
- `./script/clippy -p gpui`
- Built Delta Web for `wasm32-unknown-unknown` with this GPUI worktree
and reached a successful Trunk release build
Release Notes:
- N/A
Prewarming cosmic-text font cache completely eliminated expensive
`get_font_matches` calls and thus reducing the time it takes to call
`cosmic_text::shape::ShapeLine::new`.
Release Notes:
- Improved rendering performance on Linux by prewarming font match
caches.
Closes FR-112
Otherwise, if a multibuffer snapshot changed under the hood for example
one of the paths changed, without doing an explicit validity check, we
would panic during comparison instead.
Release Notes:
- Fixed panic when hovering links during an under-the-hood multibuffer
changes.
Closes FR-133
`cosmic-text`'s BiDi line shaping machinery (`ShapeLine::new`) asserts
that every BiDi paragraph is following the same direction. It turns out
that our `gpui_wgpu` line shaping adapter would not account for that
leading to panics if text contained multiple BiDi paragraphs with
multiple directions. Not super common but worth fixing as the fix is not
super complicated. At the same time, I'd like to point out that there is
a patch submitted to `cosmic-text` that redoes shaping logic so that
this is no longer illegal:
https://github.com/pop-os/cosmic-text/pull/508 If it gets accepted, we
can revert this fix.
Release Notes:
- Fixed panic in `gpui_wgpu` if text contained multiple BiDi paragraphs
with mismatched directions.
Closes#58651
Closes FR-123
https://github.com/zed-industries/zed/pull/50406/ while fixing one issue
regressed serial tracking in Wayland. What happens is we conflated
unrelated serials into a common value which is wrong. For example,
`InputMethod` serial does not come from the same source as `MousePress`
or `KeyPress`, and if Zed is running for a while and the user performs
lots of IME commits (`zwp_text_input_v3.commit`), `InputMethod` will
overtake other serial values and will be incorrectly used for clipboard
authorisation/selection by the compositor such as Mutter or kWin. This
will effectively poison the clipboard making Zed the indefinite owner
until we kill Zed. More concretely, we use `get_latest()` on the serial
tracker to extract *the largest serial REGARDLESS of kind* which is
wrong since not every serial kind comes from the same pool.
Release Notes:
- Fixed copy-paste behaviour in Wayland.
Closes FR-130
Builds compiled from source at a release tag report a non-dev release
channel, so they used to install the crash handler and write minidumps
into the shared logs directory. An official Zed launched later would
find and upload those dumps to Sentry, where they can never be
symbolicated (their debug UUID matches no uploaded debug files).
Gate the crash handler on having somewhere to send the dumps: either the
compile-time ZED_MINIDUMP_ENDPOINT baked into official builds, the
runtime ZED_MINIDUMP_ENDPOINT override, or an explicit
ZED_GENERATE_MINIDUMPS opt-in for debugging the crash pipeline locally.
Release Notes:
- N/A
This actually makes it possible for Linux headless client to have
working windows for computation (well, we are in headless mode after
all). This also matches macOS headless client behaviour.
Release Notes:
- N/A
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Release Notes:
- N/A
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Release Notes:
- N/A
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Release Notes:
- N/A
Self-Review Checklist:
- [ ] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Closes https://github.com/zed-industries/zed/issues/57073
Release Notes:
- Fixed running Zed on Ubuntu 20.04 installed via the installer by
bundling the required `libstdc++.so`.
This PR decouples `language_model`'s dependence on Zed-specific
implementation details. In particular
* `credentials_provider` is split into a generic `credentials_provider`
crate that provides a trait, and `zed_credentials_provider` that
implements the said trait for Zed-specific providers and has functions
that can populate a global state with them
* `zed_env_vars` is split into a generic `env_var` crate that provides
generic tooling for managing env vars, and `zed_env_vars` that contains
Zed-specific statics
* `client` is now dependent on `language_model` and not vice versa
Release Notes:
- N/A
A couple of things that this PR wants to accomplish:
* remove dependency on `settings` crate from `language_model`
* refactor provider-specific code into submodules - to be honest, I
would go one step further and put all provider-specific bits in
`language_models` instead but I realise we have cloud logic in
`language_model` which uses those too making it tricky
* move anthropic-specific telemetry into `language_models` crate - I
think it makes more sense for it to be there
Anyhow, I would very appreciate if you could have a look @mikayla-maki
and @maxdeviant and lemme know what you think, if you would tweak
something, etc.
Release Notes:
- N/A
Closes#51339
This should address issues with too new libstdc++.so on older/more
conservative distros such as RHEL9.
Release Notes:
- Relaxed requirement for libstdc++.so available on Linux distros.
Fixes a panic in livekit's process_reverse_stream for non-matching
channel counts, e.g., upmixing 2->4, or downmixing 2->1.
Release Notes:
- Fixed a panic in livekit when joining a channel using legacy audio
using a device with less or more than 2 channels.
This allows you to now re-use our Zed flake in different side projects
with cargo wrapper script having its path correctly resolved.
Say you have this dir structure:
```
$HOME/dev/zed
$HOME/dev/something
```
Then this now works:
```
$ cd $HOME/dev/something
$ nix develop ../zed
$ cargo version
cargo 1.93.0 (083ac5135 2025-12-15)
```
Release Notes:
- N/A
This would cause a null pointer dereference when trying to open an audio
device in Zed. More context:
https://github.com/NixOS/nixpkgs/pull/478907/changes#r2885943326
cc @cameron1024
Release Notes:
- Fixed crash when trying to join a channel/test audio on Nix-built Zed
on Linux.
We would mark `FileNotFound` as success and progress the update loop
which does not make much sense.
Release Notes:
- Do not skip update roll back in presence of FileNotFound errors on Windows.
Co-authored-by: Miguel Raz Guzman Macedo <raz@zed.dev>
Use `BackgroundExecutor::spawn_with_priority(Priority::RealtimeAudio,
fut)` to spawn the audio input thread with correct thread priority much
like we do for audio output. Under-the-hood, `spawn_with_priority +
Priority::RealtimeAudio` boils down to calling `std::thread::spawn` and
setting appropriate thread priority.
Release Notes:
- N/A
Seems that `SmallVec::clone` is pretty expensive in a generic case, and
specialising it improves the performance quite a bit!
Release Notes:
- Improved performance of different building blocks within the
MultiBuffer.
---------
Co-authored-by: Lukas Wirth <lukas@zed.dev>
This change improves performance of project diff in that:
* scrolling in split view for very large diffs (think chromium repo with
`git reset HEAD~1000`) is now very smooth on macOS and fairly smooth on
Linux
* switching from split to unified is very smooth on macOS, and fairly
smooth on Linux
There still remains the case of (severe) hangs when switching from
unified to split however, but it will be addressed in a follow-up PR.
Anyhow, here's the screenshot of the Instruments.app capture of opening
chromium repo in Zed in split view, scrolling a little, moving to
unified, scrolling some more, and moving back to split. Prior to this
change, split -> unified would cause a severe hang, whereas now it's a
hang and thus feels much smoother already (without Instruments profiling
is barely visible). Unified -> split severe hangs are still there but
don't last as long.
<img width="2301" height="374" alt="Screenshot 2026-02-16 at 5 46 23 PM"
src="https://github.com/user-attachments/assets/f687f8d4-cffd-47f1-ada1-f6c4d3ac3cd4"
/>
Release Notes:
- Improved project diff performance when opening very large
diffs/repositories.
Here's some backstory:
* on macOS, @cole-miller and I noticed that since roughly Oct 2025, due
to some changes to latest macOS Tahoe, for any spawned child process we
needed to reset Mach exception ports
(https://github.com/zed-industries/zed/issues/36754 +
https://github.com/RemiKalbe/zed/commit/6e8f2d2ebe5a93753625a3026aeb996de8cb436b)
* the changes in that PR achieve that via `pre_exec` hook on
`std::process::Command` which then abandons `posix_spawn` syscall for
`fork` + `execve` dance on macOS (we tracked it down in Rust's std
implementation)
* as it turns out, `fork` + `execve` is pretty expensive on macOS
(apparently way more so than on other OSes like Linux) and `fork` takes
a process-wide lock on the allocator which is bad
* however, since we wanna reset exception ports on the child, the only
official way supported by Rust's std is to use `pre_exec` hook
* posix_spawn on macOS exposes this tho via a macOS specific extension
to that syscall `posix_spawnattr_setexceptionports_np` but there is no
way to use that via any standard interfaces in `std::process::Command`
* thus, it seemed like a good idea to instead create our own custom
Command wrapper that on non-macOS hosts is a zero-cost wrapper of
`smol::process::Command`, while on macOS we reimplement the minimum to
achieve `smol::process::Command` with `posix_spawn` under-the-hood
Notably, this changeset improves git-blame in very large repos
significantly.
Release Notes:
- Fixed performance spawning child processes on macOS by always forcing
`posix_spawn` no matter what.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
This PR adds ability to select and test audio input/output devices for
use in collaboration setting (which is what the team at Zed relies
heavily on). Currently, we only ever used whatever the system default is
and it worked well until it didn't - for some reason, when I am on my
Linux laptop, I am unable to force Zed to use my external mic +
headphones via external USB audio interface. With this PR, now I can
list all available devices and select the one I want.
There are still a couple of caveats that we should be aware of:
* I've decided to list *all* available devices meaning on Linux it is
quite possible that you may discover that what your desktop environment
is reporting to you is a significantly shorter list than what your sound
framework/hw is actually exposing. I think this makes sense given my
inexperience with audio drivers/devices and frameworks on various OSes
so that we get full control over what is available with the goal of
being able to come up with some filtering heuristic as we go along.
* We currently populate the list of available audio devices only once at
startup meaning if you unplug your device while you have Zed running
this will not register until you restart Zed which is a PITA. However,
in order to keep the changes manageable I thought it would be best to do
minimal work in this regard now, and iterate on this some more in the
near future. After all, we don't really monitor device changes on any
platform except macOS anyhow, so it might be the case that when I get
round to implementing this I will have the opportunity to tackle both at
the same time.
* In order to get a valid list of all audio devices using `cpal` crate
(which is the building block of `rodio`), I had to bump `cpal` to 0.17,
and pin `rodio` to a more recent commit sha as a result, so if you see
any regressions, lemme know and/or feel free to revert this PR.
* Finally, I've done my best to integrate this with the settings UI, but
I am sure more could be done in terms of styling, etc.
Some screenshots:
<img width="1152" height="949" alt="Screenshot From 2026-02-12 11-40-04"
src="https://github.com/user-attachments/assets/e147c153-1902-49d6-bf68-3ac317a6a7b0"
/>
<img width="1152" height="949" alt="Screenshot From 2026-02-12 11-40-16"
src="https://github.com/user-attachments/assets/b4e9a2f8-b38e-4de0-b910-067cc432b5bc"
/>
Release Notes:
- Added ability to select audio input/output devices as part of
Collaboration page in Settings. Added ability to test selected devices
with a simple playback loop routing input directly into output for
easier debugging of your audio devices.
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Release Notes:
- Added handling of custom blocks in the RHS editor by creating matching
dummy custom blocks rendered as spacer blocks in the LHS editor when in
split view.
Release Notes:
- N/A
--
I think it's possible to clean this up further but will withhold until
we land bits necessary to correctly align split view in presence of
custom blocks.
Skipping setting the language on the git index text buffer improves
snappiness for (very) large git diff multibuffers and also significantly
lower peak and steady-state RSS. When tested on the chromium repo with
`git reset HEAD~1000` and *all* language extensions installed we notice:
* current `main`: peak RSS ~45GB, ss RSS ~39GB
* this patch: peak RSS ~30GB, ss RSS ~27GB
Release Notes:
- Improved memory usage of large git diff multibuffers.
While at it, annotate more functions that are potentially related to
language parsing in buffers.
Also, on macOS, in order to actually have callstack frames properly
recorded by Tracy, you need to manually run `dsymutil` on the binary.
Release Notes:
- N/A
Until now, Helix-mode users would have to rely on Vim's `d *` behaviour
which cannot be reliably replicated with Helix's default delete
behaviour and so I believe that remapping this functionality to Helix's
goto mode is a better fit.
Release Notes:
- Added custom mappings for Zed specific diff and git-related actions to
Helix's goto mode:
* `g o` - toggle selected diff hunks
* `g O` - toggle staged
* `g R` - restore change
* `g u` - stage and goto next diff hunk
* `g U` - unstage and goto next diff hunk
We restructured `struct Repository` a bit so that it now stores a shared
task of `enum RepositoryState`. This way, we can now re-use it outside
of the git job queue when spawning a git job a standalone bg task. An
example here would be `git-blame` that does not require any file locks
and is not susceptible to git job ordering.
As a result of this change, loading (and modifying) a file that contains
a huge git history will no longer block other git operations on the repo
such as staging/unstaging/committing.
Release Notes:
- Improved overall git experience when loading buffers with massive git
history where they would block other git jobs from running (such as
staging/unstaging/commiting). Now, git-blame will run separately from
the git job queue on the side and the buffer with blame hints when
finished thus unblocking other git operations.
Co-authored-by: Cole Miller <cole@zed.dev>
We now run git pre-commit hooks before we commit. This ensures we don't
run into timeout issues with askpass delegate and report invalid error
to the user.
Closes#43157
Release Notes:
- Fixed long running pre-commit hooks causing committing from Zed to
fail.
Co-authored-by: Cole Miller <cole@zed.dev>
The idea is that we only store running (`!self.finished`) or finished
(`self.finished`) pending ops, while everything else (skipped, errored)
jobs are pruned out immediately. We don't really need them in the grand
scheme of things anyway.
Release Notes:
- N/A
In my local setup, I always enforce git-commit signing with GPG/SSH
which automatically enforces `git commit -S` when committing. This
changeset will now show a modal to the user for them to specify the
passphrase (if any) so that they can unlock their private key for
signing when committing in Zed.
<img width="1086" height="948" alt="Screenshot 2025-11-07 at 11 09
09 PM"
src="https://github.com/user-attachments/assets/ac34b427-c833-41c7-b634-8781493f8a5e"
/>
Release Notes:
- Handle automatic git-commit signing by presenting the user with an
askpass modal
Previously, staging a large file in the git panel would block the UI
items until that operation finished. This is due to the fact that
staging is a git op that is locked globally by git (per repo) meaning
only one op that is modifying the git index can run at any one time. In
order to make the UI snappy while letting any pending git staging jobs
to finish in the background, we track their progress via `PendingOps`
indexed by git entry path. We have already had a concept of pending
operations however they existed at the UI layer in the `GitPanel`
abstraction. This PR moves and augments `PendingOps` into the model
`Repository` in `git_store` which seems like a more natural place for
tracking running git jobs/operations. Thanks to this, pending ops are
now stored in a `SumTree` indexed by git entry path part of the
`Repository` snapshot, which makes for efficient access from the UI.
Release Notes:
- Improved UI responsiveness when staging/unstaging large files in the
git panel
Prior to this change we would always resolve envs when spawning a new
terminal window based on the inherited CLI environment. This works fine
as long as we open a new Zed instance in the terminal when using it
locally only. When using Zed connected to a remote server, it would not
be meaningful however. WIth this change, we correctly ping the remote
for the project-local envs and use that instead. This change should also
fix a pesky issue when updating Zed - after Zed restarts, opening a new
terminal window will not run `direnv` for example.
Release Notes:
- N/A
Currently, this only applies to long-running individually selected
unstaged files in the git panel. Next up I would like to make this work
for `Stage All`/`Unstage All` however this will most likely require
pushing `PendingOperation` into `GitStore` (from the `GitPanel`).
Release Notes:
- N/A
This change adds two things to our remote server build
process:
1. It now checks if all required tooling is installed before using it or installing it on demand. This includes checks for `rustup` and `cargo-zigbuild` in your `PATH`.
2. Next, if `ZED_BUILD_REMOTE_SERVER` contains `musl` and `ZED_ZSTD_MUSL_LIB`
is set, we will pass its value (the path) to `cargo-zigbuild` as `-C
link-arg=-L{path}`.
Release Notes:
- N/A
Fixes https://github.com/zed-industries/zed/issues/41260
After experimenting and reading through the implementation of OpenSSH
stack on Windows, it looks like batch mode precludes use of passwords.
In the listing
https://github.com/PowerShell/openssh-portable/blob/b8c08ef9da9450a94a9c5ef717d96a7bd83f3332/sshconnect2.c#L417,
the last field of each `Authmode` struct is a pointer to the config
value that *disables* that particular mode. In this case, `keyboard`
(interactive) and `password` modes are both disabled if batch mode is
used. We should therefore fall back to `scp` if `sftp` fails rather than
to fail outright.
Release Notes:
- N/A
Using `shlex` unconditionally is dangerous as it assumes the underlying
shell is POSIX which is not the case for PowerShell, CMD, or Nushell.
Therefore, whenever we want to quote the args we should utilise our
helper `util::shell::ShellKind::try_quote` which takes into account
which shell is being used to actually exec/spawn the invocation.
Release Notes:
- N/A
---------
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
Jakub Konka