Chrome-parity navigation work for the PDF viewer:
- Find in document (ctrl-f): query editor, match counter, Enter/Shift+Enter
and ctrl-g navigation, yellow highlights with a stronger tint on the
active match, and a page jump per match.
- Internal link destinations: pdfium now reports dest_page for GoTo links,
so clicking a link that points inside the document jumps to that page
instead of being dropped.
- Space/Shift+Space scroll the viewport a screen at a time, unless the
find bar has focus so the query stays typeable.
Follow-up to #63195.
# Objective
When `cursor_animation` is enabled, moving a block cursor (e.g. in Vim
mode) leaves the character underneath hidden until the spring animation
fully finishes, after which the letter pops in.
This happens because `CursorLayout::paint` returned early while
animating, skipping `block_text`.
## Solution
Paint `block_text` upon the animated cursor's arrival at the target
cell, rather than waiting for the entire spring settling phase to
complete:
- Check if any animated corner has reached the target bounds
(`bounds.dilate(...)`).
- If the cursor is still in mid-air, return early so we don't draw the
destination letter prematurely.
- Once it touches the target cell, fall through and paint `block_text`
over the cursor polygon.
## 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)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
Left: before, Right: after
https://github.com/user-attachments/assets/7057f40a-64a7-4035-b8e2-7c0b7dc40069
---
Release Notes:
- Fixed an issue where the block cursor hid the character underneath
until cursor animation completed.
---------
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
# Objective
Zed on X11 could crash with `index out of bounds: the len is 0 but the
index is 0` in `WgpuAtlas::get_texture_info` right after recovering from
a lost GPU device (Sentry ZED-BVQ, Linear FR-488).
## Solution
When the device is lost, `X11Window::draw` recreates the renderer, which
clears the sprite atlas, and sets `force_render_after_recovery` so the
next frame rebuilds the scene instead of replaying the cached one. Only
the periodic refresh timer consumed that flag though. An `Expose` event
handled in the same event loop turn (a compositor repainting after the
same GPU reset, for example) requested a presentation-only frame with
`force_render: false`, so GPUI presented the previously rendered scene,
whose sprites still pointed at atlas textures that no longer exist.
We now consume the flag in `X11WindowStatePtr::refresh`, so every frame
request, Expose or timer, forces a full render after recovery. The field
is private now so a caller can't bypass it again.
## 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 a crash on Linux (X11) that could occur when a window was
redrawn immediately after recovering from a lost GPU device.
- [GPUI] Fixed a crash on Linux (X11) when an `Expose` event presented a
cached frame immediately after GPU device recovery.
Primarily, add a
- helper to easily get information on what pulls in a crate (hey Mr
Piotr we can consider moving this up in the namespace to also use this
elsewhere)
- helper to extract a list of GPUI crates in order which need publishing
Release Notes:
- N/A
# Objective
Fixes#63835.
Nearby related diagnostics omitted the link back to their primary
diagnostic.
## Solution
Always include the existing back link on related diagnostic blocks,
regardless of line distance. The primary diagnostic still suppresses
nearby related hints as before.
## 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
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Improved diagnostic navigation by showing back links to the primary
diagnostic even for nearby related diagnostics.
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Previously, we created texture atlas bind groups every frame (once per
sprite group). This showed up in delta web mobile profiling.
This PR reuses them across frames, which saved ~5% frame time on the
delta web thread view on a pixel 10 pro.
---
Release Notes:
- [GPUI]: Improved performance on wgpu by caching atlas bind groups
Reduce the nightly release workflow from six runs per day to two runs
per day, at 02:00 and 14:00 UTC. Update both the workflow generator and
generated workflow.
Validated by regenerating workflows with `cargo xtask workflows`.
Release Notes:
- N/A
---------
Co-authored-by: Amp <amp@ampcode.com>
Based on
https://github.com/zed-industries/zed/pull/64464#issuecomment-5763255028
With `RUST_BACKTRACE=1` set, `anyhow` captures a backtrace for every
error it constructs; on macOS this costs ~30ms per error, on Linux ~µs.
`Project::test` alone hits several such errors during setup
(`canonicalize`/`load` of the non-existent global `tasks.json` and
`debug.json`, worktree creation, buffer open), adding ~0.8s of fixed
cost per test on macOS.
`RUST_LIB_BACKTRACE=0` is checked by std before `RUST_BACKTRACE`, so
panics keep their backtraces while library error captures stop.
Set only on the macOS test jobs (`run_tests.yml`, `release.yml`), since
Linux and Windows pay nothing for the captures and keep the error-origin
backtraces in failure output.
Measured with `cargo nextest run -p editor --lib`: macOS 119s → 72s,
Linux 78s → 76s (noise).
Trade-off on macOS: a failing `.unwrap()` on an `anyhow::Error` in CI
output loses the backtrace of where the error was constructed; the panic
backtrace at the unwrap site is unaffected.
Release Notes:
- N/A
## Objective
Allow custom terminal path regexes to extend inherited entries without
copying them. This PR also corrects the existing mismatch between the
documented and shipped default regexes.
This is the last submission in the #64399 series, following #62769,
#64222, #64440, #64484, and #64540.
## Solution
The `"..."` entry is intentionally supported at the top level only. A
`"..."` line inside a multiline entry remains regex text. Existing
configurations that use bare `...` as a three-character regex can
preserve that behavior by writing `["..."]` as an entry instead.
The shipped regexes and hyperlink matching behavior are unchanged.
## Testing
All focused tests and all hyperlink tests pass on macOS. The documented
default expressions were checked against the shipped values.
## 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:
- Added support for `"..."` in `terminal.path_hyperlink_regexes` to
extend inherited regexes without repeating them.
Make provider-owned terminal cards read-only for user input while
preserving local inspection. This builds on the explicit terminal
ownership introduced in #64544.
- Add a construction-time `TerminalView::with_read_only` option,
selected from ACP process ownership rather than PTY presence. Existing
views remain interactive by default, including client-owned headless
terminals.
- Reject typing, send actions, paste, file/path drops, IME input,
clear/rerun actions, and focus reports in read-only views.
- Preserve selection, copying, links, scrolling, search, and local Vi
navigation. Leaving Vi mode does not enable terminal input.
- Pass an explicit mouse-routing policy to the existing lower terminal
handlers so provider-requested mouse and alternate-scroll modes cannot
consume inspection gestures. Real modifiers remain unchanged, and
Linux/FreeBSD middle-click paste is suppressed.
Release Notes:
- N/A
## Objective
Group the threads sidebar settings together in JSON and the Settings
Editor, using consistent “Threads Sidebar” terminology.
This follows up on #63452 now that #62883 has added configurable default
width, and includes the auto-open setting added since then.
## Solution
- Group `position`, `default_width`, and `auto_open` under
`agent.threads_sidebar`, and display their controls together in
Settings.
- Automatically migrate `agent.sidebar_side`,
`agent.threads_sidebar_default_width`, and
`agent.threads_sidebar_auto_open` across supported settings scopes,
preserving existing nested values.
- Apply changes to the default width immediately, including when the
sidebar was manually resized, and clear the saved width override.
Unrelated settings changes preserve manual sizing.
- Document all three settings, including the previously missing position
entry.
## Testing
The following targeted checks passed on the local changes:
- `cargo test -p migrator nest_agent_threads_sidebar_settings` — 7 tests
passed.
- `cargo test -p sidebar -p workspace -p agent_settings -p gpui_platform
--features gpui_platform/runtime_shaders --lib -- width
threads_sidebar_settings test_open_directory_in_existing_window` — 9
tests passed.
- `cargo fmt --all` completed successfully.
- `git diff --check` passed.
- From `docs`: `npx prettier --check src/reference/all-settings.md
src/ai/parallel-agents.md` passed.
Coverage includes migration precedence and supported scopes, settings
defaults and width limits, manual sizing and resets, persisted widths,
and auto-open behavior.
Full application tests and manual UI testing were not run. Clippy was
not rerun after the final terminology changes.
## 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 threads sidebar settings by grouping position, default width,
and auto-open together, and applying default-width changes even after
manual resizing.
Fixes the git panel's active repository being silently overridden by the
cursor position in `ProjectDiff`.
Closes#58792Closes#61530
## Summary
When a multi-buffer item (e.g. `ProjectDiff`) gains focus, the workspace
calls `set_active_repo_for_path` with the cursor's project path to
automatically switch the active git repository. This was safe when
multi-buffer items returned `None` from `active_project_path`, but PR
#57236 changed `ProjectDiff` to return the cursor-based path (for
project panel highlighting), inadvertently allowing the cursor position
to override the user's explicit repository selection.
Fix the issue by restoring the `Singleton` guard that was removed in PR
#57236: only call `set_active_repo_for_path` when the active item is
backed by a single buffer.
## Changes
- **`workspace.rs`**: Only call `set_active_repo_for_path` when the
active item's `buffer_kind` is `Singleton`. Multi-buffer items (e.g.
`ProjectDiff`, diagnostics, search results) span multiple repositories,
so their cursor position should not trigger an automatic repository
switch.
## Before
https://github.com/user-attachments/assets/6ca4fa61-b42a-447b-9de7-8b6ec1f1181a
## After
https://github.com/user-attachments/assets/9b045ad9-2bb5-4862-ac45-41e9fdd3dc96Closes#58792
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 the Git panel unexpectedly switching repositories when viewing
changes in multi-repository projects.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: dino <dinojoaocosta@gmail.com>
## Objective
Let projects and language-specific settings add scopes where edit
predictions are disabled without repeating inherited scopes.
Part of #64399.
## Solution
Extend the `"..."` convention from #62769, #64222, #64440, #64484, and
#64540 to `edit_predictions_disabled_in`. For example, a global
`["comment"]` and a language override of `["string", "..."]` disable
predictions in both scopes.
Inherited scopes are inserted at `"..."`, and duplicates keep their
first occurrence. Omitting the marker replaces the list, `[]` clears it,
and omitting the setting preserves inheritance. The default remains
`[]`.
## Testing
Tested on macOS through settings loading, covering project and
language-specific overrides, inheritance, replacement, and clearing. The
language settings tests passed. Live editor behavior has not been
checked manually.
To check manually, configure global `["comment"]` and a language
override of `["string", "..."]`. Confirm predictions are disabled in
both scopes, then remove `"..."` and repeat with `[]` to check
replacement and clearing.
## 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:
- Added support for `"..."` in `edit_predictions_disabled_in` so project
and language-specific settings can extend inherited scopes.
---------
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
## Objective
Let users and projects add edit prediction exclusion patterns without
repeating defaults or inherited patterns.
Part of #64399.
## Solution
Extend the `"..."` convention from #62769, #64222, #64440, and #64484 to
`edit_predictions.disabled_globs` using `SplicingVec`. Inherited
patterns are inserted at `"..."`, and duplicates retain their first
occurrence. Omitting the marker replaces the list, `[]` clears it, and
omitting the setting preserves inheritance.
Opening an absent setting now initializes it with `["..."]` instead of
clearing inherited patterns, and the selection is located by parsing the
JSON instead of a regex, so a commented-out or nested `"disabled_globs"`
can no longer capture it. Cursor imports append `"..."` like the
`files.exclude` import does, so Zed's sensitive-file defaults survive an
import; empty lists and empty or literal `"..."` entries are dropped,
matching `enabled_patterns`.
## Testing
Tested on macOS with settings merge and loading tests, Cursor import
tests, the UI settings update and selection path (including
commented-out and nested decoy keys), the new `settings_json` key-path
lookup, and Copilot integration coverage.
To check manually, configure custom disabled patterns alongside `"..."`
and confirm that both custom patterns and inherited sensitive-file
patterns remain disabled. Repeat without `"..."` and with `[]` to verify
replacement and clearing. Opening the setting when it is absent should
preserve inherited patterns.
## 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:
- Added support for `"..."` in `edit_predictions.disabled_globs` so
custom patterns can extend inherited exclusions, and fixed "Configure
Excluded Files" selecting the wrong list when a commented-out
`disabled_globs` precedes it.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Provider terminal metadata creates a display buffer, not a client-owned
process. These terminals previously entered the process-completion path,
which completed immediately when no local task existed and cached empty
output. Provider exit status was also discarded.
- Distinguish client-owned processes from provider-owned display
terminals, including headless processes that use the same lower-level
display renderer.
- Complete display terminals on provider exit and retain ACP exit
codes/signals. Duplicate creation and exit events preserve identity and
completion; late output refreshes cached content without changing exit
time or status.
- Refresh tool-card metadata when provider completion arrives without
another tool update.
- Show Stop only for client-owned processes and avoid treating display
terminals as background processes when their tool completes.
- Preserve the full unsigned exit-code range without manufacturing `-1`
for signal-only exits.
Process wait/kill behavior, PTY release, and sandbox cleanup remain
intact. Header rendering continues to use cached metadata rather than
extracting terminal contents.
Release Notes:
- acp: Fixed premature completion and incorrect exit-status reporting
for external-agent terminals, and removed Stop controls from terminals
managed by the agent.
# Objective
- This PR enables users to switch between unified/split diff views when
comparing buffers.
- Fixes#64419 .
## Solution
- The unified/split toggle (`DiffStyleControls`) is normally surfaced
automatically by `BufferSearchBar`, which detects any active item
exposing a `SplittableEditor`. That auto-detection is gated to
multi-buffer views, since it's paired with an expand/collapse-all-hunks
control that only makes sense across multiple files. `FileDiffView`
(used by `zed --diff <old> <new>`) is a singleton buffer, so it's
intentionally excluded from that generic path.
- Git's own single-file diff view,
[`SoloDiffView`](https://github.com/zed-industries/zed/blob/f2e33599724432f329f9e23b353a8fb28cd6ece3/crates/git_ui/src/solo_diff_view.rs#L52),
hits the same limitation and works around it with a small, dedicated
`ToolbarItemView` (`SoloDiffStyleToolbar`) that renders
`DiffStyleControls` directly, independent of `BufferSearchBar`.
- This PR follows the same pattern: a new `FileDiffStyleToolbar` (in
`git_ui_core::file_diff_view`) activates whenever a `FileDiffView` is
the focused pane item, and renders just the unified/split toggle, no
expand/collapse or file-status controls, since neither concept applies
to a plain two-file diff. It's registered in `initialize_pane` alongside
the existing git toolbars.
## Testing
- Did you test these changes? If so, how?
Ran `cargo test -p git_ui_core`, all passed. I've also attached the
results of manual testing in the Showcase section below.
- Are there any parts that need more testing?
I think more tests can be 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
## Showcase
Adds a unified/split toggle to the diff view opened via `zed --diff
<old> <new>`, matching the toggle already available in git's diff views.
<details>
<summary>Click to view before/after</summary>
**Before**:
<img width="1920" height="1080" alt="screenshot_20260921_020610"
src="https://github.com/user-attachments/assets/92cbcf75-0cac-4555-8d2d-ce927064515f"
/>
**After**:
<img width="1920" height="1080" alt="screenshot_20260921_020355"
src="https://github.com/user-attachments/assets/56f9ebc6-11df-41cc-a44d-99bfa8caa130"
/>
</details>
---
Release Notes:
- Added a unified/split toggle to the diff view opened via `zed --diff
<old> <new>` command.
---------
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Preserve ordered mixed content in agent messages without disrupting text
streaming for existing native/v1 agents. The previous single-block
reduction could replace images with placeholders or lose non-text
content as subsequent chunks arrived.
- Introduce [ordered message display
content](https://github.com/zed-industries/zed/blob/929fba3e16f7a378eb1dca3d85ac2f1df2b902c6/crates/acp_thread/src/acp_thread.rs#L1500),
reusing adjacent text entities while retaining image/resource-preview
boundaries.
- Update rendering, text search, response copy/export, Mermaid cache
invalidation, and CLI output to visit the collection.
- Use block-local context menus and existing Markdown getters so copy
commands target the clicked part rather than another part's cached
state.
- Keep existing link/mention formatting, resource-button and blob-label
search behavior, compact prompt mentions, and original user-message
chunks.
- Preserve the separator between a leading resource link and subsequent
direct or streamed text.
Release Notes:
- N/A
# Objective
- Fix PowerShell discovery when Scoop is installed outside the default
`%USERPROFILE%\scoop` directory.
- Zed currently ignores Scoop's `SCOOP` environment variable, so it can
miss `pwsh.exe` and fall back to another shell.
## Solution
- Use the `SCOOP` environment variable as the Scoop root when it is set.
- Fall back to `%USERPROFILE%\scoop` when `SCOOP` is unset.
- Preserve the PowerShell discovery order and file validation from the
current `main` branch.
The original change also covered Git Bash. That is no longer needed
after #63339 changed Git Bash discovery to follow the active Git
installation.
## Testing
- `cargo fmt --all --check`
- `cargo test -p gpui_util` — 2 passed, 0 failed.
- `cargo check -p gpui_util --tests --target x86_64-pc-windows-msvc` —
passed.
- Did not runtime-test the Windows-specific path on this macOS host
because Windows test binaries cannot run natively here.
- To test manually on Windows, set `SCOOP` to a custom Scoop root
containing `shims\pwsh.exe`, launch Zed, and verify that PowerShell is
selected.
## 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 PowerShell installed by Scoop not being detected when Scoop uses
a custom installation directory.
- [GPUI] Fixed PowerShell discovery for custom Scoop installations on
Windows.
Signed-off-by: jliu666 <jliu666@hotmail.com>
Opening a file like `zed "\\server\share\file.txt"` leaves it with no
language servers attached, and the tab shows the ugly `\\?\UNC\...`
path.
The problem is the verbatim `\\?\UNC\` prefix Windows adds during path
canonicalization. We rely on dunce to strip these prefixes, but it
doesn't handle the UNC case, so the path stays in a form that breaks LSP
URL conversion.
Fixed by stripping the prefix ourselves in `SanitizedPath` before
handing off to dunce.
Before:
<img width="446" height="257" alt="Screenshot 2026-06-12 075128"
src="https://github.com/user-attachments/assets/4177e8de-8d13-42f1-a19b-d7dd52c10b32"
/>
After: (note the correct tooltip and the syntax error highlighting)
<img width="423" height="268" alt="Screenshot 2026-06-12 083651"
src="https://github.com/user-attachments/assets/83e98200-6bed-4a9e-b463-abbc067f6a5d"
/>
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)
— N/A, no UI changes
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable — one
extra string-prefix check per worktree creation
Release Notes:
- Fixed: language servers now run when opening files via UNC paths on
Windows (e.g. `\\server\share\file.txt`).
---------
Co-authored-by: Chris Biscardi <chris@christopherbiscardi.com>
## Objective
Import VS Code’s `files.exclude` into `file_scan_exclusions`.
The previous `files.watcherExclude` mapping was dead code: it expected
an array, while VS Code stores an object of `pattern: bool`.
`files.watcherExclude` only stops watching, and the files stay visible
in VS Code, so it is not a match for `file_scan_exclusions`.
`files.exclude` hides files from the explorer and search, which matches
`file_scan_exclusions`, and its default set is nearly identical to
Zed's.
Related to #62769, reported during the review of #64484. A meta
follow-up to #64399.
## Solution
Import nonempty `files.exclude` patterns enabled with `true`, ignoring
disabled and malformed entries, including VS Code's `{"when": ...}`
form.
Append `"..."` so the imported list extends inherited exclusions instead
of replacing them.
Inputs with no usable patterns leave the inherited list unchanged.
`files.watcherExclude` is no longer imported.
## Testing
The new regression tests reproduce the bug and verify the fix.
To check manually, import
`{"files.exclude":{"**/build/**":true,"**/cache/**":false}}` and verify
that `file_scan_exclusions` becomes `["**/build/**", "..."]`, and that
`.git` stays hidden in the project panel.
## 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 importing VS Code `files.exclude` into `file_scan_exclusions`.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
## Objective
Prevent one invalid file pattern from discarding valid patterns or
causing settings loading to panic.
The pre-existing exclusion-matcher bug was reported during review of
#64492 (part of #64399).
## Solution
Ignore invalid entries individually and log their errors in
`file_scan_exclusions`, `file_scan_inclusions`, `file_types`,
`hidden_files`, `private_files`, and `read_only_files`.
Preserve valid inherited entries without changing `"..."`, replacement,
or empty list behavior. Valid brace inclusion patterns remain usable,
including when an alternative spans multiple directories.
## Testing
Reproduced matcher loss and inclusion and file type panic paths before
fixing them. Targeted tests pass on macOS for mixed, inherited,
replacement, empty, and all-invalid lists, including inherited `.git`
exclusions, private file protections, and inclusion rescans with brace
patterns.
Windows and Linux execution remains untested.
## 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 invalid file patterns discarding valid exclusions, hidden file
rules, or read-only rules, or causing inclusion settings to panic. Also
fixed invalid private file patterns discarding valid protections and
invalid file type patterns causing settings loading to panic.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
## Objective
Closing a GPUI window on macOS does not release that window's native
view tree, so every
open/close cycle leaves a `GPUIView`, its `CAMetalLayer` and the
renderer's command queue
alive in the process. A long-running app that opens and closes windows
grows without bound;
this is the mechanism described in #50737.
The reason is a retain cycle:
```
MacWindowState
-> accesskit_adapter (crates/gpui_macos/src/window.rs:710)
-> NSWindow.contentView (strongly retained by accesskit_macos)
-> GPUIView (a subview of that content view)
-> Arc<Mutex<MacWindowState>> in its ivar (back to the start)
```
`accesskit_macos::SubclassingAdapter::for_window` keeps a strong
`Id<NSView>` of the
window's content view, and both the `NSWindow` and the `GPUIView` store
an
`Arc<Mutex<MacWindowState>>` in their `windowState` ivar.
`MacWindow::drop` resets the
delegate and tears down the frame source and the visibility callback,
but nothing drops the
adapter, so the native view tree outlives the window.
Worth noting while reading the existing teardown:
`gpui_apple::metal_renderer::destroy()`
is currently a no-op (`crates/gpui_apple/src/metal_renderer.rs`), so the
`renderer.destroy()`
call that is already there is not evidence that GPU-side resources were
released — what
matters is whether the state that owns the renderer can run its
destructor at all.
## Solution
One line in `MacWindow::drop`:
```rust
let mut this = self.0.lock();
drop(this.accesskit_adapter.take());
this.renderer.destroy();
```
Nothing else in the teardown changes:
- `frame_source.take()` stays. `WindowFrameSource`'s `Drop` cancels
`frame_requests`, and
that dispatch source's context points at the native view, so it has to
be cancelled while
the view is still valid.
- `visibility_callback.take()` stays, as do the sheet handling and the
delegate reset.
- No view or layer is released by hand. The native view is already
handed to its parent view
via `autorelease`; the problem is the cycle, not the ownership.
## Testing
Done locally on macOS (aarch64), with `stable`:
- `cargo fmt -p gpui_macos -- --check` — clean.
- `cargo test -p gpui_macos --lib` — 7 passed, 0 failed.
- `cargo clippy -p gpui_macos --release --all-targets --all-features --
--deny warnings` — clean.
Note: the adapter is only created when Zed runs with
`ZED_EXPERIMENTAL_A11Y=1`, so the leak
only affects that path and the fix is a no-op otherwise.
What isn't covered:
- **No automated test.** The cycle needs a real `NSWindow`/`contentView`
pair, and the change
is a `Drop` impl; a unit test here would be testing `NSView` ownership
rather than this
crate's logic. `gpui_macos` has no window-lifecycle test harness today,
and adding one is
more than this fix should carry.
- **No memory measurement by me.** I did not run
Instruments/`Allocations` against this
change, and the minimal-repro numbers quoted in #50737 were measured on
a different fork
revision, not this one. So the leak here is established from the
ownership graph above
rather than from a footprint curve I produced. The follow-up that would
settle it is a
before/after count of live `GPUIView` / `CAMetalLayer` / command-queue
objects after closing
a window, with accessibility enabled and disabled; I have not run that,
and I am not
claiming this explains every memory-growth report.
- Only the macOS backend is touched, so there is nothing
Windows/Linux-specific here.
## 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 (UI/UX and icon
guidelines) — no UI change
- [ ] Tests cover the new/changed behavior — not applicable, see "What
isn't covered"
- [x] Performance impact has been considered and is acceptable
## AI disclosure
Built with substantial LLM assistance: I had help reading the
`accesskit_macos` and
`gpui_macos` ownership graph and drafting this description, and I
reviewed every line of the
diff myself. The change is one line plus a comment. English isn't my
first language, so the
prose here was machine-polished; happy to restate anything in plain
terms.
---
Release Notes:
- [GPUI] Fixed a memory leak on macOS where closing a window with
accessibility enabled left its native view, `CAMetalLayer` and the
renderer's resources alive.
- Fixed a memory leak on macOS where closing a window left its native
view, `CAMetalLayer` and the renderer's resources alive.
## Summary
- Adds 63 internal links across 41 documentation pages.
- Connects existing terms such as Agent Panel, semantic tokens, edit
predictions, and language-specific debugging to their detailed reference
pages.
- Uses existing wording for 60 links and makes three small wording
changes where a natural anchor did not already exist.
## Why this matters
Readers can now move from overview and configuration pages to the
relevant detailed guidance without searching the documentation manually.
The changes add navigation only. They do not change product behavior or
documented requirements.
## Jev experiment
This PR came from a local experiment using Jev to audit internal links
across the published documentation. The audit scripts are not included
in this PR.
- Code shortlisted 2,715 possible source and destination page pairs.
- Jev made two separate decisions for each pair: whether the link would
help the reader, and which exact existing phrase should become the
anchor.
- Five strong links without existing anchor text went to GPT-5.6 Luna
for minimal rewrite options. Jev then selected among those fixed
options.
- A local review interface surfaced the results for Pass or Fail
decisions before any files changed.
Human review approved 66 changes. Two no longer matched the current
`main` branch, and review removed one circular link, leaving the 63
links in this PR.
## Validation
- `pnpm dlx prettier@3.5.0 <changed docs> --check`
- `lychee --exclude '^http' './docs/src/**/*'` — 0 errors
- `mdbook build docs`
- Verified that the diff adds exactly 63 Markdown links
Release Notes:
- Improved links between related documentation pages.
## Objective
Let projects add hidden file patterns without repeating defaults or
patterns inherited from user settings.
Part of
[#64399](https://github.com/zed-industries/zed/discussions/64399).
## Solution
Extend the `"..."` behavior from #62769, #64222, and #64440 to
`hidden_files`. `"..."` includes the resolved inherited list, omitting
it replaces the list, and `[]` clears it. Duplicate entries retain their
first occurrence.
The default remains `["**/.*"]`, and `project_panel.hide_hidden` still
controls visibility.
## Testing
Tested on macOS with settings merge, worktree integration, and Settings
Editor metadata tests.
To check manually, configure different user and project hidden file
patterns and enable `project_panel.hide_hidden`. Include `"..."` to
retain inherited patterns, then repeat without it and with `[]` to
verify replacement and clearing.
## 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:
- Added support for `"..."` in `hidden_files` so project settings can
extend inherited hidden-file patterns.
Following #41842, this is an extension to that contribution and it
enables `MicaBackdrop` and `MicaAltBackdrop` for
`"background.appearance"`
Release Notes:
- Add `MicaBackdrop` and `MicaAltBackdrop` to be selectable on themes
Additional Notes:
If PR is merged, theme schema should be updated to 0.2.1 or higher
---------
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
yenru0
