# Objective
Unify dependencies inside of the root `Cargo.toml` to prevent versions
from going out of sync and creating copies of dependencies.
## Testing
- All tests pass, nothing touches the `Cargo.lock`
## Review
Review is easiest by going through commit by commit.
Release Notes:
- N/A or Added/Fixed/Improved ...
Fixes what https://github.com/zed-industries/zed/pull/57748 does for
buffer search.
When project search is deployed with regex mode enabled and the query is
seeded from the editor's selection or the word under the cursor, that
text is literal, so regex chars in it (e.g. `.` in `z.d`) are now
escaped instead of being interpreted as regex syntax. This follows how
VSCode handles it.
Release Notes:
- Fixed project search queries seeded from the current selection being
interpreted as a regular expression instead of literal text when regex
mode was enabled.
# Objective
Fixes#44529
## Solution
Earlier, the container holding the right side of the title bar applied a
conditional right padding depending on the whether the user was signed
in or not. This PR removes the conditional padding and replaces it with
a constant.
## Testing
The changes where visually verified by replicating the issue and seeing
if the fix works.
## 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
## Showcase
[](https://github.com/user-attachments/assets/017099c3-224e-4e32-9f28-66961e244d1b)
---
## Release Notes:
Fixed drop down arrow shifting upon logging in.
with `hard_tabs: true` and `tab_size: 4`, shift-alt-down off a
tab-aligned column drops the cursor in the wrong spot:
```
current.rgb.r ˇ= p[0] >> 8; <- cursor here
residuals[run].rˇgb.r = p[0] & 0xff; <- lands here, not on the =
```
both `=` render at column 48 but sit at buffer columns 22 and 27, since
a different number of tabs pads each row. shift-alt-down is
`skip_soft_wrap: true`, which placed the cursor by utf16 column where a
tab counts as one.
so count the column with tabs expanded instead. still a column and not a
pixel position, so the buffer-column behaviour
`test_add_selection_skip_soft_wrap_option` pins doesn't change (without
tabs the expanded column *is* the buffer column). tried pixels first and
it breaks that test, since x is measured inside a wrapped segment.
heads up that the existing tests here all pass `Default::default()`,
which is `skip_soft_wrap: false` (the `default_true` only applies to
deserializing), so nothing covered the branch the keybinding actually
uses.
Closes#60752.
Release Notes:
- Fixed added cursors landing in the wrong column when using tabs to
align code
Closes#34698
The buffer search query input is itself an editor, so dispatching
`editor::ToggleSoftWrap` from the command palette while the search bar
had focus toggled soft wrap on the single-line query editor (with no
visible effect) and never reached the searched editor.
This intercepts the action on the search bar in the capture phase and
applies it to the active searchable item, the same way `ToggleFoldAll`
is already relayed. Focus stays in the search bar, so you can keep
typing your query. `Editor::toggle_soft_wrap` and
`Editor::soft_wrap_mode` become `pub` (matching
`fold_all`/`has_any_buffer_folded`, which the existing `ToggleFoldAll`
relay already uses).
Includes a regression test that fails without the fix: it deploys the
search bar, dispatches `ToggleSoftWrap` with the query editor focused,
and asserts the searched editor's wrap mode changes while focus remains
in the search bar.
Release Notes:
- Fixed `editor: toggle soft wrap` doing nothing when invoked while the
buffer search bar was focused
---------
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
Adds a title_bar.show_worktree_name setting (default: true) that hides
the worktree picker button in the title bar, mirroring how
show_branch_name gates the branch picker. The "/" separator only renders
when both buttons are visible, and the container is omitted entirely
when both are hidden.
The setting is hide-only: it deliberately does not join the
render_project_items gate, so configurations with show_branch_name and
show_project_items both disabled keep hiding the whole group as before.
Requested in discussion
[zed-industries/zed#54902](https://github.com/zed-industries/zed/discussions/54902).
# Objective
The worktree name is always present in the title bar even when unused.
Unlike the branch name it has no dedicated option to disable it.
Requested in discussion
[zed-industries/zed#54902](https://github.com/zed-industries/zed/discussions/54902).
## Solution
Adds a `title_bar.show_worktree_name` setting (default: true) that hides
the worktree picker button in the title bar, mirroring how
show_branch_name gates the branch picker. The "/" separator only renders
when both buttons are visible, and the container is omitted entirely
when both are hidden.
The setting is hide-only: it deliberately does not join the
render_project_items gate, so configurations with show_branch_name and
show_project_items both disabled keep hiding the whole group as before.
## Testing
I tested the setting added by running the application by adding,
removing and toggling the `title_bar.show_worktree_name` setting in the
`settings.json`
## 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 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
- [ ] Performance impact has been considered and is acceptable
## Showcase
<img width="1496" height="982" alt="title_bar.show_worktree_name =
false"
src="https://github.com/user-attachments/assets/b2c502de-a8d8-4409-ba04-5ab807c77a8e"
/>
<img width="1496" height="982" alt="title_bar.show_worktree_name = true"
src="https://github.com/user-attachments/assets/6cea7eb5-0e88-454c-9c97-3b4ad62aed51"
/>
---
Release Notes:
- title_bar: Added title_bar.show_worktree_name (default: true) to hide
worktree picker button
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
This PR fixes the telemetry documentation to reference the `CrashInfo`
struct in `crates/crashes/src/crashes.rs`, since the `Panic` struct was
removed from `telemetry_events.rs` in #42931 after crash metadata moved
to the minidump path in #36267.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Fixes#59576
- N/A
on linux with the emacs keymap, holding `ctrl-n` at the end of the
buffer opens a new file every press. `ctrl-p` at the top opens the file
finder.
the keymap already tries `"ctrl-n": null`, but `null` only breaks
resolution in a *user* keymap, so from a base keymap
`workspace::NewFile` still resolves. a targeted unbind works regardless
of source:
```json
"ctrl-p": ["zed::Unbind", "file_finder::Toggle"],
"ctrl-n": ["zed::Unbind", "workspace::NewFile"],
```
left the MoveDown/MoveUp propagation alone, it's load bearing (agent
panel uses it for up-to-edit-last-message). tests cover the fix plus the
narrower ctrl-n/ctrl-p bindings still winning, since the unbind only
targets the one action.
ctrl-g/ctrl-x in that block are still null and probably just as broken,
but ctrl-x is a prefix key so i left them.
Closes#45010.
Release Notes:
- Fixed `ctrl-n` opening a new file and `ctrl-p` opening the file finder
at the ends of a buffer when using the Emacs keymap on Linux
# Objective
- Make runnable task results visible directly in the editor gutter after
running a test or task.
- This makes it easier to see whether the last run passed or failed
without looking at the terminal output.
## Solution
- Track the completion result for scheduled runnable tasks.
- Show the last runnable result in the gutter:
- running task: accent play icon
- successful task: success check icon
- failed/cancelled task: error icon
- Apply the same status update path when running from the gutter play
button and from inline code lens actions such as `Run Test`.
## Testing
- Ran `cargo check -p editor -p workspace`.
- Ran `cargo test -p workspace
test_schedule_resolved_task_with_completion_reports_success`.
- Manually tested running a GPUI test from the gutter play button.
- Manually tested running a GPUI test from the inline `Run Test` code
lens.
- Verified the gutter icon updates after completion in both cases.
## 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
Before:
<img width="1897" height="691" alt="before"
src="https://github.com/user-attachments/assets/614c2811-ee0a-43c0-8619-d0301836aa62"
/>
After:
<img width="1897" height="691" alt="after"
src="https://github.com/user-attachments/assets/a3db19f2-71e6-4c9b-824d-43a4f020a6b7"
/>
---
Release Notes:
- Improved runnable tasks by showing the last run result in the editor
gutter.
## Objective
Prevent a use-after-free when a macOS pasteboard wrapper outlives the
autorelease pool in which it was created.
Pasteboard cached its NSPasteboard and custom zed-text-hash and
zed-metadata NSString objects as raw ids. These constructors return
autoreleased objects. A later clipboard read could therefore pass a
dangling type identifier to dataForType and crash in objc_msgSend.
## Solution
- Retain the pasteboard and custom type objects for the Pasteboard
lifetime with StrongPtr.
- Copy NSData contents into owned Rust byte buffers before the
autoreleased data object can expire.
- Add a regression test that drains the creation autorelease pool and
then accesses the retained custom types.
## Testing
- cargo test -p gpui_macos --features runtime_shaders
test_custom_types_survive_creation_autorelease_pool --lib
- Built an optimized macOS embedder against the patched GPUI checkout.
## Self-Review Checklist:
- [x] I have reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks have justifying comments
- [x] The content adheres to Zed UI and icon standards; this change has
no UI
- [x] Tests cover the changed lifetime behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed a macOS crash that could occur when reading from the clipboard.
---
AI Disclosure: I ran into this bug on a project where I'm using GPUI.
For my purposes I patched it on my fork I maintain. I had codex (gpt
5.6-sol) send this PR because I think this fix should be upstreamed.
# Objective
Make solo diff views show the full file by default while preserving an
easy way to focus on changed hunks. This addresses a recurring request
across issues and pull requests for full-file context in single-file Git
diffs.
## Solution
- Initialize the solo diff with a singleton multibuffer so the entire
file is visible on open.
- Keep the existing toolbar toggle available for switching to
changes-only excerpts.
- Use the singleton path key when replacing excerpts so toggling remains
reliable.
- Preserve Git change indicators in the scrollbar; the editor generates
those markers for singleton buffers.
## Testing
- Ran `cargo fmt -p git_ui`.
- Ran `git diff --check`.
- Ran `cargo check -p git_ui --no-default-features` successfully.
- Manually reviewed the full-file and changes-only state transitions in
`SoloDiffView`.
## 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
Before, solo diffs opened with only changed hunks and surrounding
context. They now open with the complete file, retain Git change
indicators in the scrollbar, and can still be toggled to changes-only
from the toolbar.
---
Release Notes:
- Improved solo diffs to show the full file by default while retaining
Git change indicators in the scrollbar.
Follow up to https://github.com/zed-industries/zed/pull/61245. That PR
introduced a bug where the thread controls would appear at seemingly
random tool boundaries as opposed to only at the end of each turn. It
caused this sort of behavior, where we'd have many instances of those
buttons showing up:
<img width="500" alt="Screenshot 2026-07-20 at 4 03 2@2x"
src="https://github.com/user-attachments/assets/6e6f716e-adb5-4532-9f89-e955398cda23"
/>
Alongside with fixing it, this PR is also making the "scroll to top"
only show up only at the very last turn. I think that makes more sense
given you'd be most likely interested to go to the top when you're at
the bottom, rather than at every turn, but I could be persuaded
otherwise; not holding that too strongly.
Release Notes:
- N/A
Just a small tweak ensuring the description truncates nicely. I think
this was a recently-introduced regression, as I am pretty sure it was
truncating well not too long ago.
Release Notes:
- N/A
Also, unifies the naming of the variable naming for the target entry in
both the git graph and git panel history tab.
Release Notes:
- Improved the git panel's history tab to keep an entry highlighted
while its context menu is open
TLDR: Opus 4.6 has been falling back to standard speed. Opus 4.7 fast
mode API will error after July 24th.
This will likely need to be cherry-picked to stable for either
Wednesday's release, or be pushed out separately on the 24th to maximize
availability. Although I don't think there are many Opus 4.7 fast mode
users, so Wednesday seems better to me.
> Fast mode for Claude Opus 4.7 is deprecated as of June 25, 2026, and
will be removed on July 24, 2026. After removal, requests to
claude-opus-4-7 with speed: "fast" will return an error; unlike Claude
Opus 4.6 (see the following note), Claude Opus 4.7 does not fall back to
standard speed. The model itself remains available at standard speed. To
continue using fast mode, migrate to Claude Opus 4.8.
Source: https://platform.claude.com/docs/en/build-with-claude/fast-mode
Release Notes:
- Deprecated Fast Mode for Opus 4.6 and Opus 4.7
Fixes an issue where toggling an MCP server on/off in Settings → AI →
MCP Servers does not update the toggle state in the UI immediately.
## Root Cause
There were two issues:
1. `ContextServerStore::update_server_state()` and `remove_server()`
emitted `ServerStatusChangedEvent` but did not call `cx.notify()`, so
Settings UI observers were not informed to re-render.
2. `render_toggle_switch()` was bound to `is_running` (runtime status)
instead of `is_enabled` (settings state).
## Solution
- Add `cx.notify()` in both methods after emitting the status event.
- Change toggle to read `settings.enabled()` and rename parameter from
`is_running` to `is_enabled`.
## Testing
- `cargo check -p settings_ui -p project` passes.
- `cargo fmt --check` passes.
- Manual verification: open Settings → AI → MCP Servers, toggle a
server, observe immediate UI update.
---
Release Notes:
- Fixed MCP server toggle not updating immediately in Settings UI.
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
# Objective
Docker Compose devcontainers currently resume only the primary container
when an existing environment is stopped. Supporting services listed in
`runServices`, such as databases and caches, remain stopped.
Fixes#60779
## Solution
Reuse the Docker Compose startup path when resuming an existing
Compose-based devcontainer.
The resume path now:
- Runs `docker compose up -d --no-recreate`.
- Targets the services configured in `runServices`.
- Uses the original Compose files and project name.
- Avoids recreating the existing devcontainer.
- Preserves the existing `docker start` behavior for non-Compose
devcontainers.
A regression test verifies that the requested services are resumed,
unrelated services are excluded, and the existing container is not
recreated.
## Testing
Tested on macOS with:
- `cargo fmt --all --check`
- `cargo test -p dev_container`
- `cargo clippy -p dev_container --tests -- -D warnings`
All 112 `dev_container` tests pass.
Also tested against a multi-service Docker Compose devcontainer
containing a workspace, web server, PostgreSQL, Redis, and Celery. All
configured services resumed while the workspace container retained the
same container ID.
## 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 Docker Compose dev containers not starting all configured
services when resuming an existing environment.
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
This reverts commit 690c7fac64.
# Objective
language detection is firing very often in channel notes, often picking
YAML instead of markdown, causing some language-detection flickering.
cc/ @amtoaer (author of the original PR)
## Objective
The doc comment links for `Settings::PRESERVED_KEYS` point to
`[FileContent](Self::FileContent)` but that associated type was removed
by the settings refactor in
https://github.com/zed-industries/zed/pull/38367.
`Settings::from_settings` now takes `&SettingsContent` directly. The
dead link causes `rustdoc::broken_intra_doc_links` warnings when
building docs for the `settings` crate:
```
warning: unresolved link to `Self::FileContent`
--> crates/settings/src/settings_store.rs:61:53
|
61 | /// The name of the keys in the [`FileContent`](Self::FileContent) that should
| ^^^^^^^^^^^^^^^^^ the trait `Settings` has no associated item named `FileContent`
```
Fixes#57310
## Solution
Replaced both `[FileContent](Self::FileContent)` occurrences in
`crates/settings/src/settings_store.rs` with `[SettingsContent]`, which
is already in scope via the existing `use` at the top of the file and
resolves correctly. Docs-only change, no runtime behavior change.
## Testing
- Verified with `cargo doc -p settings --no-deps`, which now completes
without any `broken_intra_doc_links` warnings (previously emitted two).
- No runtime code touched — doc comments only, so no other testing
applies.
## 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
The diff already has a constant-time accessor to get the counts of
added/removed rows, use that instead of iterating hunks on the
foreground.
Release Notes:
- Improved performance in agent threads with many file changes.
Closes#61141
Follow-up https://github.com/zed-industries/zed/pull/58791
# Objective
Currently after https://github.com/zed-industries/zed/pull/58791 landed,
we now always ask for the gpg passphrase on every commit which is not
ideal, since some people have a bigger **ttl** configured so they don't
have/want to re-enter their passphrase everytime on every commit. So we
should cache the signature so the user does not have to re-enter their
passphrase everytime, which also fixes the case for unprotected keys
which obviously don't have a passphrase. So we pre-check if we can sign
the commit if so we should not ask for the passphrase at all.
## Solution
The solution was also suggested inside this
https://github.com/zed-industries/zed/issues/61141 issue, to first check
if the signature was cached, if that is is the case use that to sign the
commit. If that fails we should fallback to the loopback mode and Zed
should prompt for your passphrase once and your signature should be
cached again.
## Testing
**The basic setup for gpg signing**:
1. Create a key `gpg --full-generate-key`
2. Run `git config --global user.signingkey <KEY ID>`
3. Run `git config --global commit.gpgsign true`
4. Run & copy result from `gpg --armor --export <KEY ID>` and submit
your public key to github https://github.com/settings/gpg/new
**Testing the new flow were the signature is cached**:
5. Run `gpgconf --reload gpg-agent` to reset cached signature
6. Make a change and try committing
7. See that it promts for your passphrase
8. enter passphrase
9. Make a change and try committing
10. Notice it does not re-promts for your passphrase
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [ ] 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
## Showcase
**Before** (**Note** before you were prompted everytime when you commit)
https://github.com/user-attachments/assets/0a967bb1-5eff-4224-9e9a-995e411f8d3a
**After** (**Note** you are only prompted once and using the keychain
after instead)
https://github.com/user-attachments/assets/5eee6afb-5972-44d8-afdd-6416a189db32
---
**Note**: I used AI as an assistance to write this PR.
Release Notes:
- Git: Fixed the GPG signing passphrase prompt appearing on every commit
even when gpg-agent had the passphrase cached or the key was
unprotected.
# Objective
Fixes#60540
## Solution
I suggest to focus on new feature keybindings support `Text Finder`
instead of supporting old `DeployReplace`:
1. Add `cmd+opt+f` bind for `Text Finder` in `Editor` and `BufferSearch`
to all platforms (now it's not there)
2. Remove `cmd+opt+f` bind for `buffer_search::DeployReplace` from
`Editor` and `BufferSearch` on macOS.
3. Add breaking changes `buffer_search::DeployReplace` has no keybind
anymore on macOS.
## 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
<details>
<summary>Click to view showcase</summary>
Uploading github.mov…
</details>
---
Release Notes:
- `Text Search` now opens from almost all contexts (added `Editor`,
`BufferSearch`)
- Breaking changes: Dropped support for toggle filters hotkey in
`BufferSearch` in macOS instead of supporting new `Text Search` feature
with `cmd+alt+f`
## Summary
Seed the text_finder's query from the focused pane's item instead of
only the active center editor. Selecting text in the terminal or
markdown_preview and opening text_finder now seeds that selection; the
item next to focus wins when both it and a center editor have
selections. If the focused item has no selection, the center item is
tried, then the last persisted search as before.
## Test plan
- Select a word in the terminal, open Text Finder, confirm it's
pre-filled and searching
- With a selection in both terminal and editor, confirm the focused one
wins
- Focus the terminal without a selection, confirm an editor selection
still seeds
- No selection anywhere, confirm the last search is restored
- Confirm a selection in a markdown preview seeds too
Release Notes:
- Improved the Text Finder to seed its query from the focused item's
selection, including the terminal
---------
Co-authored-by: ozacod <ozacod@users.noreply.github.com>
When `active_pane_modifiers.border_size` is set in `settings.json`, both
the active editor pane and the active terminal pane would display a
border simultaneously, making it impossible to tell which pane actually
has focus. The pane opacity dimming also renders simultaneously before
this fix.
1. Before fix: impossible to tell which pane has focus
<img width="901" height="732" alt="image"
src="https://github.com/user-attachments/assets/cbcad798-0d72-420c-9585-2dafa867ff2b"
/>
2. After fix: only one pane has focus
<img width="902" height="731" alt="image"
src="https://github.com/user-attachments/assets/97f2238e-4789-41b3-97e3-98cb9a0c82ef"
/>
The root cause is that both the workspace center and the terminal panel
pass their own `active_pane` to `PaneRenderContext`, so each pane group
unconditionally marks its active pane for border rendering. The fix adds
a focus check so `active_pane_ix` is only set when the pane actually has
keyboard focus, ensuring only the truly focused pane gets the border
(and the inactive_opacity dimming applies correctly to unfocused
groups).
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:
- Fixed active pane border being drawn on both the editor pane and
terminal pane simultaneously
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
`NotebookItem::try_open` only checked the worktree-relative path's
extension, which is empty for single-file worktrees. As a result,
opening a notebook directly (`zed foo.ipynb`, or any open outside a
folder worktree) fell through to the text editor and showed raw JSON,
while the same file opened from within a folder workspace opened in the
notebook editor. Fall back to the absolute path when detecting
notebooks.
Tested locally (macOS, with the notebook feature enabled via
`LOCAL_NOTEBOOK_DEV`): `zed /tmp/solo.ipynb` now opens the rendered
notebook view; folder-workspace behavior unchanged.
Release Notes:
- Fixed notebooks opened as single files (e.g. `zed foo.ipynb`)
rendering as raw JSON instead of opening in the notebook editor
(preview-only).
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Closes#61312
In `parse_choices`, the escape branch only appended the escaped
character to `current_choice` when parsing the first choice, because the
push was placed inside the `!found_default_choice` guard. That guard is
only meant for `text` (the default value inserted into the buffer) — the
plain-text branch below handles it that way. As a result, `${1|a,b\,c|}`
offered the choices `a` and `bc` instead of `a` and `b,c`, and the same
applied to any `\,`, `\|`, or `\\` in choices after the first.
Moved `current_choice.push(c)` out of the guard and added a regression
test covering escaped comma, pipe, and backslash in non-first choices.
Escapes in the first choice were already covered by the existing test
and are unchanged.
Before / after (snippet body `"${1|a,b\\,c|}"`): the choice dropdown
showed `a` / `bc`, now shows `a` / `b,c`.
Release Notes:
- Fixed escaped characters (`\,`, `\|`, `\\`) being dropped from snippet
choice options after the first one
Sometimes when creating Git worktrees, it's necessary to set things up
so the new worktree is ready. For example, copying env.vars, installing
dependencies, etc. That was already possible in Zed through the tasks
system, but you'd only maybe know about that if you read the
documentation or is super familiar with it already; nothing in the
product in the context of worktrees told you about that. This is what
this PR does.
Now, in the worktree picker, there's a "" button that opens the
`tasks.json` file exposing the `create_worktree` hook, which allows you
to plugin all sorts of things to be run by the time of a worktree
creation. If you don't already have a `tasks.json` file, we will create
a new one for you with a worktree-creation template. Otherwise, we
either append the `create_worktree` hook content to it or just open the
file.
Here's a quick video:
https://github.com/user-attachments/assets/21908be4-306b-4cf3-bed0-50d52cad9d79
Release Notes:
- Git Worktrees: Improved discoverability of the `create_worktree` hook
for setting up things that need to happen by the time of worktree
creation.
When a file has unsaved edits and has also changed on disk, the conflict
prompt offered "Overwrite / Discard / Cancel". Both "Overwrite" and
"Discard" were directionally ambiguous, it wasn't clear whether the disk
contents or the buffer edits would be lost. "Discard Edits" makes it
explicit that the buffer edits are thrown away and the disk version is
reloaded.
Release Notes:
- Improved the file conflict prompt by renaming the "Discard" button to
"Discard Edits" to clarify that unsaved edits are discarded in favor of
the on-disk contents.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
# Objective
Markdown Preview does not reveal where a link will navigate before it is
opened or right clicked to copy the URL.
Show a small Firefox-style URL preview in the bottom-left corner when
hovering text links or linked images.
## Solution
- Added URL hover reporting to the Markdown renderer, including hit
detection for linked images that are outside the text layout.
- Used the existing `LinkPreview` component to display the hovered
destination in the bottom-left corner of the Markdown preview.
- Cleared the destination preview when the pointer leaves a link, the
preview, or the displayed Markdown changes.
## Testing
- Confirmed the project builds successfully and manually verified the
behavior on macOS.
- Hovered text links and linked images in a Markdown preview and
confirmed their destinations appear in the bottom-left corner.
- Moved the pointer away from links and outside the preview and
confirmed the destination preview disappears.
- Reviewers can test this by opening a Markdown file containing a text
link and a linked image, opening its preview, and hovering each link.
## 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 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
See bottom left of this image for a sample of the link preview in
action.
<img width="2240" height="1258"
alt="warya_wayne_fix_markdown_render_link_preview_zed_pr"
src="https://github.com/user-attachments/assets/7659e2ae-161d-4a41-a5b4-ba5b76951e30"
/>
---
Release Notes:
- Improved Markdown previews by showing link destinations in the
bottom-left corner when hovering links.
the startup terminal can take a sec to come up if your shell is slow.
when it's ready it grabs focus, and if you've opened the command palette
by then, that blurs the palette input and closes it. so it just
vanishes.
`add_center_terminal` focused the new terminal unconditionally. now it
skips the focus if a modal is open (`!has_active_modal`). one line at
the definition, covers all the call sites.
kept it terminal-specific like dinocosta framed it. could do a broader
workspace-level "don't steal from a modal" instead if you'd prefer.
two tests: modal stays focused after a background terminal spawns (fails
without the fix), and no-modal still focuses the terminal like before.
Fixes#60762.
Release Notes:
- Fixed a background terminal finishing startup closing the command
palette or an open picker
## Context
Buffer search did not work in file diffs opened from the Git panel
because `SoloDiffView` did not expose its embedded editor as searchable.
Restoring search also revealed that the primary toolbar clipped several
search controls, so the deployed search bar now uses the full-width
secondary row for this view.
Closes#60659.
## How to Review
Three files changed. Read in this order:
**`crates/git_ui/src/solo_diff_view.rs`** :
`SoloDiffView::as_searchable` now returns its embedded
`SplittableEditor`, restoring search for the focused diff side while
keeping the editor hidden from global diff-style controls.
**`crates/search/src/buffer_search.rs`** : Buffer search now detects
when its searchable split editor is intentionally hidden by the
containing item. When deployed, this case uses the secondary toolbar row
so Toggle Replace, search options, match navigation, and match counts
remain visible. Other multibuffer layouts keep their existing primary
toolbar location.
**`crates/git_ui/src/git_panel.rs`** : The regression test now opens a
solo diff through the Git panel, confirms the split editor is
searchable, deploys buffer search, verifies the secondary toolbar
location, runs a query, and checks that the focused editor receives a
search highlight.
Manual test after the fix below :
[Screencast from 2026-07-14
00-39-04.webm](https://github.com/user-attachments/assets/022ab106-d35a-4a75-98db-8809b86fa58d)
## 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 searching in file diffs opened from the Git panel.
Co-authored-by: Chris Biscardi <chris@christopherbiscardi.com>
# Objective
The contextmenu listener cancelled the browser's native menu
unconditionally, so pages hosting a gpui app lost right-click entirely
wherever the app showed no menu of its own, and apps that do show one
had no native menu to suppress selectively.
## Solution
Record whether the right-button MouseDown dispatch was consumed (a
handler called stop_propagation, e.g. to open a custom menu) and cancel
the native menu only in that case: app menus win where they exist, the
browser menu everywhere else. Apps opening custom context menus should
mark the triggering mousedown consumed to opt in.
## Testing
Tested locally
## 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="816" height="288" alt="context menu"
src="https://github.com/user-attachments/assets/c79cd2ef-d465-4431-8461-7a9feb922576"
/>
Release Notes:
- N/A
run htop or btm and you can't select terminal text with shift+drag, the
usual escape hatch does nothing.
#25143 made shift+click only ever extend a selection, never start one.
so with nothing selected there's no anchor and the drag has nothing to
grab. now it drops an anchor when there's no selection, and still
extends when there is.
added two event-level tests (harness can't sync without a window):
shift+drag under mouse tracking, which fails without the fix, and
shift+click still extending.
Fixes#60254.
Release Notes:
- Fixed Shift+click-drag not selecting terminal text while an app has
mouse tracking enabled
# Objective
Closes#4868.
Untitled buffers start as Plain Text and require users to select a
language manually before receiving syntax highlighting. Add lightweight
automatic language detection for code entered or pasted into untitled
buffers.
## Solution
This builds on [Max Stevens's earlier language-detection
work](https://github.com/zed-industries/zed/pull/43057), replacing
Magika with [Betlang](https://github.com/DioxusLabs/betlang).
While researching smaller and faster alternatives to Magika, I came
across Betlang, a recently introduced language detection library
developed by DioxusLabs for dioxus-code. The fact that it comes from
DioxusLabs gave me more confidence in evaluating this relatively new
dependency for Zed. Betlang embeds an approximately 50 KB model, is
MIT-licensed, and depends only on `fearless_simd`, making it well suited
to Zed's cross-platform embedding requirements.
Detection runs on the background executor with bounded input sampling.
It is restricted to untitled buffers, skips content shorter than 20
bytes, and requires at least 50% confidence. These limits have worked
well in local testing. In release builds on Linux with an Intel Core
i5-13600KF, the `betlang::detect` call alone typically completes within
3 ms when processing the maximum sampled input.
## Testing
I added a test for language detection in untitled buffers that covers
both manually entered and pasted content. The test passes successfully.
I also manually tested the feature to verify that the overall experience
works well.
## 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
https://github.com/user-attachments/assets/96e28ad7-2968-4325-9aff-37fe813a2da7
---
Release Notes:
- Added automatic language detection for untitled buffers.
---------
Co-authored-by: Max Stevens <maxstevens2708@gmail.com>
Closes#54951
## Problem
The quick action bar's preview button (markdown, SVG, and CSV behind the
feature flag) resolved everything through `workspace.active_item()` —
the globally *focused* item — instead of the item of the pane the button
sits in. With `A.md` in the left pane and focus in `B.md` in the right
pane:
- Clicking the eye button in **A.md's** toolbar opened a preview of
**B.md**, in the right pane.
- Focusing a non-previewable file (e.g. `B.sh`) in one pane hid the
button in **every** pane's toolbar, making `A.md` unpreviewable by
mouse.
Clicking the button dispatched the `OpenPreview` action, whose
workspace-level handler re-resolved the focused editor — so a click on a
specific pane's toolbar was functionally identical to pressing the
keybinding, discarding the pane the click happened in.
## Fix
Make the flow pane-explicit end to end:
- **Visibility:** each pane's `QuickActionBar` resolves the preview type
from its own `active_item` (set via `set_active_pane_item`) instead of
the workspace's focused item.
- **Click:** no more action dispatch. The handler resolves its pane via
`Workspace::pane_for` and calls new pane-explicit helpers —
`open_preview_in_pane` / `open_preview_to_the_side_of_pane` — extracted
from the action-handler bodies in all three preview crates. Keyboard
actions keep their focus-based semantics and route through the same
helpers with the focused editor and active pane.
- **Alt-click** (open in split) now splits relative to the button's pane
via the new `Workspace::adjacent_pane_of` (the existing `adjacent_pane`
delegates to it).
Notably *not* done: focusing the button's pane and re-dispatching the
action. `workspace.active_pane` only updates when pane focus-in
listeners fire at the end of the next draw, while dispatched actions run
before it — the handler would still read the stale pane.
## Additional changes
- Existing-preview lookup now happens **before** view construction,
instead of building a full preview view (subscriptions, initial parse)
and discarding it when one already exists.
- The `focus` flag now also applies to the activate-existing branch, so
open-to-the-side never steals focus — previously the *first* invocation
left focus in the editor but a *repeat* invocation focused the existing
preview (and cancelled collaborator-following in that pane as a side
effect).
- SVG handlers no longer double-check `is_svg_file`; CSV handlers reuse
`resolve_active_item_as_csv_editor` instead of inlining it;
`is_markdown_file` takes `&App` instead of a needless `&mut Context<V>`.
## Testing
- New regression test
`preview_opens_for_the_given_pane_not_the_focused_editor` reproducing
the issue's setup (two panes, focus in the second, preview invoked for
the first pane's editor), asserting the preview opens in the invoking
pane bound to that pane's editor with the focused pane untouched.
- Markdown/SVG/CSV preview suites and the full `workspace` suite pass;
`./script/clippy` is clean.
Release Notes:
- Fixed the preview button (Markdown/SVG) previewing the focused file
instead of the file in the pane the button belongs to when multiple
panes are open
# Objective
Make the branch picker easier to scan and ensure branch creation and
remote icons behave consistently across All, Local, and Remote filters.
## Solution
- Group local and remote branches under their own headers in the All
filter.
- Place the create-branch option above branch sections when there is no
exact branch-name match.
- Resolve each remote's hosting provider from its URL and show the
provider icon for branches from that remote.
- Include remote URLs in remote-workspace repository responses so
arbitrary remote names work without hardcoding `origin` or `upstream`.
## Edge Cases Fixed
- An exact branch can exist outside the active Local or Remote filter.
The picker now checks all branches before offering to create a duplicate
branch.
- A non-exact search can return fuzzy branch matches and a create
action. The create action now stays at the top, before the Local and
Remote section headers.
- When a filtered search has no branch matches, the create action is
shown without incorrectly placing it under a Local Branches or Remote
Branches header.
- Repositories can use any remote name, not only `origin` and
`upstream`. Provider icons are resolved independently for every
configured remote.
- Remotes hosted on an unknown or unsupported forge use the generic
server icon instead of implying a desktop or a specific provider.
- Remote-workspace repositories carry the same remote-name-to-URL data
as local repositories, so their branch icons follow the same
provider-resolution path.
## Testing
- `cargo check -p git_ui --no-default-features`
- Branch picker test suite (17 tests)
- `git diff --check`
Tested on macOS.
## 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="560" height="522" alt="Screenshot 2026-07-17 at 11 19 27 PM"
src="https://github.com/user-attachments/assets/28d57315-b859-4a8d-86ca-53f9fb513bf5"
/>
The updated branch picker groups local and remote branches, keeps the
create-branch action above those sections, and shows forge-specific
icons for remote branches.
---
Release Notes:
- Improved branch picker filtering, grouping, branch creation
suggestions, and remote-provider icons.
# Objective
Fixes#59304
Right now inline html tags don't render with any kind of highlighting,
despite the fact that non-inline html tags do get highlighting.
## Solution
Right now zed already has tree-sitter rules that identifies the inline
blocks so we can add a new tree-sitter grammar rule,
```
((html_tag) @injection.content
(#set! injection.language "html")
(#set! injection.combined))
```
that passes these blocks to the html language server.
## Testing
I did some manual testing:
https://github.com/user-attachments/assets/92e5b322-bbc1-48c3-a615-0d32acc2e7d6
And also added a test:
test_markdown_inline_html_highlighting
## 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:
- markdown: Fixed inline html block highlighting.
# Objective
Fixes#59983.
Reducing the Zed window height with the terminal open can clip the
Bottom Dock and terminal content. The dock should shrink to remain
within the workspace instead of extending beyond the window.
## Solution
Restore height clamping for Bottom Dock panels by skipping
`clamp_panel_size` only when a panel actually uses flexible width.
Flexible sizing remains unchanged for the Left and Right Docks, while
Bottom Dock panels once again reduce their stored height to fit the
available workspace.
## Testing
Added a regression test that distinguishes flexible Bottom and Right
Dock behavior. It confirms that the Bottom Dock is clamped while the
flexible-width Right Dock is not. The test failed with the previous
condition and passed with this change.
Manually verified the reported window-resizing scenario locally.
## 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
+ Before
https://github.com/user-attachments/assets/c56995a8-47c6-45b6-aeb4-b0b56477c737
+ After
https://github.com/user-attachments/assets/97b5ca6f-cf6f-4dd5-b981-e44bd8139490
---
Release Notes:
- Fixed bottom dock clipping when resizing windows.
# Objective
Before this PR we would show inside the recent project picker the
projects per group (window) which is great, but when you were trying to
remove a project from the group it would show you a label that includes
the just removed project and also when you clicked on it, it would bring
you back to the 2 project's in the same window in this case.
## Solution
My solution is when we actually remove the project from a group, we also
update the group key that includes the newly updated path list, that
should no longer have the removed project path in it. I also refactored
it a bit so we have one method that does the project removing part so we
don't have to duplicate this logic.
## Testing
You can produce this when you do the following:
1. Open Zed
2. Add 2 projects to your window using the project panel
3. Open the recent project picker
4. See that the `This window` header shows 2 projects
5. Remove one of the projects
6. See that below the `This window` header we would show you a entry
that shows you `projectA, projectB` where **projectb** should be removed
from the group.
I also added a regression test that covers this issue, so we can make
sure the change actually works and does not regress of couse :).
## 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
**Before** (**Note** before this change we showed the group project
names comma seperated)
https://github.com/user-attachments/assets/750358f4-f347-4f91-86b7-6500b2e09af9
**After** (**Note** after we now updated the groups key so it does not
include the removed project)
https://github.com/user-attachments/assets/f15acea8-d936-4aab-b5c2-324ee49f74a2
---
Release Notes:
- Recent projects: Fixed that it shows you a removed project from a
group
# Objective
Closes#41743
When selecting text on the last line, excluding the trailing newline,
Vim and Helix modes behave differently from native Vim and Helix when
the file has a trailing newline:
1. We cannot use `l` (move right) to include the final `\n` in the
selection, while native Vim and Helix allow this.
2. By default, the rendered cursor should appear on the selected
character. When that character is the final `\n`, however, Zed renders
the cursor on the synthetic empty line after it rather than at the end
of the preceding line. This differs from native Vim and Helix, as well
as from Zed's behavior for newlines elsewhere in the file.
3. When the final `\n` is selected, it affects subsequent selection
motions, as reported in #41743.
The cause is several special-case guards for trailing newlines in Visual
and Select modes. These guards exist in the cursor rendering logic:
c9e8e611db/crates/editor/src/element.rs (L201-L213)
They also exist in the Visual motion logic for Vim mode and the Select
motion logic for Helix mode (the Helix implementation was adopted
directly from Vim in #43234):
c9e8e611db/crates/vim/src/visual.rs (L254-L259)
Finally, they exist in the selection extension logic for Vim and Helix
(the Helix logic was also adopted from Vim):
c9e8e611db/crates/vim/src/visual.rs (L273-L284)
These guards cause trailing-newline selections to behave inconsistently
with selections containing newlines elsewhere in the file.
## Solution
Remove all the guards mentioned above, including those in cursor
rendering, Visual and Select motions, and selection extension. And due
to the cursor rendering logic is also changed, an exsisting test is
updated.
After removing these guards, I could not reproduce the unexpected
behavior described in the existing comments:
c9e8e611db/crates/vim/src/visual.rs (L247-L253)
The only remaining difference is that, when the cursor is on the last
line in Visual mode, pressing `j` moves it to the final `\n` rather than
to the synthetic empty line after it. In comparison, native Vim and
Helix do nothing in this case.
## Testing
- Built and tested locally.
- Added new GPUI tests.
## 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:
- Improved Vim Visual and Helix Select modes when selections include a
trailing newline.
# Objective
As part of the transparent-window artifact fixes in #58981, multibuffer
header backgrounds stopped rendering whenever the window was transparent
or blurred.
This caused a regression for transparent themes, which commonly use an
opaque multibuffer header background to prevent editor text from showing
through sticky headers.
## Solution
Render `editor_subheader_background` when either the window or the
configured background color is opaque.
This restores opaque multibuffer header backgrounds as a mask for the
editor content beneath them, while preserving the #58981 behavior for
translucent backgrounds that would otherwise create a darker layered
region.
## Testing
Manually verified locally with a transparent theme that an opaque
multibuffer header background is rendered and prevents editor text from
showing through sticky headers.
## 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
## Showcase
**Nightfox - opaque / blurred**
Before:
<img width="2566" height="1771" alt="图片"
src="https://github.com/user-attachments/assets/55b333bc-b029-4079-9bbc-86462a3f41a7"
/>
After:
<img width="2444" height="1687" alt="图片"
src="https://github.com/user-attachments/assets/217e1ee7-717c-4961-8db0-5eac8104e5bb"
/>
---
Release Notes:
- Fixed editor text showing through multibuffer headers and overlapping
header text in transparent themes.
Found some unnecessary allocations and an `.unwrap()` while working on a
separate issue. The PR makes no behavior changes and should be trivial
to review.
## Testing
All tests pass. These changes are not expected to change any behavior.
None of the changes are interleaving, so it should be easy to review
top-down. Reasoning for each change can be read from individual commit
messages.
Release Notes:
- N/A or Added/Fixed/Improved ...
# Objective
When using column Git blame with avatars enabled, blame entries whose
author name is the longest in the buffer can exceed the blame border.
For example, line 10 of `crates/vim/src/visual.rs` is displayed as
follows:
<img width="998" height="121" alt="issue"
src="https://github.com/user-attachments/assets/eff3e1ff-bd1c-42af-ae9b-da8efb0a7c22"
/>
The blame contents exceeds the width.
The root cause is in the blame width calculation:
0c51c7fd24/crates/editor/src/editor.rs (L11583-L11598)
The calculation accounts for the commit SHA, author name, and timestamp.
Other elements, including spacing, margins, and the avatar, are
represented by the fixed `SPACING_WIDTH` constant.
For typical fonts, `ch_advance` is approximately `0.5rem` to `0.6rem`,
so `SPACING_WIDTH` provides approximately `2rem` to `2.4rem` for
non-text content. However, the avatar itself occupies `1rem`:
0c51c7fd24/crates/ui/src/components/avatar.rs (L81)
When avatars are displayed, the entry also contains three `0.5rem` gaps
and also one `0.5rem` right margin:
0c51c7fd24/crates/git_ui/src/blame_ui.rs (L170-L188)
This requires approximately `3.0rem`, which can exceed the space
provided by `SPACING_WIDTH`. When an entry contains both the longest
author name in the buffer and a long timestamp, its content can
therefore exceed the blame border.
## Solution
The simplest fix would be to increase `SPACING_WIDTH`, but that would
still rely on an approximate conversion between editor character widths
and UI dimensions.
Instead, this PR adds a method to the blame renderer for calculating the
non-text width of a blame entry. The editor uses this value together
with the measured text width when calculating the final blame width.
## Testing
Tested locally. A before-and-after comparison is included below.
## 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
## Showcase
| Before | After |
| :--: | :--: |
| <img width="551" height="94" alt="Before"
src="https://github.com/user-attachments/assets/b6741a41-6531-4fae-adaa-f9ae0b298e0f"
/> |<img width="566" height="93" alt="After"
src="https://github.com/user-attachments/assets/e8d75d2a-6b07-43f6-b2a8-bfb76d118611"
/> |
Release Notes:
- Fixed Git blame entries overflowing the gutter when avatars are
displayed.
# Objective
When you make a line selection in a row that is long enough to multiple
lines long while wrapped the selection box will disappear when the
cursor (or just origin of the line selection goes off screen).
## Solution
The when you are in line selection mode the `SelectionsCollection` just
enables `line_mode`, instead of storing the whole ranges of those line
selections, so the Anchor of the selection is a single point.
`disjoint_in_range` filters all the disjoint selections of the
collection to fit inside some range, this is used to render the
selection boxes on screen. `disjoint_in_range` had no special case for
`line_mode` causing it to filter on the point instead of the bounds of
the selection.
My fix is too add a case for `line_mode` that changes the filtering
`Anchor` -> `Point` and then only filters on the row. Then use the
proper bounds of the selection with that:
```rust
let (start_ix, end_ix) = if self.line_mode {
let start_row = range.start.to_point(buffer).row;
let end_row = range.end.to_point(buffer).row;
let start_ix = self
.disjoint
.partition_point(|probe| probe.end.to_point(buffer).row < start_row);
let end_ix = self
.disjoint
.partition_point(|probe| probe.start.to_point(buffer).row <= end_row);
(start_ix, end_ix)
} else {
...
```
## Testing
Before:
https://github.com/user-attachments/assets/a443de39-53d7-4ee4-b3af-d3be99ca1fcf
After:
https://github.com/user-attachments/assets/18c1c7ef-45cc-4dc8-9a8b-241252c376ab
I also added some tests `disjoint_in_range_line_mode_matches_whole_row`,
being the one that really tests this behavior. the other two are just
for `disjoint_in_range`
I am using macOS 27.0 Beta (26A5368g), but I noticed this bug before
upgrading.
## 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:
- editor: Fixed bug where selection boxes wouldn't render when the
cursor was offscreen.
# Objective
When joining lines, Zed checks the next line and strips comment,
documentation-comment, and unordered-list delimiters. The logic trims
whitespace from these delimiters, then checks whether the next line
starts with the trimmed delimiter. If it does, Zed removes the delimiter
before joining the lines.
This works for comment and documentation-comment delimiters, where
trailing whitespace does not affect their meaning. However, it causes
unexpected behavior for unordered-list delimiters, which, as far as I
know, are unique to Markdown.
In Markdown, `* ` is an unordered-list marker, while `*` is also used as
an emphasis delimiter, such as `*italics*` and `**bold**`. The current
logic strips the leading `*` from these emphasis cases, which it should
not.
## Solution
For unordered-list delimiters, Zed should strip the exact delimiter,
such as `* `, rather than the trimmed `*`. It should strip a bare `*`
only when the next line contains only `*`.
## Testing
Tested locally and new GPUI tests were added.
## 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 markdown emphasis delimiters being removed when joining lines.
