Follow-Up-For: #47243
Previously, we would detach tasks spawned to watch config files.
However, the task blocked on receiving a file event before checking if
the receiver for the updates channel was dropped, causing the task to
never exit. The fix here was to return the task explicitly, so that it
can be dropped instead of calling `.detach()` on it. There is definitely
a way to `select!` between the receiver being dropped and the next file
system event, but I couldn't figure it out in a reasonable amount of
time and decided it wasn't worth it.
Release Notes:
- Fixed an issue where a few file descriptors would be leaked each time
a project was closed
This is still behind a feature flag as the registry is still WIP, but
allows downloading binary agents from the registry on github.
Release Notes:
- N/A
Closes#41832
Extends https://github.com/zed-industries/zed/pull/19455
When an internal `.editorconfig` is detected in the worktree, we
traverse parent directories up to the filesystem root looking for
additional `.editorconfig` files. All discovered external configs are
loaded and cached (shared when multiple worktrees reference the same
parent directories). When computing settings for a file, external
configs are applied first (from furthest to closest), then internal
configs.
For local projects, file watchers are set up for each external config so
changes are applied immediately. When a project is shared via collab,
external configs are sent to guests through the existing
`UpdateWorktreeSettings` proto message (with a new `outside_worktree`
field). SSH remoting works similarly.
Limitations: We don't currently take creation of new external editor
config files into account since they are loaded once on worktree add.
Release Notes:
- Added support for `.editorconfig` files outside the project directory.
Zed now traverses parent directories to find and apply EditorConfig
settings. Use `root = true` in any `.editorconfig` to stop inheriting
settings from parent directories.
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
Closes#40327
The env vars were only getting added if a custom command was provided.
But it makes sense in either case to be able to specify your env vars,
so now these are applied regardless.
Closes #ISSUE
Release Notes:
- acp: Fix for env vars not being properly applied to built-in ACP
agents.
Closes #ISSUE
Moves the settings content definitions into their own crate, so that
they are compiled+cached separately from settings, primarily to avoid
recompiles due to changes in gpui. In that vain many gpui types such as
font weight/features, and `SharedString` were replaced in the content
crate, either with `*Content` types for font/modifier things, or
`String`/`Arc<str>` for `SharedString`. To make the conversions easy a
new trait method in the settings crate named `IntoGpui::into_gpui`
allows for `into()` like conversions to the gpui types in
`from_settings` impls.
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Release Notes:
- Opening bundled files, keymap, and local release notes now opens in
remote windows instead of opening a new local zed window
- Opening the settings files, keymap files, task files, debug files and
logs will now open within wsl windows instead of opening a new local zed
window
Closes https://github.com/zed-industries/zed/issues/34402
Release Notes:
- MCP servers can now be run on the remote server when using remote
development. This can be enabled by setting the `"remote": true`
property in the settings entry for the MCP server.
---------
Co-authored-by: localcc <kate@zed.dev>
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
- **copilot: Fix double lease panic when signing out**
- **Extract copilot_chat into a separate crate**
- **Do not use re-exports from copilot**
- **Use new SignIn API**
- **Extract copilot_ui out of copilot**
Closes#7501
Release Notes:
- Fixed Copilot providing suggestions from different Zed windows.
- Copilot edit predictions now support jumping to unresolved
diagnostics.
This PR introduces a project dropdown when working with multiple
folders/projects in one workspace. Here are some interaction details
that I hope improves the UX of working on this scenario significantly:
- The dropdown shows the currently "active" project, which is determined
by:
- Either the file you're currently editing
- Or the file you have just recently switched to
- Some example cases:
- If you are focused on file from project A but switch to project B in
the titlebar, nothing happens. However, as soon as you type on the file
from project A, the title bar will update and your active project will
return to being project A.
- If you're focused on file from project A and change tabs to a file
from project B, the title bar will update, showing project B as the
active one.
- The content you'll see in the branch picker will correspond to the
currently active project
- It's still possible to reach the "Recent Projects" picker through the
project dropdown
- It's possible to do all interactions (trigger dropdown, select active
project, and remove project from workspace) with the keyboard
https://github.com/user-attachments/assets/e2346757-74df-47c5-bf4d-6354623b6f47
Note that this entire UX is valid only for a multiple folder workspace
scenario; nothing changes for the single project case.
Release Notes:
- Workspace: Improved the UX of working with multiple projects in the
same workspace through introducing a project dropdown that more clearly
shows the currently active project as well as allowing you to change it.
This PR adds the ability to open local terminals when working in remote
projects. When working in a remote (often actually remoting into a local
container) I always need to run separate terminals outside Zed so I can
run local build tools, scripts, agents, etc. for the related project.
I'd like to be able to run all of these in the same Zed window and this
adds that ability via one-off local terminals.
## Changes
Adds an optional `local` parameter to terminal commands. When set to
`true`, creates a local shell on your machine instead of connecting to
the remote.
### Implementation
- Added `force_local` parameter to terminal creation logic
- Created `create_local_terminal()` method that bypasses remote client
- Updated terminal actions (`NewTerminal`, `NewCenterTerminal`) to
accept optional `local: bool` field (defaults to `false`)
### Usage
**Via keybinding:**
```json
{
"bindings": {
"cmd-t": "workspace::NewCenterTerminal",
"cmd-T": ["workspace::NewCenterTerminal", { "local": true }]
}
},
{
"context": "Terminal",
"bindings": {
"cmd-n": "workspace::NewTerminal",
"cmd-N": ["workspace::NewTerminal", { "local": true }],
},
},
```
**Behavior:**
- Default terminal commands continue to work as before (remote in remote
projects, local in local projects)
- The `local` parameter is optional and defaults to `false`
Release Notes:
- Added support for opening local terminals in remote projects via
`local` parameter on terminal commands.
Collab projects are considered trusted and remote clients use the
editor-related settings only. A better fix would be sync "not trusted"
indicator with the project host, and disallow clients' iteraction with
that indicator.
Release Notes:
- Fixed collab settings sync causing "not trusted" pop ups for client
New workspace/window creates a different `WeakEntity<WorktreeStore>` for
the same path, which was not considered before.
Closes https://github.com/zed-industries/zed/issues/46318
Release Notes:
- Fixed worktree trust not applied in window reuse
Closes https://github.com/zed-industries/zed/issues/46590https://github.com/user-attachments/assets/8464a3b6-9258-4d15-9168-56178bf46437
`use smol::channel::{Receiver, Sender};` do not propagate the value
change to all receivers, hence only one language server received the
"worktree trusted" message.
The fix uses `watch` kind of channels instead, and cleans up its state
more eager to rely on the sender drop as another form of notification.
Release Notes:
- Fixed groups of language servers not starting after worktree trust
approval
## Motivation
This PR unifies the async execution infrastructure between GPUI and
other components that depend on the `scheduler` crate (such as our cloud
codebase). By having a scheduler that lives independently of GPUI, we
can enable deterministic testing across the entire stack - testing GPUI
applications alongside cloud services with a single, unified scheduler.
## Summary
This PR completes the integration of the `scheduler` crate into GPUI,
unifying async execution and enabling deterministic testing of GPUI
combined with other components that depend on the scheduler crate.
## Key Changes
### Scheduler Integration (Phases 1-5, previously completed)
- `TestDispatcher` now delegates to `TestScheduler` for timing, clock,
RNG, and task scheduling
- `PlatformScheduler` implements the `Scheduler` trait for production
use
- GPUI executors wrap scheduler executors, selecting `TestScheduler` or
`PlatformScheduler` based on environment
- Unified blocking logic via `Scheduler::block()`
### Dead Code Cleanup
- Deleted orphaned `crates/gpui/src/platform/platform_scheduler.rs`
(older incompatible version)
## Intentional Removals
### `spawn_labeled` and `deprioritize` removed
The `TaskLabel` system (`spawn_labeled`, `deprioritize`) was removed
during this integration. It was only used in a few places for test
ordering control.
cc @maxbrunsfeld @as-cii - The new priority-weighted scheduling in
`TestScheduler` provides similar functionality through
`Priority::High/Medium/Low`. If `deprioritize` is important for specific
test scenarios, we could add it back to the scheduler crate. Let me know
if this is blocking anything.
### `start_waiting` / `finish_waiting` debug methods removed
Replaced by `TracingWaker` in `TestScheduler` - run tests with
`PENDING_TRACES=1` to see backtraces of pending futures when parking is
forbidden.
### Realtime Priority removed
The realtime priority feature was unused in the codebase. I'd prefer to
reintroduce it when we have an actual use case, as the implementation
(bounded channel with capacity 1) could potentially block the main
thread. Having a real use case will help us validate the design.
## Testing
- All GPUI tests pass
- All scheduler tests pass
- Clippy clean
## Architecture
```
┌─────────────────────────────────────────────────────────────┐
│ GPUI │
│ ┌──────────────────────┐ ┌────────────────────────────┐ │
│ │ gpui::Background- │ │ gpui::ForegroundExecutor │ │
│ │ Executor │ │ - wraps scheduler:: │ │
│ │ - scheduler: Arc< │ │ ForegroundExecutor │ │
│ │ dyn Scheduler> │ └────────────┬───────────────┘ │
│ └──────────┬───────────┘ │ │
│ │ │ │
│ └──────────┬──────────────────┘ │
│ ▼ │
│ ┌───────────────────────┐ │
│ │ Arc<dyn Scheduler> │ │
│ └───────────┬───────────┘ │
│ ┌──────────────┴──────────────┐ │
│ ▼ ▼ │
│ ┌──────────────────┐ ┌────────────────────┐ │
│ │ PlatformScheduler│ │ TestScheduler │ │
│ │ (production) │ │ (deterministic) │ │
│ └──────────────────┘ └────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
```
Release Notes:
- N/A
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Co-authored-by: Yara <git@yara.blue>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
This happens when a user's default branch has different remote and local
versions on their system. Because we would get a diff using just a
branch name without including it's remote name as well
This is a better default because it's far less confusing from a user's
perspective to debug what's going on.
Release Notes:
- git: Fix BranchDiff showing incorrect diffs when default local branch
is out of sync with the remote default branch
Fixes#41220
Co-authored-by: dino <dinojoaocosta@gmail.com>
Closes#41220
Release Notes:
- Rust: Fixed diagnostics being stale when working across path
dependencies
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Right now agent extensions can specify icon paths that point anywhere.
This changes it so that they can only specify icon paths that are
subdirectories of the extension's root dir.
Release Notes:
- Restrict agent server extension icon paths to subdirectories of the
extension's root directory
Closes#45776
It didn't enable multiline mode before `¯\_(ツ)_/¯`. If there is a reason
this fix won't work please let me know but it seems like this one was
just an easy fix.
Release Notes:
- Improved multiline regex behavior
Also improves the commit view to use the same status-based buffer header
visual overrides as the project diff as a driveby.
Fixes https://github.com/zed-industries/zed/issues/45735
Release Notes:
- git: Binary files are no longer shown in garbled form when viewing an
old commit.
Per LSP spec, when receiving `workspace/diagnostic/refresh`, clients
should refresh all pulled diagnostics including both workspace and
document diagnostics[^1]. Previously, only workspace diagnostics were
refreshed.
[^1]:
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.18/specification/#diagnostic_refresh
This adds `pull_document_diagnostics_for_server()`, which refreshes
`textDocument/diagnostic` for all open buffers associated with the
given language server.
Closes #ISSUE
Release Notes:
- When handling `workspace/diagnostic/refresh`, Zed now also sends new
`textDocument/diagnostic` requests for open files, aligning with the LSP
specification.
---------
Co-authored-by: John Tur <john-tur@outlook.com>
Adds various useful things to the repl inspired by ipynb and the julia
vscode extension which can be best seen with this video:

