Both cloning and dropping of these has quite a bit of overhead (despite
them being snapshots), so avoid where possible, especially in display
map syncing
Release Notes:
- N/A or Added/Fixed/Improved ...
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
### Context:
- Having a unified way of searching would allow for better debugging as
we move forward here. Right now we have remote/headless specific
searching and it's getting messy. This should allow for a more intuitive
function graph in the head for debugging environment related issues in
remote repl. The implementation mirrors python.rs approach.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes#50892
Release Notes:
- N/A
Coming from #51834, these would be more helpful than just that it
failed!
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
## Context
Closes#51874
the repl is able to recognize that the venv is managed by uv, but still
runs `python -m pip install ipykernel`, despite this not working. this
PR fixes that behavior and uses uv to install ipkernel.
## How to Review
Added a path that uses uv to install ipykernel in repl_editor.rs
Added a function to repl_store.rs that allows updating the venv as
having ipykernel installed after installing it.
## Videos
Old Behavior:
https://github.com/user-attachments/assets/9de81cc9-cd78-4570-ad57-550f5ecabffa
New Behavior:
https://github.com/user-attachments/assets/391f54c7-ae67-4d85-8f4f-9d87ddc8db63
## Self-Review Checklist
<!-- Check before requesting review: -->
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- repl: Fixed installing ipykernel with uv managed environements
Switch python_env_kernel_specifications to a buffered stream (using
buffer_unordered(4) and filter_map) to run discovery concurrently with a
bounded parallelism and skip None results.
Closes#50988
Before you mark this PR as ready for review, make sure that you have:
- [x] Added a solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
- [x] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A
Follow up to https://github.com/zed-industries/zed/pull/48760 thanks to
@miguelraz and @reflectronic.
No new notes since #48760 did the same thing, only wasn't opting in to
process groups we already had in place.
Release Notes:
- N/A
Split WslRemote out of the remote_kernels bucket in the kernel picker,
giving it its own "WSL Kernels" section. Use the distro name and
kernelspec display name for WSL entries instead of the generic "WSL"
string.
In python_env_kernel_specifications, detect WSL projects via
RemoteConnectionOptions and return WslRemote instead of SshRemote. Stop
marking WSL worktrees as remote so global kernel specs load.
Fix ark kernel stdout pollution by building the wsl.exe bash command
with a quoted cd and inline env assignment, so exec replaces the shell
and doesn't echo input back.
Closes#50459
Before you mark this PR as ready for review, make sure that you have:
- [x] Added a solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
- [x] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A
Closes#15196, #46918
- fix: notebook_ui, use buffer so that notebooks open in remote/WSL
settings.
- fix: add musl in nix for cross-compilation, without this remote server
doesn't build inside NixOS
Release Notes:
- Implement WSL and SSH remote kernels (crates/repl/src/kernels/*) and
wire up spawn/kill kernel proto messages and client requests.
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>
Closes#21529
Show a toast when a message from a Jupyter kernel doesn't parse
properly.
Discovered that some kernels don't include their execution count in an
`ExecuteReply` which is required in the jupyter protocol. Upstream I'll
go make that field either be an `Option` or just stick
`#[serde(default)]` on it so it's not a change in the interface.
Release Notes:
- Show error when parsing a message from a Jupyter kernel fails
Hot on the heels of https://github.com/zed-industries/zed/pull/48817 I'm
bringing the best improvement to the repl underneath: `split()`-able
sockets! Much more will be unlocked by having this.
This split the shell and control `DealerSocket` connections into
independent send/recv halves using the new `split()` API from zeromq
0.5.0 and runtimelib 1.x. This also nicely cleaned things up so we could
have a single `select!` loop over iopub, shell, and control recv halves.
That replaces three separate recv tasks.
This likely closes some issues for certain kernels that would get stuck
either during startup or other flows due to them not sending replies to
specific requests. I'll see if I can find issues around this and update
the release notes after.
This allows us to unlock some nifty new things we can do on the shell
socket, particularly autocompletion for in-memory values, stdin support,
and others. I _think_ it also help with sending and receving
`KernelInfo`, which not all kernels do properly at the start. This makes
us a bit more resilient to errant kernels.
Release Notes:
- N/A
Closes#17985Closes#21911
Force the shutdown of the kernel by ensuring the kernel sessions are
dropped on app quit.
Release Notes:
- Fixed shutdown of kernels on app exit
Coming from discussion on #25936 and
https://github.com/zed-industries/zed/pull/19756 .
This PR introduces the KernelSession abstraction and adds basic notebook
cell execution inside NotebookEditor.
The following provides a base starter for the development on Notebooks.
What this PR includes today:
Release Notes:
- KernelSession trait extracted. Both REPL and NotebookEditor now share
the same routing mechanism.
- NotebookEditor can launch kernels, execute code cells, and display
outputs.
- Basic cell operations: run current cell, run all, move up/down, add
code/markdown blocks. Keybindings follow Jupyter defaults.
Next Steps:
- [x] Editing support for markdown and code blocks.
- Buffer integration instead of temporary cell text.
- [x] Proper focus behavior when executing or adding cells.
- Kernel control UI.
A little far fetched steps:
- Vim Support
- Cell Handling Improvement and other convenient features and design
from other editors
- Ability to have better parsing for AI Support.
I have attached a video of showcasing some of the features:
https://github.com/user-attachments/assets/37e6f3e5-2022-45f0-a73d-2dd01ebc2932
Implements a specialized constructor `LanguageName::new_static` for
`&'static str` which reduces allocations.
`LanguageName::new` always backs the underlying `SharedString` with an
owned `Arc<str>` even when a `&'static str` is passed. This makes us
allocate each time we create a new `LanguageName` no matter what.
Creating a specialized constructor for `&'static str` allows us to
essentially construct them for free.
Additional change:
Encourages using explicit constructors to avoid needless allocations.
Currently there were no instances of this trait being called where the
lifetime was not `'static` saving another 48 locations of allocation.
```rust
impl<'a> From<&'a str> for LanguageName {
fn from(str: &'a str) -> Self {
Self(SharedString::new(str))
}
}
// to
impl From<&'static str> for LanguageName {
fn from(str: &'static str) -> Self {
Self(SharedString::new_static(str))
}
}
```
Release Notes:
- N/A
Closes#40888
This updates runtimed to the latest version, which handles the
"starting" variant of `execution_state`. It actually handles a bunch of
other variants that are not documented in the protocol (see
https://jupyter-client.readthedocs.io/en/stable/messaging.html#kernel-status),
like "starting", "terminating", etc. I added implementations for these
variants as well.
Release Notes:
- Fixed issue that prevented the Ark kernel from working in Zed
(#40888).
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Closes#40884
- Make IOPub task return a `Result`
- Create a monitoring task that watches over IOPub, Control, Routing and
Shell tasks.
- If any of these tasks fail, report the error with `kernel_errored()`
(which is already used to report process crashes)
https://github.com/user-attachments/assets/3125f6c7-099a-41ca-b668-fe694ecc68b9
This is not perfect. I did not have time to look into this but:
- When such errors happen, the kernel should be shut down.
- The kernel should no longer appear as online in the UI
But at least the user is getting feedback on what went wrong.
Release Notes:
- Jupyter client errors are now surfaced in the UI (#40884)
Closes https://github.com/zed-industries/zed/issues/38690Closes#37353
### Background
On Windows, paths are normally separated by `\`, unlike mac and linux
where they are separated by `/`. When editing code in a project that
uses a different path style than your local system (e.g. remoting from
Windows to Linux, using WSL, and collaboration between windows and unix
users), the correct separator for a path may differ from the "native"
separator.
Previously, to work around this, Zed converted paths' separators in
numerous places. This was applied to both absolute and relative paths,
leading to incorrect conversions in some cases.
### Solution
Many code paths in Zed use paths that are *relative* to either a
worktree root or a git repository. This PR introduces a dedicated type
for these paths called `RelPath`, which stores the path in the same way
regardless of host platform, and offers `Path`-like manipulation APIs.
RelPath supports *displaying* the path using either separator, so that
we can display paths in a style that is determined at runtime based on
the current project.
The representation of absolute paths is left untouched, for now.
Absolute paths are different from relative paths because (except in
contexts where we know that the path refers to the local filesystem)
they should generally be treated as opaque strings. Currently we use a
mix of types for these paths (std::path::Path, String, SanitizedPath).
Release Notes:
- N/A
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Peter Tripp <petertripp@gmail.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
- **toolchains: Add new state to toolchain selector**
- **Use toolchain term for Add Toolchain button**
- **Hoist out a meta function for toolchain listers**
Closes#27332
Release Notes:
- python: Users can now specify a custom path to their virtual
environment from within the picker.
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
This removes around 900 unnecessary clones, ranging from cloning a few
ints all the way to large data structures and images.
A lot of these were fixed using `cargo clippy --fix --workspace
--all-targets`, however it often breaks other lints and needs to be run
again. This was then followed up with some manual fixing.
I understand this is a large diff, but all the changes are pretty
trivial. Rust is doing some heavy lifting here for us. Once I get it up
to speed with main, I'd appreciate this getting merged rather sooner
than later.
Release Notes:
- N/A
This reverts commit 1e55e88c1822402566bdec8a893ec0429d8ee5e6.
Closes #ISSUE
Release Notes:
- Python toolchain selector now uses path to the closest pyproject.toml
as a basis for picking a toolchain. All files under the same
pyproject.toml (in filesystem hierarchy) will share a single virtual
environment. It is possible to have multiple Python virtual environments
selected for disjoint parts of the same project.
https://github.com/zed-industries/zed/issues/30972 brought up another
case where our context is not enough to track the actual source of the
issue: we get a general top-level error without inner error.
The reason for this was `.ok_or_else(|| anyhow!("failed to read HEAD
SHA"))?; ` on the top level.
The PR finally reworks the way we use anyhow to reduce such issues (or
at least make it simpler to bubble them up later in a fix).
On top of that, uses a few more anyhow methods for better readability.
* `.ok_or_else(|| anyhow!("..."))`, `map_err` and other similar error
conversion/option reporting cases are replaced with `context` and
`with_context` calls
* in addition to that, various `anyhow!("failed to do ...")` are
stripped with `.context("Doing ...")` messages instead to remove the
parasitic `failed to` text
* `anyhow::ensure!` is used instead of `if ... { return Err(...); }`
calls
* `anyhow::bail!` is used instead of `return Err(anyhow!(...));`
Release Notes:
- N/A
We're seeing panics caused by a buggy implementation of AsyncWrite
that is being passed to rustls:
https://github.com/rustls/rustls/issues/2316#issuecomment-2662838186
One hypothesis was that we're using (comparatively) non-standard async
tools for connecting over websockets; so this attempts to make us be
(comparitvely) more standard.
Release Notes:
- N/A
This is the core change:
https://github.com/zed-industries/zed/pull/26758/files#diff-044302c0d57147af17e68a0009fee3e8dcdfb4f32c27a915e70cfa80e987f765R1052
TODO:
- [x] Use AsyncFn instead of Fn() -> Future in GPUI spawn methods
- [x] Implement it in the whole app
- [x] Implement it in the debugger
- [x] Glance at the RPC crate, and see if those box future methods can
be switched over. Answer: It can't directly, as you can't make an
AsyncFn* into a trait object. There's ways around that, but they're all
more complex than just keeping the code as is.
- [ ] Fix platform specific code
Release Notes:
- N/A
Done automatically with
> ast-grep -p '$A.background_executor().spawn($B)' -r
'$A.background_spawn($B)' --update-all --globs "\!crates/gpui"
Followed by:
* `cargo fmt`
* Unexpected need to remove some trailing whitespace.
* Manually adding imports of `gpui::{AppContext as _}` which provides
`background_spawn`
* Added `AppContext as _` to existing use of `AppContext`
Release Notes:
- N/A
There's still a bit more work to do on this, but this PR is compiling
(with warnings) after eliminating the key types. When the tasks below
are complete, this will be the new narrative for GPUI:
- `Entity<T>` - This replaces `View<T>`/`Model<T>`. It represents a unit
of state, and if `T` implements `Render`, then `Entity<T>` implements
`Element`.
- `&mut App` This replaces `AppContext` and represents the app.
- `&mut Context<T>` This replaces `ModelContext` and derefs to `App`. It
is provided by the framework when updating an entity.
- `&mut Window` Broken out of `&mut WindowContext` which no longer
exists. Every method that once took `&mut WindowContext` now takes `&mut
Window, &mut App` and every method that took `&mut ViewContext<T>` now
takes `&mut Window, &mut Context<T>`
Not pictured here are the two other failed attempts. It's been quite a
month!
Tasks:
- [x] Remove `View`, `ViewContext`, `WindowContext` and thread through
`Window`
- [x] [@cole-miller @mikayla-maki] Redraw window when entities change
- [x] [@cole-miller @mikayla-maki] Get examples and Zed running
- [x] [@cole-miller @mikayla-maki] Fix Zed rendering
- [x] [@mikayla-maki] Fix todo! macros and comments
- [x] Fix a bug where the editor would not be redrawn because of view
caching
- [x] remove publicness window.notify() and replace with
`AppContext::notify`
- [x] remove `observe_new_window_models`, replace with
`observe_new_models` with an optional window
- [x] Fix a bug where the project panel would not be redrawn because of
the wrong refresh() call being used
- [x] Fix the tests
- [x] Fix warnings by eliminating `Window` params or using `_`
- [x] Fix conflicts
- [x] Simplify generic code where possible
- [x] Rename types
- [ ] Update docs
### issues post merge
- [x] Issues switching between normal and insert mode
- [x] Assistant re-rendering failure
- [x] Vim test failures
- [x] Mac build issue
Release Notes:
- N/A
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Joseph <joseph@zed.dev>
Co-authored-by: max <max@zed.dev>
Co-authored-by: Michael Sloan <michael@zed.dev>
Co-authored-by: Mikayla Maki <mikaylamaki@Mikaylas-MacBook-Pro.local>
Co-authored-by: Mikayla <mikayla.c.maki@gmail.com>
Co-authored-by: joão <joao@zed.dev>
This PR adds the initial concept of an `IconTheme` and refactors
`FileIcons` to use it to resolve the icons.
The `IconTheme` will ultimately be used to allow users to select a
different set of icons to use. Currently, however, this is just laying
the foundation for that work.
The association between file types and icons is now handled by the icon
theme when we resolve file icons. This mapping has been moved out of
`file_types.json` and into `icon_theme.rs`.
Release Notes:
- N/A
- [x] Rewrite worktree git handling
- [x] Fix tests
- [x] Fix `test_propagate_statuses_for_repos_under_project`
- [x] Replace `WorkDirectoryEntry` with `WorkDirectory` in
`RepositoryEntry`
- [x] Add a worktree event for capturing git status changes
- [x] Confirm that the local repositories are correctly updating the new
WorkDirectory field
- [x] Implement the git statuses query as a join when pulling entries
out of worktree
- [x] Use this new join to implement the project panel and outline
panel.
- [x] Synchronize git statuses over the wire for collab and remote dev
(use the existing `worktree_repository_statuses` table, adjust as
needed)
- [x] Only send changed statuses to collab
Release Notes:
- N/A
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Mikayla <mikayla@zed.com>
Co-authored-by: Nathan <nathan@zed.dev>
Some VPN configurations require that websockets present a user agent.
This adds it in directly for the repl usage. I wish there was a way to
reuse the user agent from the `cx.http_client`, but I'm not seeing a
simple way to do that for the moment since it's not on the `HttpClient`
trait.
No release notes since this feature hasn't been announced/exposed.
Release Notes:
- N/A
This PR introduces a unified interface for both native and remote
kernels through the `RunningKernel` trait. When either the native kernel
or the remote kernels are started, they return a `Box<dyn
RunningKernel>` to make it easier to work with the session. As a bonus
of this refactor, I've dropped some of the mpsc channels to instead opt
for passing messages directly to `session.route(message)`. There was a
lot of simplification of `Session` by moving responsibilities to
`NativeRunningKernel`.
No release notes yet until this is finalized.
* [x] Detect remote kernelspecs from configured remote servers
* [x] Launch kernel on demand
For now, this allows you to set env vars `JUPYTER_SERVER` and
`JUPYTER_TOKEN` to access a remote server. `JUPYTER_SERVER` should be a
base path like `http://localhost:8888` or
`https://notebooks.gesis.org/binder/jupyter/user/rubydata-binder-w6igpy4l/`
Release Notes:
- N/A
Starts setting up a `RunningKernel` trait to make the remote kernel
implementation easy to get started with. No release notes until this is
all hooked up.
Release Notes:
- N/A
Lukas Wirth