Candidate fix for #59822.
Adds a live preview pane to the project symbols picker, matching the
file finder and project search pickers. When the selection moves, the
selected symbol's file is shown in the preview with its declaration line
highlighted and vertically centered.
## Changes
- `project_symbols`: construct the picker with
`uniform_list_with_preview`; asynchronously open the buffer for the
selected symbol (cached by candidate id, cleared on each new query) and
implement `try_get_preview_data_for_match` to return the buffer plus the
symbol's anchor range.
- `picker`: add a public `refresh_preview` so a delegate can push
preview data once a buffer finishes opening asynchronously (the symbol
buffer is not available synchronously, unlike text search which already
holds open buffers).
#### Before
<img width="1725" height="712" alt="image"
src="https://github.com/user-attachments/assets/21dcd7d6-7cc4-4de8-ab7d-2f1ce143e814"
/>
##### After
<img width="1725" height="712" alt="image"
src="https://github.com/user-attachments/assets/db981db8-0a61-43bc-9838-c01b7bdbbf78"
/>
Can turn preview pane off by clicking at the bottom button!
## AI disclosure
AI was used for understanding the codebase and formatting this PR.
Release Notes:
- Added a preview pane to the project symbols picker
---------
Co-authored-by: Yara <git@yara.blue>
LiveKit Cloud rejects room-join tokens as revoked when their `nbf`
predates a participant revocation. Zed generated those LiveKit JWTs with
`nbf: 0`, so a fresh participant token minted after stale connection
cleanup could still appear older than the cleanup and leave a user
joined at the collab layer without audio or screen sharing. This sets
`nbf` to the issuance time for room-join tokens while leaving admin/API
tokens unchanged, and adds regression coverage at the token, mock
LiveKit, and channel rejoin layers.
Closes FR-83
Release Notes:
- Fixed calls getting stuck without audio or screen sharing after
restarting Zed and rejoining a channel.
# Objective
On a few occasions I have been wondering if the Zed update download had
stalled, when in fact it's just taking a while. This PR adds a progress
bar to the "Downloading Zed Update..." button to give users feedback
that the download is indeed progressing.
## Solution
Add a custom progress bar inside the button. I tried reusing the
existing ProgressBar component but that has a fixed height of 8px which
caused the button to become taller.
## Testing
- Tested manually using the command palette `collab: simulate update
available` and stepping through the different UI states.
- Added unit test
## 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 adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
<img width="1350" height="748" alt="Image 02-07-2026 at 17 23"
src="https://github.com/user-attachments/assets/ed23c97a-01b8-446b-9693-0c53a69b419d"
/>
Release Notes:
- Added a download progress indicator to the update button.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Adds a `zed: get merch` command palette action that opens
https://merch.zed.dev/ in the system browser.
Just thought it'd be fun!
Release Notes:
- Added a `zed: get merch` action that opens the Zed merch store.
StreamReader::poll_next dropped the reader it take()s whenever the read
returned Poll::Pending, so the next poll reported end-of-stream. And
poll_read_buf measured bytes via ReadBuf::filled(), which never advances
when the reader writes through initialize_unfilled(), so every read
counted as zero bytes. Together these made any AsyncBody::from_reader
request body (e.g. one backed by async_fs::File, which returns Pending
on its first read) upload as an empty or truncated body.
Keep the reader across Pending polls and use the byte count that
futures::AsyncRead::poll_read returns.
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
Co-authored-by: Marshall <marshall@zed.dev>
This reverts commit 2882636c06.
This was causing Zed to crash immediately on startup with the following
error:
```
thread 'main' (74835290) panicked at /Users/maxdeviant/.cargo/git/checkouts/reqwest-dc13ba947e7b959e/c156624/src/async_impl/body.rs:365:33:
there is no reactor running, must be called from the context of a Tokio 1.x runtime
```
Closes FR-118.
Release Notes:
- Reverted https://github.com/zed-industries/zed/pull/60301
# Objective
In the keymap editor, bindings whose `keymap.json` entries use a
deprecated action alias (e.g. `"editor::CopyRelativePath"` for
`workspace::CopyRelativePath`) could not be deleted or edited. Aliases
resolve to the canonical action on load, so the row displays normally,
but file updates searched for the canonical name and never matched the
alias entry. Deleting failed ("Failed to find keybinding to remove"),
and editing silently fell back to appending a new binding — leaving the
user with duplicate identical-looking rows they couldn't remove.
## Solution
- Thread gpui's deprecated-alias map
(`App::deprecated_actions_to_preferred_actions`) into
`KeymapFile::update_keybinding`, and resolve aliases in file entries
when matching bindings.
- As a side effect, editing an alias-based binding now rewrites the
entry with the canonical action name instead of duplicating it.
## Testing
- Unit tests in `settings` for removing and replacing alias-based
entries.
- End-to-end keymap editor tests (fake fs → keymap load → `KeymapEditor`
→ delete) covering both the alias case and plain duplicate bindings.
## 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 adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed the keymap editor failing to delete or edit key bindings whose
keymap file entries use deprecated action names
When Zed was downloading an update and the machine went to sleep, the
download would hang indefinitely on wake because the in-flight TCP
connection had silently died and nothing ever timed it out or retried.
This adds an inactivity `read_timeout` to the HTTP client so a stalled
response body errors out instead of hanging forever
(slow-but-progressing downloads are unaffected, since the timeout resets
on each chunk). It also promotes `App::on_system_wake` to a
multi-subscriber `Subscription` API and uses it in the auto-updater to
cancel an interrupted check/download on wake and start a fresh attempt.
## 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 adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fix hanging Zed update downloads after system sleep
Makes cmd-f work for terminal threads.
Since the agent panel is not part of the normal pane system we have to
manually hook up the search bar.
Closes#57309
Release Notes:
- agent: Added support for searching (cmd-f) inside of terminal threads
Summary
- Track whether a worktree root is itself a linked Git worktree.
- Use that metadata when computing project group keys so bare checkout
worktrees group under the repository identity path.
- Propagate the metadata through remote worktree protocols and add
local/remote regression coverage.
Background
Bare checkout layouts can place linked worktrees under the repository
identity directory, e.g. `/monty/.bare` with worktrees like
`/monty/feature-a`. We were treating those linked worktree paths as
separate project identities, which caused the sidebar to move agent
threads under the active worktree instead of the shared repository
group.
We also exclude adding this to collab intentionally, we can open a
different PR for that if we need to.
Closes#59910
Closes AI-431
Test Plan
- `cargo fmt --package project --package worktree --package
remote_server --package workspace --package collab --package proto`
- `git --no-pager diff --check`
- `cargo test -p project test_project_group_key -- --nocapture`
- `cargo test -p remote_server test_remote_root_repo_common_dir --
--nocapture`
- `cargo test -p worktree remote_worktree -- --nocapture`
- `cargo test -p workspace
test_remote_project_root_dir_changes_update_groups -- --nocapture`
- `cargo check -p collab`
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
Release Notes:
- Fixed agent thread/sidebar grouping for Git worktrees backed by bare
checkouts.
---------
Co-authored-by: Anthony Eid <anthony@zed.dev>
## Summary
On Windows, `trash::delete_with_info` can return an error even when the
file was successfully moved to the Recycle Bin.
This is caused by a race condition in the `trash` crate: after
`IFileOperation::PerformOperations` completes, it re-binds the trashed
item via `SHCreateItemFromParsingName` to read its metadata, but the
shell's virtual namespace cache may not yet reflect the new item,
producing an error. Previously, the delete loop propagated this error
and aborted the entire batch. The outer `detach_and_log_err` swallowed
the error, so the user received no feedback.
This PR handles each entry independently: entries that fail to delete
are skipped, the loop continues, and undo history is recorded for the
entries that succeeded.
The upstream root cause (the post-operation re-bind race in
`zed-industries/trash-rs`) will be addressed separately.
Before:
https://github.com/user-attachments/assets/59a95ac5-098b-42dc-bffb-f3240c6b966d
After:
https://github.com/user-attachments/assets/0cd6c0b3-2ee3-4bf2-a243-3e8a83d05dd7
## Test plan
- [ ] Select multiple files in the project panel on Windows
- [ ] Trash them (right-click > Move to Trash, or `Delete` key)
- [ ] Confirm all selected files are deleted, even if one triggers the
trash-crate race
- [ ] Undo restores the files that were successfully trashed
Release Notes:
- Improved handling of failed trash or delete operations in the Project
Panel in order to display a toast informing the user that some files
could not be trashed or deleted
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
## Why / What
Fixes#58702.
In Helix mode the block cursor is a one-character selection that can
rest on the
trailing newline at the end of a line. When you select to the end of a
line
(excluding the newline) and press `d`, Helix leaves the cursor on the
newline.
Zed instead clamped the cursor onto the character immediately to the
left of the
deleted selection.
The shared `visual_delete` always re-clipped the post-deletion cursor at
line
ends (`set_clip_at_line_ends(true)`), which is correct for Vim normal
mode but
contradicts Helix mode, where `Vim::clip_at_line_ends()` is `false`.
This also
made Helix inconsistent with itself: deleting a whole line left the
cursor on the
newline, but deleting to the end of a non-empty line clamped it onto the
previous
character. The fix honors the active mode's clip policy, so Helix keeps
the
cursor on the newline.
## Testing
- Added `test_delete_to_end_of_line_keeps_cursor_on_newline` reproducing
#58702.
- Corrected `test_helix_select_end_of_line`; its mid-line assertion had
captured
the pre-fix (clamped) cursor position. Its whole-line assertion already
expected the cursor on the newline, so the test is now internally
consistent.
- `cargo test -p vim`: 540 passed, 0 failed.
- Vim visual-mode delete is unchanged (`is_helix()` is false for Vim
modes).
Release Notes:
- Fixed Helix mode placing the cursor on the wrong character after
deleting a selection that ends at the end of a line.
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
## Context
The gutter hover button can represent either adding a breakpoint or
adding a bookmark depending on whether the secondary modifier is
pressed. Previously, the visible tooltip did not update when the
modifier changed while the popover was already open. This moves the
gutter hover intent into a shared state used by both the button and
tooltip, so the label, metadata, icon, color, click action, and
displayed keybinding all stay in sync.
Closes#58821
## How to Review
`crates/editor/src/editor.rs` adds a shared gutter hover intent type and
a custom tooltip view that reads the current modifier state while
rendering. Review that bookmark and breakpoint behavior map consistently
across the button icon/color, click action, tooltip label, metadata, and
keybinding.
`crates/editor/src/editor_tests.rs` adds a regression test covering the
tooltip intent selection with and without the secondary modifier.
Manual test after the fix below :
[Screencast from 2026-06-09
01-30-23.webm](https://github.com/user-attachments/assets/ef465eb9-e659-44da-93a6-a511c84e9401)
## Self-Review Checklist
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the UI/UX checklist
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed the breakpoint/bookmark gutter popover not updating when
modifier keys change.
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
This PR removes/simplifies some APIs that were leftover after moving the
agent settings from the agent panel into the agent settings UI.
Behavior/UI should be identical.
- Removed `ConfigurationViewTargetAgent` since only a single variant was
used
- Removed `configuration_view` and `configuration_view_v2` and replaced
it with `settings_view`
- Removed all the custom configuration views that were replaced by the
API key view abstraction
- Removed `intitial_title` and `initial_description` and moved it to
`ProviderSettingsView`
Release Notes:
- N/A
## Summary
Add a chevron (`Disclosure`) to each file group header in Text Finder,
letting you fold/unfold that file's matches. Fold state is cleared
whenever a new search starts.
## Test plan
- [x] Open Text Finder, run a search with matches in multiple files
- [x] Click a header's chevron, confirm its matches hide/show and
selection lands on a visible row
- [x] Start a new search, confirm folded state doesn't carry over
Release Notes:
- Added the ability to collapse per-file match groups in Text Finder
---------
Co-authored-by: ozacod <ozacod@users.noreply.github.com>
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Enable the command palette picker scrollbar while preserving the
one-shot reopen behavior.
---
Release Notes:
- N/A or Added/Fixed/Improved ...
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
To reproduce:
1. Open a git project with the agent sidebar, ideally with no other
threads in the sidebar.
2. Create a thread in a new git worktree and type into it without
sending.
3. While still in that worktree workspace, hit New Thread. The parked
draft must now be the last activatable entry in the sidebar.
4. Hover the parked draft → click Discard Draft
5. 💥
Release Notes:
- Fixed a panic when discarding a draft workspace.
In multi-buffer context, `do_completion` resolved the completion's
replace range anchors against whichever buffer currently held the newest
selection. If that selection had moved into a different file's excerpt
(while the menu remained open), the anchors belonged to a different
buffer and caused a panic.
This PR adds a guard to confirm the completion buffer and selection
buffer is the same.
Closes FR-76.
---
Release Notes:
- Fixed a panic that could occur when confirming a completion in a
multibuffer if the cursor had moved into a different file
# Objective
Fixes a crash when trashing a large number of untracked files from the
Git Panel, caused by unbounded OS thread spawning (thread explosion).
## Solution
`GitPanel::clean_all()` builds one deletion task per untracked file and
then awaits them one by one. Since GPUI tasks start executing as soon as
they are spawned, not when they are awaited, all deletions run
concurrently. Each of them called `RealFs::trash`, which spawned a
dedicated OS thread per call, so a large enough batch exceeded the OS
per-process thread limit and panicked at the `.expect("The os can spawn
threads")` in `RealFs::trash`.
This PR replaces the dedicated thread with `smol::unblock`, which runs
the blocking `trash::delete_with_info` call on a shared thread pool that
is capped and queues additional work instead of spawning more. This is
the same idiom already used elsewhere in the file (e.g. `atomic_write`)
for blocking filesystem work.
## Testing
- Did you test these changes? If so, how?
yes, reproduced using steps in the issue before and after and confirmed
fix works.
https://github.com/user-attachments/assets/d3bcd049-485a-486f-877a-0e5c21b7917c
Reproduction steps here:
https://github.com/zed-industries/zed/issues/60216
## 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 adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes#60216
---
Release Notes:
- Fixed a crash caused by spawning one thread per file when trashing a
large number of untracked files from the Git Panel.
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Closes#22490
## Summary
• Keep kill-ring state as a dedicated global structure (`text`,
`metadata`, `row`, `column`, `buffer_id`) instead of a raw clipboard
wrapper.
• Update `editor::KillRingCut` to append consecutive empty-line kills
only when all are true:
- one selection only
- previous selection was empty
- same row/column
- same buffer
• Preserve existing behavior for non-empty and multi-selection cuts by
replacing the ring payload instead of appending.
• Preserve yank metadata behavior through the existing clipboard
selection metadata path.
• Add regression coverage in
`editor_tests::test_kill_ring_cut_accumulates_multi_line_kills`.
## Verification
• `cargo fmt --all -- --check`
• `./script/check-keymaps`
• `./script/clippy -p editor`
• `cargo test -p editor -- --nocapture`
• `cargo test -p editor
editor_tests::test_kill_ring_cut_accumulates_multi_line_kills --
--exact`
• `cargo test -p editor test_cut_line_ends -- --exact`
## Manual
• `Ctrl+K`, `Ctrl+K`, `Ctrl+Y` with repeated line-end kills at same
caret location pastes concatenated text.
• Non-empty selection cut and multi-selection still replace as before
(no unintended append).
• Cut in one buffer then cut in another does not cross-append.
• Moving caret between kills does not append.
• Undo/redo around cut+yank path works cleanly.
Release Notes:
- Fixed Emacs-style kill-ring behavior so successive `KillRingCut`
operations at the same caret context are accumulated and pasted together
via one `KillRingYank`, while preserving existing non-empty selection
and multi-selection semantics.
---------
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
fixes#53726
Compute the base delta from the first visible, non-filtered row instead
of using rows.start. This avoids off-by-one numbering when rows.start is
a wrapped continuation that gets filtered out. Ensure deleted lines
still advance the relative counter even when they are not numbered. Add
a test for the wrapped scrolling case.
P.S. This is my first time using rust for a serious pull request and
let's say I'm a little bit rusty with it.
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 #ISSUE
Release Notes:
- N/A or Added/Fixed/Improved ...
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
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 adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
This PR makes two changes:
1. detect() now returns the line number of the first match instead of
just a boolean.
2. This line number (line_hint) is threaded through the pipeline and
passed as a subrange to query.search in full buffer scan, so the full
buffer scan starts from where the first match was already found instead
of the beginning of the file.
## Scope
- This optimization only applies to **local search** (not remote).
- It is only effective for **single-line text and single-line regex**
queries. For multiline queries, `detect()` returns `line_hint = 0`, so
the full buffer is scanned from the beginning as before.
- It does not apply to already-open buffers, which always receive
`line_hint = 0`.
## Test
i tried to search the word "typeably" in the file
"pkgs/development/haskell-modules/hackage-packages.nix" of the repo
[nixpkgs](https://github.com/NixOS/nixpkgs) given in the comment:
[comment](https://github.com/zed-industries/zed/issues/38799#issuecomment-4088491295).
Result seems promising:
**with line_hint:
search: 45.21ms**
**without line_hint:
search: 508.05ms**
I measured the time within the function: "handle_find_all_matches"
## Assumption
The core assumption is: if the search query is long enough (after 4 or 5
chars), the probability of finding multiple matches in a single file is
low. In that case, re-scanning the content before line_hint is
unnecessary — detect() function already confirmed there is no match
there.
Changes maybe can make an improvement on issues #38799 and #58905
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Automates the Guild contributor program on project board #74 so the
cohort is recognized and kept unblocked without manual babysitting.
- Move a board issue to In Progress when a Guild member self-assigns it,
and post a friendly heads-up when they are assigned an issue that is not
on the board.
- Flag when a Guild member opens a new PR while another of theirs is
still open, to help them land work before spreading thin.
- Check in on quiet assignments and, if an assignee stays silent, free
the issue back to a to-do column so others can pick it up; a "guild
hold" label lets maintainers pause check-ins after they have followed
up.
- Share a weekly digest of what the Guild shipped.
- Label PRs from Guild members and recognize a Guild contributor tier on
the community PR board.
Release Notes:
- N/A
# Objective
Microsoft has decoupled the MSVC version from the Visual Studio version
starting with Visual Studio 2026 (see [this
blog](https://devblogs.microsoft.com/cppblog/new-release-cadence-and-support-lifecycle-for-msvc-build-tools/)),
meaning that the previous traditional naming conventions were obsolete.
For Visual Studio 2026 (including future newer versions of VS) users,
the existing docs will probably confuse them, as they cannot find out
the components named like "MSVC v145 - VS 2026 C++ ..." in present
Visual Studio Installer.
## Solution
Add a note next to the dependencies.
## Testing
Docs are no need to test. (Maybe?)
## 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 adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
## Objective
While profiling https://github.com/zed-industries/zed/issues/60102 I
noticed `GitStore::update_repositories_from_worktree` does unneeded
work. It fires on every `WorktreeUpdatedGitRepositories` event, which
under filesystem pressure (`rescan: user dropped`) repeats roughly once
per second and can fire more frequently in a large monorepo with many
repositories, since the redundant work scales with the number of
repositories.
## Solution
In `crates/project/src/git_store.rs`:
- Drop the per-iteration `Arc<Path>` clone in the repo lookup; compare
the borrowed reference instead.
- Hoist the `is_trusted` (`can_trust`) computation out of the loop since
it only depends on `worktree_id`.
No behavior change is intended; this is purely reducing redundant work
per event.
## Notes
The *frequency* of these events originates upstream in
`LocalWorktree::changed_repos` (`crates/worktree/src/worktree.rs`),
which re-emits an `UpdatedGitRepository` whenever `git_dir_scan_id`
changes on a full rescan. That path is intentionally left untouched here
since it involves scan semantics; this PR only addresses the redundant
work on the consumer side.
## 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 adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- N/A
# Objective
Make images nested inside markdown links (e.g., README badges)
clickable, so they behave like normal markdown links.
Previously, linked images rendered correctly but were not interactive in
markdown previews: they did not show a pointer cursor, could not be
clicked to open their target URL, and did not expose link actions
through the context menu.
## Solution
Changed the `MarkdownElement` to detect when an `<img>` tag is inside a
`<a>` tag during rendering. When a linked image is rendered:
- The wrapper `div` gets a `cursor_pointer` style and an `on_click`
handler that opens the link URL (or delegates to the `on_url_click`
callback if set).
- The wrapper also captures right-click events to populate the context
menu with "Copy Link" via `capture_for_context_menu`.
- The `on_url_click` closure type was changed from `Box<dyn Fn>` to
`Rc<dyn Fn>` to allow cloning across multiple handlers.
- When a linked image fails to load, the fallback element's `on_click`
now calls `cx.stop_propagation()` to prevent the event from bubbling to
the parent link wrapper and opening the URL twice.
The feature is gated behind `!self.style.prevent_mouse_interaction` so
it respects existing interaction-prevention settings.
## Testing
- `cargo test -p markdown`: 95 tests passed.
- Manually verified in markdown preview that badge/image links open
correctly and right-click shows "Copy Link".
- Verified existing markdown tests continue to pass.
## 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 adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed images inside markdown links not being clickable.
https://github.com/user-attachments/assets/df2a8d8f-b002-47f9-b139-815ee713700b
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
This PR makes the `markdown_preview_font_size` setting be based on the
UI font size instead of the buffer UI font size. I typically use a much
smaller code font than UI font, and that made reading the markdown
preview super small. I don't think this will be uncommon because the
dimensions between mono and non-mono typefaces are different...
Release Notes:
- Changed the markdown preview to fall back to the UI font size instead
of the buffer font size when `markdown_preview_font_size` is unset.
WSL downloads a linux zed binary for the sandbox helper. But the flag is
set on the `zed-editor` binary, not the `zed` cli binary. This fixes
that
---
Release Notes:
- N/A or Added/Fixed/Improved ...
## Summary
When formatting specific ranges (e.g. via Format Selections), trailing
whitespace removal and final newline enforcement currently operate on
the entire file. This PR makes these operations range-aware, so they
only affect lines within the target ranges.
As noted in #16509, users want `remove_trailing_whitespace_on_save` and
`ensure_final_newline_on_save` to suppress jitter by only touching
changed lines. This PR provides the foundational infrastructure for that
— range-based whitespace and newline operations — which a follow-up PR
will wire into the `format_on_save` modifications mode.
## Changes
- Added `remove_trailing_whitespace_in_ranges` and
`ensure_final_newline_in_range` to `Buffer`
- When a `FormattableBuffer` has ranges set, whitespace and newline
operations now use the range-based variants
- `format_ranges_via_lsp` returns `Ok(None)` instead of an error when
the LSP doesn't support range formatting
- Extracted `anchor_ranges_to_row_ranges` helper to deduplicate
conversion logic
<details><summary>Tests (4)</summary>
- `test_trailing_whitespace_in_ranges` — only modified lines have
whitespace removed
- `test_trailing_whitespace_empty_ranges` — empty ranges → no changes
- `test_final_newline_modified_last_line` — newline added when last line
is in range
- `test_final_newline_unmodified_last_line` — newline not added when
last line is outside range
</details>
---
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:
- Improved Format Selection to scope trailing whitespace removal and
final newline enforcement to the selected range instead of the entire
file
- Improved handling of LSP servers that do not support range formatting
by gracefully skipping instead of producing an error
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Closes#50210
Bracket colorization currently runs theme accents through
`ensure_minimum_contrast`, which can significantly alter authored
palette colors in order to satisfy a single foreground-vs-background
target. In practice, that makes rainbow brackets drift away from the
theme colors they are supposed to reflect.
This PR keeps bracket colorization as a single automatic behavior, but
changes how the palette is derived:
- preserve authored accent colors when they already work
- adjust only the specific accents that are too weak against the editor
background
- only reorder the palette when adjacent bracket levels are still too
similar after that
The implementation is staged because bracket colorization has to handle
two separate problems:
- **Bracket-vs-Background Readability**: is an individual bracket
visible against the editor background?
- **Adjacent Bracket Separation**: can you still distinguish one nesting
level from the next?
Those two constraints are also why the implementation cannot simply
defer to whatever accent colors the theme provides. Some themes,
including the bundled One and Ayu, do not define explicit accents at
all, so bracket colorization falls back to Zed's shared default accent
palette. That palette was not designed with any particular theme's
background in mind, which makes the background contrast check especially
important for those cases.
That is why the previous `ensure_minimum_contrast(..., 55.0)` path is
not enough on its own. It addresses foreground-vs-background
readability, but if lightness-only adjustment cannot satisfy that target
it escalates to saturation reduction and then black/white fallback.
This PR instead keeps the bracket-specific background fix bounded and
lightness-only in OKLCH, so the resulting color stays much closer to the
authored accent.
### How it works
- **Background Contrast Correction**: accents that fall below the APCA
floor against the editor background are adjusted by changing OKLCH
lightness only, preserving hue and chroma
- **Adjacency Correction**: if the resulting palette is still too weak
between neighboring nesting levels, the palette is reordered
conservatively to improve adjacent separation
That ordering matters. Doing the reorder first can easily be undone by
the background-fix step.
### Color measurement
- background contrast uses APCA, via the existing `apca_contrast` path
- adjacent bracket separation uses OKLab Euclidean distance
APCA is the right tool for bracket-vs-background readability, but it is
not designed to compare two foreground colors against each other. OKLab
distance is a better fit for detecting when neighboring bracket levels
are perceptually too close.
### Thresholds
- background APCA floor: `30` on dark themes, `35` on light themes
- adjacent OKLab target: `0.08` on dark themes, `0.10` on light themes
- light-theme reorder tolerance band: reorder only triggers below
`0.095`, avoiding threshold-artifact reordering on palettes that are
visually fine but narrowly miss `0.10`
### Validation
- `cargo test -p editor bracket_colorization`
- manual comparison on bundled One, Ayu, and Gruvbox theme families
Release Notes:
- Improved bracket colorization by preserving theme accent colors when
possible and applying targeted contrast fixes only when needed.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Closes AI-432
The turn-end action buttons in the agent panel (scroll to top, scroll to
most recent prompt, open as markdown, thumbs up/down, share/sync) are
now exposed as local slash commands in the message editor instead of
buttons rendered at the end of each turn. The actions themselves are
unchanged — this is just a different way to access them.
Release Notes:
- Changed some of the agent panel's turn-end action buttons into slash
commands in the message editor.
---------
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
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)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
When files are dragged into the terminal, paths were formatted using
Rust's Debug format (`{path:?}`), which wraps them in double quotes.
This caused issues with programs like Claude Code that parse bare paths
from terminal input — quoted paths were treated as plain text instead of
file references.
This change replaces double-quote wrapping with backslash escaping for
special shell characters on Unix, which is both valid shell syntax and
compatible with path-parsing tools running in the terminal. On non-Unix
platforms the previous behavior is preserved.
Tested on macOS only. Unable to verify Windows behavior.
Fixes#57471
Release Notes:
- Fixed/ file drag-and-drop into terminal inserting double-quoted paths,
which prevented tools like Claude Code from recognizing them as file
references.
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
# Objective
Zed uses `pet` to auto-discover Python virtual environments. When
opening Python projects, there is a large amount of log spam from `pet`
output, which is not useful:
```
2026-07-01T22:32:07+08:00 INFO [pet::find] find_and_report_envs; search_scope=None
2026-07-01T22:32:07+08:00 INFO [lsp] starting language server process. binary path: "/usr/bin/ty", working directory: "/home/xin/works/test/test_python", args: ["server"]
2026-07-01T22:32:07+08:00 INFO [pet::find] locators_phase;
2026-07-01T22:32:07+08:00 INFO [pet::find] path_search_phase;
2026-07-01T22:32:07+08:00 INFO [pet::find] locator_find; locator=PipEnv
2026-07-01T22:32:07+08:00 INFO [pet::find] workspace_search_phase;
2026-07-01T22:32:07+08:00 INFO [pet::find] locator_find; locator=PyEnv
2026-07-01T22:32:07+08:00 INFO [pet::find] locator_find; locator=Pixi
2026-07-01T22:32:07+08:00 INFO [pet::find] locator_find; locator=Conda
2026-07-01T22:32:07+08:00 INFO [pet::find] locator_find; locator=Uv
2026-07-01T22:32:07+08:00 INFO [pet::find] locator_find; locator=Poetry
2026-07-01T22:32:07+08:00 INFO [pet::find] global_virtualenvs_phase;
2026-07-01T22:32:07+08:00 INFO [pet::find] locator_find; locator=Venv
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=[] executable_count=0
2026-07-01T22:32:07+08:00 INFO [pet::find] locator_find; locator=VirtualEnv
2026-07-01T22:32:07+08:00 INFO [pet::find] find_python_environments_in_workspace_folder_recursive; workspace_folder="/home/xin/works/test/test_python" workspace=/home/xin/works/test/test_python
2026-07-01T22:32:07+08:00 INFO [pet::find] locator_find; locator=Homebrew
2026-07-01T22:32:07+08:00 INFO [lsp] starting language server process. binary path: "/usr/bin/ruff", working directory: "/home/xin/works/test/test_python", args: ["server"]
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=[] executable_count=0
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=[] executable_count=0
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=[] executable_count=0
2026-07-01T22:32:07+08:00 INFO [pet::find] locator_find; locator=LinuxGlobal
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=[] executable_count=0
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=[] executable_count=0
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=[] executable_count=0
2026-07-01T22:32:07+08:00 INFO [pet::find] locator_find; locator=VirtualEnvWrapper
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=[] executable_count=0
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=["/home/xin/works/test/test_python/.venv/bin/python"] executable_count=1
2026-07-01T22:32:07+08:00 INFO [pet::locators] identify_python_environment_using_locators; env=PythonEnv { executable: "/home/xin/works/test/test_python/.venv/bin/python", prefix: Some("/home/xin/works/test/test_python/.venv"), version: None, symlinks: None } executable=/home/xin/works/test/test_python/.venv/bin/python
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=PyEnv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Pixi
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Conda
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Uv
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=[] executable_count=0
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=[] executable_count=0
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=[] executable_count=0
2026-07-01T22:32:07+08:00 INFO [pet::find] identify_python_executables_using_locators; executables=["/usr/bin/python", "/usr/bin/python3", "/usr/bin/python3.14"] executable_count=3
2026-07-01T22:32:07+08:00 INFO [pet::locators] identify_python_environment_using_locators; env=PythonEnv { executable: "/usr/bin/python", prefix: None, version: None, symlinks: None } executable=/usr/bin/python
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=PyEnv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Pixi
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Conda
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Uv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Poetry
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=PipEnv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=VirtualEnvWrapper
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Venv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=VirtualEnv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Homebrew
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=LinuxGlobal
2026-07-01T22:32:07+08:00 INFO [pet::locators] resolve_python_env; executable=/usr/bin/python
2026-07-01T22:32:07+08:00 INFO [pet::locators] identify_python_environment_using_locators; env=PythonEnv { executable: "/usr/bin/python3", prefix: None, version: None, symlinks: None } executable=/usr/bin/python3
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=PyEnv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Pixi
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Conda
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Uv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Poetry
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=PipEnv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=VirtualEnvWrapper
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Venv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=VirtualEnv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Homebrew
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=LinuxGlobal
2026-07-01T22:32:07+08:00 INFO [pet::locators] resolve_python_env; executable=/usr/bin/python3
2026-07-01T22:32:07+08:00 INFO [pet::locators] identify_python_environment_using_locators; env=PythonEnv { executable: "/usr/bin/python3.14", prefix: None, version: None, symlinks: None } executable=/usr/bin/python3.14
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=PyEnv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Pixi
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Conda
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Uv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Poetry
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=PipEnv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=VirtualEnvWrapper
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Venv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=VirtualEnv
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=Homebrew
2026-07-01T22:32:07+08:00 INFO [pet::locators] try_from_locator; locator=LinuxGlobal
2026-07-01T22:32:07+08:00 INFO [pet::locators] resolve_python_env; executable=/usr/bin/python3.14
```
This PR is intended to remove this log spam.
## Solution
Add `pet` to the default log filters. Now, `INFO` logs from `pet` are
suppressed by default.
## Testing
Tested locally, and verified that there is no longer any `pet` log spam
in the Zed logs.
## 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 adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- N/A or Added/Fixed/Improved ...
Removes git sandbox feature
The reason is essentially:
- write access to a `.git` dir can be trivially escalated to unsandboxed
access
- therefore, it is misleading to offer git access separate from
unsandboxed access
- instead, we encourage the model to use `--no-optional-locks` to avoid
needing write access to `git status`, etc.
Adds sandboxing to fetch tool
---
Release Notes:
- N/A or Added/Fixed/Improved ...
---------
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments N/A
- [x] 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
- [x] Performance impact has been considered and is acceptable
Remote `HEAD` refs such as `origin/HEAD` and `upstream/HEAD` are
symbolic refs that point to a remote's default branch. These refs can
appear in the branch picker, but selecting them shows this error prompt:
This happens because the local branch name is directly derived from the
selected ref, resulting in an attempted checkout of a local branch named
`HEAD`.
This change follows up on feedback from #57588, which just filtered
remote `HEAD` refs out of the branch picker to prevent the error prompt.
As mentioned in [this
comment](https://github.com/zed-industries/zed/pull/57588#issuecomment-4533477336),
I agree that the preferred behaviour should be to instead allow checking
them out - useful for repos with multiple remotes such as an upstream.
For example, if `refs/remotes/origin/HEAD` points to
`refs/remotes/origin/main`, selecting `origin/HEAD` now behaves like
selecting `origin/main`, switching to the corresponding local `main`
branch instead of trying to create or check out a branch named `HEAD`.
This does not fetch or pull from the remote; it uses the locally known
remote refs.
Release Notes:
- Fixed selecting remote HEAD refs from the branch picker
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