https://github.com/user-attachments/assets/6589715e-3783-456c-8f4b-e2d5a1c4090d
To summarize:
## Inline outputs
Added small, single-line outputs displayed inline at the end of the code
line instead of in a separate block. This provides a cleaner, more
compact view for simple results like numbers or short strings. This
occurs for execution views who only output a single mimetype/plain OR
output nothing, otherwise the default behavior of creating a block will
occur.
It looks like this:
<img width="258" height="35" alt="image"
src="https://github.com/user-attachments/assets/ccdeca3f-c3b7-4387-a4de-53d8b9a25132"
/>
or with a Output
<img width="346" height="55" alt="image"
src="https://github.com/user-attachments/assets/0b4effc9-1bd7-4e8c-802f-8733cdcc77d1"
/>
This was inspired by julia vscode extension, but now it can be used with
any replanguage! Hooray!
<img width="524" height="450" alt="image"
src="https://github.com/user-attachments/assets/a3551e51-f5f7-4d3e-994a-213c9d2f948c"
/>
It saves lots of space compared to the ugly and distracting:
<img width="531" height="546" alt="image"
src="https://github.com/user-attachments/assets/7cf65bae-8ec1-4279-ab19-f0d4ec4052a2"
/>
## Gutters and execution numbers
Added gutters + execution number to display exactly what was executed.
The gutter highlighting is useful for when selecting multiple cells
manually to run, but you dont remember which ones
Ran at different times:
<img width="257" height="58" alt="image"
src="https://github.com/user-attachments/assets/6002ab16-156a-4598-9964-5a6b188e989c"
/>
Ran together:
<img width="306" height="64" alt="image"
src="https://github.com/user-attachments/assets/2690ea35-2bd3-4207-b039-6c0f98dad6e4"
/>
The execution number is useful in the same way that a normal jupyter
notebook execution number is useful.
If a gutter-region does not have a block assigned to it, when you edit
the text in the gutter region, the gutter will disappear, which is
useful for telling when you have modified your code, but does not delete
useful experiment results in blocks:
<img width="280" height="38" alt="image"
src="https://github.com/user-attachments/assets/d7f29224-87e4-4c14-8d9f-41cb10ab5009"
/>
<img width="254" height="31" alt="image"
src="https://github.com/user-attachments/assets/586c9e1d-f53c-4973-affb-c8ca05a7563b"
/>
<img width="264" height="29" alt="image"
src="https://github.com/user-attachments/assets/f306c364-1c92-44bd-9050-ecce1b7822a0"
/>
## Skip empty line
This is a minor fix which is intended to make lab workflow less tedious.
Currently when you execute on an empty line (which might be there for
formatting purposes) nothing will occur. This PR adds the ability to,
when executing from an empty line, skip ahead the range of inclusion
until you reach actual code, and then execute.
Before:
```
code //run execute
//empty space, so you have to move your cursor down or use arrow key
code //run execute
code //run execute
```
After:
```
code //run execute
//empty space, you can now run execute on it and it will include the next line of code
//empty space
code //automatically executed
code //run execute
```
Currently the only piece of tested code is related to this, i still have
to write tests for the gutter annotation api i added and all of the
gutter + inline related code. Also still have to add more config for
this stuff.
@rgbkrk would appreciate a review :D
Closes#22678
Release Notes:
- repl: Added an inline display of execution results (as opposed to the
large execution view) for simple REPL cells
- repl: Improved how execution of empty lines are handled
- repl: Added gutter execution display
Previously, `detail` was not included in resolvable properties, which
prevented LSP-compliant servers from lazily resolving it.
In relation to this, I also investigated vtsls issues:
- https://github.com/yioneko/vtsls/issues/213
- https://github.com/zed-industries/zed/pull/21521
My conclusion is that regardless of whether Zed registers `detail` in
resolvable properties, vtsls always lazily resolves `detail`. However, I
understand that Zed's `resolve_completions` has been improved to handle
such "misbehaving" servers gracefully already, so I expect that adding
`detail` to resolvable properties will not cause any issues.
In fact, since Zed can lazy update all properties of completion items,
it might be appropriate to include all properties as resolvable except
for `label` (which is explicitly tested for consistency) and `data`
(which is used for resolution itself once).
However, since I'm uncertain if this is entirely correct, this commit
only adds `detail` to resolvable properties, as it was required to be
supported by LSP clients up to version 3.16.
Closes #ISSUE
Release Notes:
- N/A
