Some refactoring I ran into while working on automatic Markdown list
continuation on newline.
This PR:
- Moves `comment_delimiter` and `documentation_delimiter` computation
outside of newline method.
- Adds `NewlineFormatting`, which holds info about how newlines affect
indentation and other formatting we need.
- Moves newline-specific methods into the new `NewlineFormatting`
struct.
Release Notes:
- N/A
Add support for `zed://git/commit/<path-to-repo>#<sha>` (**EDIT:** now
changed to `zed://git/commit/<sha>?repo=<path>`) URI scheme to access
the git commit view
implement parsing and handling of git commit URIs to navigate directly
to commit views from external links. the main use case for me is to use
OSC8 hyperlinks to link from a git sha into zed. this allows me e.g. to
easily navigate from a terminal into zed
**questions**
- is this URI scheme appropriate? it was the first one i thought of, but
wondering if `?ref=<some sha>` might make more sense – the git/commit
namespace was also an equally arbitrary choice
<details>
<summary>video demo showing navigation from zed's built in
terminal</summary>
https://github.com/user-attachments/assets/18ad7e64-6b39-44b2-a440-1a9eb71cd212
</details>
<details>
<summary>video demo showing navigation from ghostty to zed's commit
view</summary>
https://github.com/user-attachments/assets/1825e753-523f-4f98-b59c-7188ae2f5f19
</details>
Release Notes:
- Added support for `zed://git/commit/<sha>?repo=<path>` URI scheme to
access the git commit view
---------
Co-authored-by: Agus Zubiaga <agus@zed.dev>
Previously, the list of edit files had a double axis scroll issue
because the list itself scrolled vertically and each file row would
scroll horizontally, causing a bad UX. The horizontal scroll intention
was so that you could see the whole path, but I've included it in the
tooltip in case it becomes obscured due to a small panel width.
<img width="500" height="666" alt="Screenshot 2025-12-17 at 11 24@2x"
src="https://github.com/user-attachments/assets/ea87236d-f5c6-475a-bf66-1afae7a6ca05"
/>
Release Notes:
- agent: N/A
Fixes an issue where we would update the imports after a file rename in
TypeScript, but those changes wouldn't surface anywhere until those
buffers were manually opened
(https://github.com/zed-industries/zed/issues/35930#issuecomment-3366852945).
In https://github.com/zed-industries/zed/pull/36681 we already added
support for opening a multibuffer with edits, but vtsls has a different
flow for renames.
Release Notes:
- Files with updated imports now open in a multibuffer when renaming or
moving TypeScript or JavaScript files
Closes#35930
When a TypeScript file is renamed or moved, vtsls can automatically
update the imports in other files. It pops up a message with the option
to always automatically update imports. This choice would previously
only be remembered for the current session and would pop up again after
a restart.
Now we persist that choice to the vtsls LSP settings in Zed, so that it
remembers across editor sessions.
Release Notes:
- When renaming a TypeScript or JavaScript file, the selected option to
automatically update imports will now be remembered across editor
sessions.
Addresses some tasks in #43969. Namely adding TailwindCSS documentation
for the following languages: HTML, JavaScript and Typescript.
**Some Notes**
- Maybe the additional information in the HTML section is unnecessary,
unsure open to suggestions.
- I tried utilizing capturing groups with alternatives like
`\\.(add|remove|toggle|contains)` but this didn't seem to work, so I was
forced to use multiple lines.
Release Notes:
- N/A
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Relevant for Nightly Users only, follow up to #45004.
In case you use nightly this will break preview/stable since
deserialisation will fail. Shipping this to Nightly so that staff does
not run into this issue. We can revert this PR in the following days.
I'll make a follow up PR which only stores the prompt in the database in
case you customise it.
Release Notes:
- N/A
Reverts https://github.com/zed-industries/zed/pull/44933.
It turns out that if you're copying agent responses to paste it anywhere
else that isn't the message editor (e.g., for a follow up prompt),
getting Markdown formatting is helpful. However, with the revert, the
underlying issue in https://github.com/zed-industries/zed/issues/42958
remains, so I'll reopen that issue, unfortunately.
Release Notes:
- N/A
Closes#33018
### Problem
When opening a `PopoverMenu` or `RightClickMenu`, the pane's tab bar
buttons would flicker (disappear for a couple frames then reappear).
This happened because:
1. The menu is created and `window.focus()` was called immediately
2. However, menus are rendered using `deferred()`, so their focus
handles aren't connected in the dispatch tree until after the deferred
draw callback runs
3. When the pane checks `has_focus()`, it calls `contains_focused()`
which walks up the focus hierarchy — but the menu's focus handle isn't
linked yet
4. `has_focus()` returns false → tab bar buttons disappear
5. Next frame, the menu is rendered and linked → `has_focus()` returns
true → buttons reappear
### Solution
Delay the focus transfer by 2 frames using nested `on_next_frame()`
calls before focusing the menu.
**Why 2 frames instead of 1?**
The frame lifecycle in GPUI runs `next_frame_callbacks` BEFORE `draw()`:
```
on_request_frame:
1. Run next_frame_callbacks
2. window.draw() ← menu rendered here via deferred()
3. Present
```
So:
- **Frame 1**: First `on_next_frame` callback runs, queues second
callback. Then `draw()` renders the menu and connects its focus handle
to the dispatch tree.
- **Frame 2**: Second `on_next_frame` callback runs and focuses the
menu. Now the focus handle is connected (from Frame 1's draw), so
`contains_focused()` returns true.
With only 1 frame, the focus would happen BEFORE `draw()`, when the
menu's focus handle isn't connected yet.
This follows the same pattern established in b709996ec6 which fixed the
identical issue for the editor's `MouseContextMenu`.
Closes #ISSUE
This PR is rather a nice to have change than anything critical, so
review priority should remain low.
Switch to using `semver::Version` for representing node binary and npm
package versions. This is in an effort to root out implicit behavior and
improve type safety when interacting with the `node_runtime` crate by
catching invalid versions where they appear. Currently Zed may
implicitly assume the current version is correct, or always install the
newest version when a invalid version is passed. `semver::Version` also
doesn't require the heap, which is probably more of a fun fact than
anything useful.
`npm_install_packages` still takes versions as a `&str`, because
`latest` can be used to fetch the latest version on npm. This could
likely be made into an enum as well, but would make the PR even larger.
I tested changes with some node based language servers and external
agents, which all worked fine. It would be nice to have some e2e tests
for node. To be safe I'd put it on nightly after a Wednesday release.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes#44624
Before this change, white space would be trimmed from word diff ranges.
Users found this behavior confusing, so we're changing it to be more
inline with how GitHub treats whitespace in their word diffs.
Release Notes:
- git: Word diffs won't filter out pure whitespace diffs now
Both `test_miniquotes_object` and `test_minibrackets_object` rely on
tree-sitter parsing for `MultiBufferSnapshot.bracket_ranges` to find
quote/bracket pairs. The `VimTestContext.set_state` call eventually
triggers async tree-sitter parsing, but `run_until_parked` doesn't
guarantee parsing completion.
We suspect this is what might be causing the flakiness on Windows, as
the syntax might not yet be parsed when the
`VimTestContext.simulate_keystrokes` call is made, so there's no bracket
pairs returned.
This commit adds an explicit await call on `Bufffer.parsing_idle` after
each `VimTestContext.set_state` call, to ensure tree-sitter parsing
completes before simulating keystrokes.
Release Notes:
- N/A
Obviously this doesn't do too much without having an actual windows
server binary for the remote side, but it does at least improve the
error message as right now we will complain about `uname` not being a
valid powershell command.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes#45033
This bug happened because the deletion icon would use the selected entry
index to choose what branch to delete. This works for all cases except
when hovering on an entry, so the fix was passing in the entry index to
the deletion button on_click handler.
I also disabled the deletion button from working if a branch is HEAD,
because it's an illegal operation to delete a branch a user is currently
on.
Finally, I made WeakEntity<Workspace> a non-optional field on
`BranchList` because a workspace should always be present, and it's used
to show toast notifications when a git operation fails. The popover view
wouldn't have a workspace before, so users wouldn't get error messages
when a git operation failed in that view.
Release Notes:
- git: Fix bug where branch list deletion button would delete the wrong
branch
Closes#43722
Release Notes:
- Fixed an issue where auto-indentation didn’t work correctly for Python
code blocks in Markdown.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Fixes the hang introduced in #44995 (which was reverted in #45011) and
re-enables the optimization.
## Background
PR #44995 introduced an optimization to skip rendering lines that are
clipped by parent containers (e.g., when a large AutoHeight editor is
inside a scrollable List). This significantly improved performance for
large diffs in the Agent Panel.
However, #45011 reverted this change because it caused the main thread
to hang for 100+ seconds in certain scenarios, requiring a force quit to
recover.
## Root Cause
The original analysis in #45011 suggested that visible_bounds wasn’t
being intersected properly, but that was incorrect—the intersection via
with_content_mask works correctly. The actual bug: when an editor is
positioned above the visible viewport (e.g., scrolled past in a List),
the clipping calculation produces a start_row that exceeds max_row:
1. Editor’s bounds.origin.y becomes very negative (e.g., -10000px)
2. After intersection, visible_bounds.origin.y is at the viewport top
(e.g., 0)
3. clipped_top_in_lines = (0 - (-10000)) / line_height = huge number
4. start_row = huge number, but end_row is clamped to max_row
5. This creates an invalid range where start_row > end_row
This caused two different failures depending on build mode:
- Debug mode: Panic from subtraction overflow in
Range<DisplayRow>::len()
- Release mode: Integer wraparound causing blocks_in_range to enter an
infinite loop (the 100+ second hang)
## Fix
Simply clamp start_row to max_row, ensuring the row range is always
valid:
```rs
let start_row = cmp::min(
DisplayRow((scroll_position.y + clipped_top_in_lines).floor() as u32),
max_row,
);
```
## Testing
Added a regression test that draws an editor at y=-10000 to simulate an
editor that’s been scrolled past in a List. This would panic in debug
mode (and hang in release mode) before the fix.
Release Notes:
- Improved agent panel performance when rendering large diffs.
0.0.2 is not a pre-release artifact unlike the previous one, so our
version fetch ignored it.
Fixes https://github.com/zed-industries/zed/issues/45061
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Remove some intermediate allocations when reconstructing text or wrapped
text from a `TextLayout`. Currently creates a intermediate `Vec<String>`
which gets joined, when you could join an `impl Iterator<Item = &str>`
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes#20613
Release Notes:
- Fixed: New windows no longer flicker between "Open a file or project
to get started" and an empty editor.
---
When opening a new window (`cmd-shift-n`), the window rendered showing
the empty state message before the editor was created, causing a visible
flicker.
**Changes:**
- Modified `Workspace::new_local` to accept an optional `init` callback
that executes inside the window build closure
- The init callback runs within `cx.new` (the `build_root_view`
closure), before `window.draw()` is called for the first render
- Changed the NewWindow action handler to use
`Project::create_local_buffer()` (synchronous) instead of
`Editor::new_file()` (asynchronous)
- Updated `open_new` to pass the editor creation callback to `new_local`
- All other `new_local` call sites pass `None` to maintain existing
behavior
**Key Technical Detail:**
The window creation sequence in `cx.open_window()` is:
1. `build_root_view` closure is called (creates workspace via `cx.new`)
2. `window.draw(cx)` is called (first render)
3. `open_window` returns
The fix uses `Project::create_local_buffer()` which creates a buffer
**synchronously** (returns `Entity<Buffer>` directly), rather than
`Editor::new_file()` which is asynchronous (calls
`project.create_buffer()` which returns a `Task`). The editor is created
from this buffer inside the `cx.new` closure (step 1), ensuring it
exists before step 2 renders the first frame.
**Before:**
```rust
let task = Workspace::new_local(Vec::new(), app_state, None, env, cx);
cx.spawn(async move |cx| {
let (workspace, _) = task.await?; // Window already drawn
workspace.update(cx, |workspace, window, cx| {
Editor::new_file(workspace, ...) // Async - editor not present for first render
})?;
})
```
**After:**
```rust
cx.open_window(options, {
move |window, cx| {
cx.new(|cx| {
let mut workspace = Workspace::new(...);
// Create buffer synchronously, then create editor
if let Some(init) = init {
init(&mut workspace, window, cx); // Uses create_local_buffer (sync)
}
workspace
})
}
})?
```
The editor is now part of the workspace before the window's first frame
is rendered, eliminating the flicker.
<!-- START COPILOT ORIGINAL PROMPT -->
<details>
<summary>Original prompt</summary>
>
> ----
>
> *This section details on the original issue you should resolve*
>
> <issue_title>Opening a new window flickers before opening an empty
buffer</issue_title>
> <issue_description>### Check for existing issues
>
> - [x] Completed
>
> ### Describe the bug / provide steps to reproduce it
>
> Opening a new window, with e.g. `cmd-shift-n`, flickers for a fraction
of a second. The new window first shows the startup page, "Open a file
or project to get started.". Then, a frame or two later, a new empty
buffer opens.
>
> Not sure if I'm sensitive or something but these kinds of flashes can
knock me out of focus/flow pretty easily.
>
> It'd be great to either have the empty buffer open from the first
frame, or to have an option to simply not open that empty buffer when a
new window is opened.
>
> ### Zed Version and System Specs
>
> Zed: v0.170.4 (Zed)
> OS: macOS 14.6.1
> Memory: 36 GiB
> Architecture: aarch64
>
> ### If applicable, add screenshots or screencasts of the incorrect
state / behavior
>
>
https://github.com/user-attachments/assets/6d9ba791-8a02-4e13-857c-66a33eb0905b
>
> ### If applicable, attach your Zed.log file to this issue.
>
> N/A</issue_description>
>
> <agent_instructions>We should make sure that the window is created in
the correct state, and not have an intermediate render before the editor
opens.</agent_instructions>
>
> ## Comments on the Issue (you are @copilot in this section)
>
> <comments>
> <comment_new><author>@ConradIrwin</author><body>
> Ugh, no. I don't believe I never noticed this before, but now I can't
unsee it :s
>
> If you'd like to pair on this: https://cal.com/conradirwin/pairing,
otherwise I'll see if I get around to it.</body></comment_new>
> <comment_new><author>@ConradIrwin</author><body>
> Yeah... I wonder if that can be a preview tab or something. It's nice
when you want it, but not so nice when you don't.
>
> Fixing this will also make zed-industries/zed#33334 feel much
smoother.</body></comment_new>
> <comment_new><author>@zelenenka</author><body>
> @robinplace do you maybe have an opportunity to test it with the
latest stable version, 0.213.3?</body></comment_new>
> </comments>
>
</details>
<!-- START COPILOT CODING AGENT SUFFIX -->
- Fixeszed-industries/zed#23742
<!-- START COPILOT CODING AGENT TIPS -->
---
💡 You can make Copilot smarter by setting up custom instructions,
customizing its development environment and configuring Model Context
Protocol (MCP) servers. Learn more [Copilot coding agent
tips](https://gh.io/copilot-coding-agent-tips) in the docs.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: ConradIrwin <94272+ConradIrwin@users.noreply.github.com>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Split running `cargo clippy` out of the job that has access to ZIPPY
secrets as
a precaution against accidentally leaking the secrets through build.rs
or
something...
Release Notes:
- N/A
Follow-up of https://github.com/zed-industries/zed/pull/44887
This fixes remote server builds.
Additionally:
* slightly rewords workspace trust text in the security modal
* eagerly ask for worktree trust on open
Release Notes:
- N/A
This PR fixes the warning from entering the nix development shell:
```
evaluation warning: 'hostPlatform' has been renamed to/replaced by 'stdenv.hostPlatform'
```
Decided to go with `zed-editor = mkZed pkgs;` instead of `zed-editor =
packages.${pkgs.stdenv.hostPlatform.system}.default;`, because it is
simpler and with my understanding it is logically equivalent (i.e. we
are getting `packages.<system>.default` which we can see in the
definition of packages is equal to `mkZed pkgs;`).
Release Notes:
- N/A
Just touching up the tooltip casing, colors, and a bit of spacing. Also
added the keybiniding to close the assistant. Maybe it was obvious
already but I don't think it hurts.
Release Notes:
- N/A
## Summary
This PR adds support for the MCP (Model Context Protocol)
`notifications/tools/list_changed` notification, enabling dynamic tool
discovery when MCP servers add, remove, or modify their available tools
at runtime.
## Release Notes:
- Improved: MCP tools are now automatically reloaded when a context
server sends a `tools/list_changed` notification, eliminating the need
to restart the server to discover new tools.
## Changes
- Register a notification handler for `notifications/tools/list_changed`
in `ContextServerRegistry`
- Automatically reload tools when the notification is received
- Handler is registered both on initial server startup and when a server
transitions to `Running` status
## Motivation
The MCP specification includes a `notifications/tools/list_changed`
notification to inform clients when the list of available tools has
changed. Previously, Zed's agent would only load tools once when a
context server started. This meant that:
1. If an MCP server dynamically registered new tools after
initialization, they would not be available to the agent
2. The only way to refresh tools was to restart the entire context
server
3. Tools that were removed or modified would remain in the old state
until restart
## Implementation Details
The implementation follows these steps:
1. When a context server transitions to `Running` status, register a
notification handler for `notifications/tools/list_changed`
2. The handler captures a weak reference to the `ContextServerRegistry`
entity
3. When the notification is received, spawn a task that calls
`reload_tools_for_server` with the server ID
4. The existing `reload_tools_for_server` method handles fetching the
updated tool list and notifying observers
This approach is minimal and reuses existing tool-loading
infrastructure.
## Testing
- [x] Code compiles with `./script/clippy -p agent`
- The notification handler infrastructure already exists and is tested
in the codebase
- The `reload_tools_for_server` method is already tested and working
## Benefits
- Improves developer experience by enabling hot-reloading of MCP tools
- Aligns with the MCP specification's capability negotiation system
- No breaking changes to existing functionality
- Enables more flexible and dynamic MCP server implementations
## Related Issues
This implements part of the MCP specification that was already defined
in the type system but not wired up to actually handle the
notifications.
---------
Co-authored-by: Agus Zubiaga <agus@zed.dev>
Similar to how you can use `shift-tab` to cycle through profiles/modes,
you can now use `alt-tab` to cycle through the language models you have
favorited.
<img width="500" height="312" alt="Screenshot 2025-12-16 at 5 23@2x"
src="https://github.com/user-attachments/assets/006d417d-5da1-48f9-82cc-ea06e28adb30"
/>
Release Notes:
- agent: Added the ability to cycle through favorited models using the
`alt-tab` keybinding.
We need to prevent this, since commit message generation did not count
as a prompt in the old billing model.
If users of Legacy Zed Pro customise the prompt, it will count as an
actual prompt since our matching algorithm will fail.
We can remove this once we stop supporting Legacy Zed Pro on 17 January.
Release Notes:
- N/A
This PR solves my main pain point with Zed agent: I have a long list of
available models from different providers, and I switch between a few of
them depending on the context and the project. In particular, I use the
same models from different providers depending on whether I'm working on
a personal project or at my day job. Since I only care about a few
models (none of which are in "recommended") that are scattered all over
the list, switching between them is bothersome, even using search.
This change adds a new option in `settings.json`
(`agent.favorite_models`) and the UI to manipulate it directly from the
list of available models. When any models are marked as favorites, they
appear in a dedicated section at the very top of the list. Each model
has a small icon button that appears on hover and allows to toggle
whether it's marked as favorite.
I implemented this on the UI level (i.e. there's no first-party
knowledge about favorite models in the agent itself; in theory it could
return favorite models as a group but it would make it harder to
implement bespoke UI for the favorite models section and it also
wouldn't work for text threads which don't use the ACP infrastructure).
The feature is only enabled for the native agent but disabled for
external agents because we can't easily map their model IDs to settings
and there could be weird collisions between them.
https://github.com/user-attachments/assets/cf23afe4-3883-45cb-9906-f55de3ea2a97
Closes https://github.com/zed-industries/zed/issues/31507
Release Notes:
- Added the ability to mark language models as favorites and pin them to
the top of the list. This feature is available in the native Zed agent
(including text threads and the inline assistant), but not in external
agents via ACP.
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
`cargo-about` got pinned to 0.8.2 in
https://github.com/zed-industries/zed/pull/44012, but this isn't exactly
"easy" to accomplish in nix. The version of nixpkgs in the flake inputs
uses the proper version, but if you override the nixpkgs input or use
the provided overlay, you might end up trying to build with a bad
version of `cargo-about`.
Since nixpkgs is versioned as a whole, your options are (in rough order
of desirability):
1. Hope that nixpkgs simply includes multiple versions of the same
package (common for things with stable major versions/breaking changes)
1. Use either `override` or `overrideAttrs` to provide different
version/source attributes
1. Depend on multiple versions of nixpkgs to get the specific versions
of the packages you want
1. Vendor the whole package build from a specific point in its history
Option 1 is out - there's only one version of cargo-about in nixpkgs.
Option 2 doesn't seem to work due to the way that `buildRustPackage`
wraps the base `mkDerivation` which provides the `override` extension
functions. There *might* be a way to make this work, but I haven't dug
into the `buildRustPackage` internals enough to say for sure. Edit: I
apparently can't read and the problems with this option were already
solved for `cargo-bundle`, so this is the final approach!
Option 3 always just feels a bit icky and opaque to me.
Leaving Option 4. I usually find this approach to be "fine" for small
package definitions that aren't actually much bigger than the overridden
attributes would have be with the Option 2 approach. ~~Since the
`cargo-about` definition is nice and small, this is the approach I
chose.~~
~~Since this has the potential to require a build of `cargo-about`, I'm
only actually invoking its build if the provided version is wrong - more
or less the same thing that's happening in the `generate-licenses`
script, but nix-y.~~
Edit: Shouldn't ever cause a rebuild since there's only one 0.8.2 input
source/vendored deps, so anything that was already using it will already
be cached.
I'm also updating nixpkgs to the latest unstable which currently has
`cargo-about 0.8.4` to prove that this works.
Unrelatedly, I also ran `nix fmt` as a drive-by change. `nix/build.nix`
was a bit out of spec.
Release Notes:
- N/A
Closes#32951
## Summary
When an agent notification was shown and the `AcpThreadView` was dropped
(e.g., by closing the project window or navigating to a new thread), the
notification would become orphaned and undismissable because the
subscriptions handling dismiss events were dropped along with the thread
view.
## Fix
Added an `on_release` callback that closes all notification windows when
the thread view is dropped. This ensures notifications are always
cleaned up properly.
## Testing
Added `test_notification_closed_when_thread_view_dropped` to verify
notifications are closed when the thread view is dropped.
Release Notes:
- Fixed agent notification getting stuck and becoming undismissable when
the project window is closed or when navigating to a new thread
Smit Barmase