329142ebfcf45ecb4c1bf2142d1f4c84c64b1516
40074
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Tom Houlé
|
329142ebfc |
language_models: Remove Baseten provider (#64463)
Remove Baseten from the hosted language model provider protocol and cloud model routing. Release Notes: - N/A |
||
|
Piotr OsiewiczandAmp
|
f2af4a2804 |
Reduce nightly build cadence (#64557)
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> |
||
|
Kirill Bulatov
|
5a1c0e3da0 |
ci: Disable library backtrace capture in macOS test jobs (#64555)
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 |
||
|
Dom Porada
|
b015cdf8be |
Add support for the "..." entry in terminal.path_hyperlink_regexes (#64552)
## 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. |
||
|
Kirill Bulatov
|
a596e1b294 |
Speedup completions test (#64464)
Follow-up to https://github.com/zed-industries/zed/pull/64139 Fixes CI flacks like https://github.com/zed-industries/zed/actions/runs/35351932842/job/105623037967?pr=64405#step:15:7107 Halve the test runtime by avoiding the entire `MultiWorkspace` creation and redraws. Release Notes: - N/A |
||
|
Ben Brandt
|
50061c9cbd |
agent_ui: Make provider-owned terminals read-only (#64550)
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 |
||
|
Josh Kent
|
a18b1a1026 |
sidebar: Group threads sidebar settings (#64395)
## 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. |
||
|
|
180932e1d9 |
Prevent multibuffer items from switching active repository (#58795)
Fixes the git panel's active repository being silently overridden by the cursor position in `ProjectDiff`. Closes #58792 Closes #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-41e9fdd3dc96 Closes #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> |
||
|
Dom PoradaandKirill Bulatov
|
fbd6cc5dcf |
Add support for "..." in edit_predictions_disabled_in (#64546)
## 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> |
||
|
Kirill Bulatov
|
d1f71d8cd0 |
Fix ctrl/cmd-w closing the project panel instead of the active pane (#64515)
Closes https://github.com/zed-industries/zed/issues/34865 Closes https://github.com/zed-industries/zed/discussions/41122 Follows an Intellij Idea approach, where these bindings are separate. Release Notes: - Fixed `ctrl/cmd-w` closing the project panel instead of the active pane. BREAKING: closing the active dock moved from `cmd/ctrl-w` to `ctrl-alt-w` |
||
|
Dom PoradaandKirill Bulatov
|
3a7b16da5d |
Add support for "..." in edit_predictions.disabled_globs (#64540)
## 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> |
||
|
Ben Brandt
|
0ddd9c9863 |
acp: Fix provider-owned terminal lifecycle (#64544)
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. |
||
|
|
14d3c2b61c |
ui: Add buttons to switch diff view when diffing buffers (#64529)
# 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> |
||
|
Ben Brandt
|
c1053ff5fd |
acp_thread: Preserve ordered mixed content in agent messages (#64456)
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 |
||
|
Ben Brandt
|
3bf65364d6 |
acp: Update the ACP SDK to 2.2.0 (#64457)
Pick up the published ACP Rust SDK 2.2.0 release, including the schema 1.9.1 compatibility fix for agents returning `null` for empty/defaultable payloads. Upstream changes: - https://github.com/agentclientprotocol/agent-client-protocol/pull/2178 - https://github.com/agentclientprotocol/rust-sdk/pull/367 Release Notes: - acp: Fixed errors when ACP agents return `null` for empty response payloads. |
||
|
jliu666
|
dfeab92d8e |
gpui_util: Respect custom Scoop installation paths (#62473)
# 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> |
||
|
JoblenandChris Biscardi
|
73609ab13e |
Windows: Fix files opened by UNC path getting no language servers (#56553)
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> |
||
|
Kirill Bulatov
|
f2e3359972 |
Exclude non-Linux remote-server checks from the merge queue runs (#64528)
Given that the rest of the checks are run for Linux only in the merge queue, follow the pattern here too. Release Notes: - N/A |
||
|
Dom PoradaandKirill Bulatov
|
24f3009720 |
Import VS Code files.exclude into file_scan_exclusions (#64492)
## 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> |
||
|
Dom PoradaandKirill Bulatov
|
313f63eb71 |
Ignore invalid file patterns individually (#64525)
## 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> |
||
|
xiaofei
|
1f37291957 |
gpui_macos: Release the accessibility adapter when a window is dropped (#64143)
## 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. |
||
|
morgankrey
|
a439f856b8 |
Improve internal links across documentation (#64481)
## 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. |
||
|
Dom Porada
|
94436f0873 |
Add support for the "..." entry in hidden_files (#64484)
## 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. |
||
|
Marocco2andChristopher Biscardi
|
2c11b68c25 |
gpui: Add MicaBackdrop and MicaAltBackdrop to be selectable on themes (#48340)
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> |
||
|
Indy FuandChris Biscardi
|
a0f008b755 |
Fix Windows task path handling for worktree variables with spaces (#55727)
## Summary Fixes task variable resolution and Windows shell argument handling when `$ZED_WORKTREE_ROOT` contains spaces or when tasks are spawned while the global `tasks.json` buffer is focused. ## Problem `$ZED_WORKTREE_ROOT` could resolve from the active editor item even when that item was outside every visible project worktree, such as the global `tasks.json` file under the Zed config directory. On Windows, paths with spaces also need to remain one logical argument when terminal shell commands are constructed. ## Changes - Only let the active editor item provide the active task context when it belongs to a visible project worktree. - Fall back to the selected or first visible project worktree when the active editor item is external/global. - Preserve project-file-specific task variables for normal project buffers. - Add regression coverage for `$ZED_WORKTREE_ROOT` in `args` and `cwd` with synthetic Windows-style paths containing spaces. - Add regression coverage for PowerShell and cmd shell command construction so a spaced path remains quoted as one shell argument. ## Testing Ran on Windows with Rust 1.95.0, Visual Studio Build Tools 2022, and Windows SDK 10.0.26100.0: - `cargo fmt --all --check` - `cargo test -p util shell_builder::test::windows_powershell_preserves_spaced_arg_as_single_shell_argument -- --exact` - `cargo test -p util shell_builder::test::windows_cmd_preserves_spaced_arg_as_single_shell_argument -- --exact` - `cargo test -p task task_template::tests::test_worktree_root_with_spaces_stays_atomic_in_args_and_cwd -- --exact` - `cargo test -p tasks_ui tests::test_non_project_active_editor_uses_visible_worktree_context -- --exact` - `cargo test -p task` - `cargo test -p tasks_ui` - `cargo test -p workspace` Release Notes: - Fix Windows task path handling for worktree variables with spaces - [GPUI] N/A Co-authored-by: Chris Biscardi <chris@christopherbiscardi.com> |
||
|
Piotr OsiewiczandAmp
|
56ae3f4293 |
Install Linux dependencies for Wezel runs (#64475)
The first dispatched binary-size run failed while compiling `x11` because the stock `ubuntu-latest` image did not include Zed's Linux build dependencies. The old Wezel runner incorrectly reported that as a successful empty run. Run Zed's existing `./script/linux` setup before the Wezel action, matching Zed's Linux CI jobs. Release Notes: - N/A Co-authored-by: Amp <amp@ampcode.com> |
||
|
wezel-build[bot]andPiotr Osiewicz
|
58eb7e54a0 |
wezel: Add GitHub Actions runner (#64402)
This PR was created by [Wezel](https://wezel.build) to run assigned experiments in GitHub Actions. After merging it, add the runner token as the `WEZEL_RUNNER_TOKEN` repository secret. Release Notes: - N/A Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com> |
||
|
Piotr OsiewiczandAmp
|
f5966f7610 |
Replace incremental build scenario with binary size (#64453)
## Summary - remove the `incremental-editor` Wezel scenario and its source patch - build the `zed` binary with the release profile - track both its original size and the size of a separately stripped copy - lock the `exec` and `filesize` foragers and regenerate the experiment schema - skip the full Zed test suite when a pull request changes only `.wezel/**` ## Validation - `wezel project tool sync` - `wezel experiment lint` - `wezel project status` - smoke-tested the copy-and-strip command against a debug-symbol-bearing executable on macOS - `rustfmt --check tooling/xtask/src/tasks/workflows/run_tests.rs` - `actionlint .github/workflows/run_tests.yml` - exercised the CI path filter with Wezel-only, mixed, docs-only, and source-only file sets The full Zed release build was not run locally. Release Notes: - N/A --------- Co-authored-by: Amp <amp@ampcode.com> |
||
|
Azeem Shaik
|
c6f3347870 |
git_ui: Load diff buffers incrementally (#62536)
# Objective Opening a diff against a heavily drifted branch sits on a spinner until every changed file has loaded. Blob reads were serialized through the git job queue and enqueued in `open_buffer` completion order rather than path order, so the blob for the first excerpt could be hundreds of jobs deep. ## Solution 1. `load_blob_content` skips the job queue — blobs are content-addressed, so the read doesn't depend on the status snapshot. 2. `DiffBuffer::load` is a lazy future instead of an eagerly-spawned `Task`, so the consumer picks the concurrency. 3. `DiffMultibuffer` drives those loads through `buffered(16)`. All three are needed: dropping the queue without bounding forks thousands of `cat-file` processes, and bounding without dropping it still serializes. Trust handling is unaffected, since the untrusted-repo flags are applied in `GitBinary::build_command` rather than by the queue. Worth noting that `handle_get_blob_content` is remote-reachable, so a guest can now put up to 16 `cat-file` processes on the host instead of queueing them. ## Testing Added `project_diff::tests::test_excerpts_are_ordered_by_path`, which pins excerpt order to `PathKey` rather than to load completion order, using more files than the concurrency limit and several executor seeds. Green: `cargo test -p git_ui --lib` (131), `cargo test -p project --lib git_store` (11), `./script/clippy`. Not tested against a remote or collab project, which is where the `handle_get_blob_content` change actually matters. ### Numbers Zed repo against a base ~3000 commits back: 2346 changed files, 1794 with a blob at the merge base. Warm cache, one `cat-file` process per blob, best of two runs at each concurrency. | concurrency | total | per blob | speedup | |---|---|---|---| | 1 (previous behaviour) | 77.25s | 43.1ms | 1.00x | | 2 | 17.74s | 9.9ms | 4.35x | | 4 | 10.05s | 5.6ms | 7.69x | | 8 | 7.34s | 4.1ms | 10.52x | | 16 (this change) | 6.63s | 3.7ms | 11.65x | | 32 | 6.59s | 3.7ms | 11.73x | | 64 | 7.14s | 4.0ms | 10.82x | 16 is where the curve flattens: 32 buys another 0.7% and 64 regresses, so there's nothing above it worth the extra in-flight buffers or the extra concurrent processes on a host serving a remote peer. At one blob at a time the first excerpt waits at an arbitrary position in a 1794-deep queue, so roughly 38s on average, which lines up with the 45s full load in the recording below. It's now in the first batch. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments — none added - [x] The content adheres to Zed's UI standards — no UI changes - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable ## Showcase Opening a branch diff against a base ~3000 commits back, 2346 changed files. Both clips are cut to 15s to keep the file size down — the before run took 45s to finish loading. **Before** https://github.com/user-attachments/assets/d9475de8-ddd3-48a0-99e2-042a2f655b42 **After** https://github.com/user-attachments/assets/0bf0e73d-0fac-4c2a-9749-71fee376f260 --- Release Notes: - Improved how quickly a branch diff shows its first changes when the branch has drifted a long way from its base |
||
|
Dom Porada
|
25fccf11c1 |
Align "..." documentation for file pattern settings (#64452)
## Objective Make the `"..."` convention easier to understand across the settings that support it. This is a meta follow-up to [#64399](https://github.com/zed-industries/zed/discussions/64399), establishing a documentation pattern that subsequent PRs can follow. ## Solution Give each setting a succinct, self-contained explanation of `"..."`, with matching wording and examples in its Rust doc comment and settings reference: - `file_scan_exclusions` • #62769 - `file_scan_inclusions` • #64440 - `read_only_files` • #64222 This keeps the explanation consistent across both surfaces and aligns the content for future documentation generated from Rust comments. ## Testing Built the docs locally on macOS and verified the examples, links, and anchors. The existing settings merge tests pass. ## Self-Review Checklist: - [x] I’ve reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed’s UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - N/A |
||
|
Agus Zubiaga
|
c5d6f0b2ca |
language_model: Allow explicit prompt cache keys (#64460)
## Objective Related conversations can’t share an OpenAI cache key without also sharing a thread ID. We currently derive `prompt_cache_key` directly from `thread_id`, tying cache reuse to conversation identity. ## Solution Add an optional `prompt_cache_key` to `LanguageModelRequest` and use it in both OpenAI Chat Completions and Responses conversions. We still fall back to `thread_id` when no key is supplied, so existing callers keep their current behavior. This lets callers share a cache key across parent and child conversations while keeping their conversation and transport identities separate. ## Testing Added regression coverage for explicit keys, legacy fallback, provider capability gating, and serialization compatibility. ## 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: - N/A |
||
|
zhujiatao
|
31c3c86010 |
terminal: Release the parse buffer once a command finishes (#64405)
# Objective Fix memory a terminal never gives back after its command finishes. Each `terminal::Terminal` constructed a `vte::ansi::Processor`, and `Processor::new` reserves `SYNC_BUFFER_SIZE` (2 MiB) up front for synchronized updates. `Terminal::release_pty_resources` tore the PTY down once the command exited but left that reservation in place, so it lived exactly as long as the terminal did. That matters because the terminal outlives the command: the agent panel keeps each tool call's terminal so it can keep rendering the finished command's output (`ToolCallContent::Terminal(Entity<..>)`, `acp_thread.rs:2014`), and the panel's own terminal map is only cleared through `TerminalEvent::CloseTerminal`, which a task terminal never emits because `SpawnInTerminal::default()` sets `hide = HideStrategy::Never`. Measured on a release build running 50 agent commands (`ls`): peak heap 205.34 MB, 200.52 MB still retained at exit, and the heap grew in a staircase that never came back down (75 MB to 192 MB between 288s and 300s, then flat). heaptrack attributed the largest share, 104.00 MiB, to exactly 52 of these reservations (109,051,904 bytes = 52 x 2,097,152), all allocated from `TerminalBuilder::new` (`crates/terminal/src/terminal.rs:1309`) and never freed. So this costs roughly 2 MB per command for as long as its terminal is kept around. ## Solution - `output_processor` is only used by `Terminal::write_output`, which parses bytes *injected* into the terminal (init commands, terminal providers, the REPL). PTY output goes through the `alacritty_terminal` event loop's own parser, not this one. - Make the field an `Option`, create it on the first injected byte instead of at construction, and drop it in `release_pty_resources`, right after the PTY is torn down. - It is recreated if something injects bytes again, so `write_output` semantics do not change for terminal providers or init-command injection. As a side effect, terminals that never receive injected bytes no longer reserve the parser at all, even while they are live. ## Testing Added `tests::test_release_pty_resources_drops_an_allocated_parse_buffer` in `crates/terminal/src/terminal.rs`. It runs `echo` to completion in a task terminal the way an agent tool call does, and asserts the parse buffer's lifecycle directly on the terminal: - a terminal that received no injected bytes holds no parse buffer; - `write_output` builds one; - `release_pty_resources` drops it, while the output the terminal already captured is still readable; - injecting again after the release builds a new one. Asserting on the terminal's own state instead of on process-wide heap keeps PTY reader threads out of the measurement: they reserve parse buffers of their own and are torn down asynchronously, so a heap-based assertion would depend on a timing the test cannot synchronize with. Removing `self.output_processor = None` from `release_pty_resources` fails the test with `releasing the PTY should drop the parse buffer`. - `cargo test -p terminal`: 107 tests, all green. - `./script/clippy -p terminal`: clean. Tested on Linux. The fix and the test are platform-independent Rust (neither is behind a `cfg`, and Windows takes the same `TerminalType::Pty` branch), so I expect the same behaviour on macOS and Windows, but I have not verified it. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content 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 ## Suggested .rules additions Found while working on this, proposed rather than edited inline, per the rules-hygiene section. - `webrtc-sys`'s build script never reuses its prebuilt download: on every run it deletes the extracted package and re-downloads 131 MB from the GitHub release, and every distinct unit gets its own `OUT_DIR` and therefore its own copy (a debug build, a release build, and rust-analyzer's `cargo check --all-targets` are at least three). A build that appears to hang indefinitely at `webrtc-sys(build)` with no output is this. Avoid it by extracting the release asset once outside `target/` and setting `LK_CUSTOM_WEBRTC` to that directory through the user-level cargo config, so rust-analyzer's background checks inherit it too: ```toml # ~/.cargo/config.toml [env] LK_CUSTOM_WEBRTC = "/home/<user>/.local/share/libwebrtc/webrtc-0001d84-4/linux-x64-release" ``` `webrtc_sys_build::download_webrtc` returns early whenever that variable is set. If the path goes stale (the prebuilt is tagged, e.g. `webrtc-0001d84-4`), the build fails to link, so the variable has to be updated when the tag changes. --- Release Notes: - Fixed terminals retaining about 2 MB of memory per command after the command had finished |
||
|
Piotr Osiewicz
|
c1b19374f4 |
collab: Drop old rustls dependencies (#55632)
## Summary - Disable legacy default TLS features for the collab AWS SDK clients - Use the current AWS HTTP client and Rustls dependency chain ## Verification - `cargo check -p collab --locked` - `cargo fmt --all -- --check` - Confirmed the collab dependency tree excludes rustls 0.21, hyper-rustls 0.24, and tokio-rustls 0.24 Release Notes: - N/A |
||
|
rn23thakurandSmit Barmase
|
108fd3ac11 |
editor: Fix vertical scroll margin calculation (#63944)
# Objective - Fixes an issue where setting an arbitrarily high `Vertical Scroll Margin` fails to perfectly lock the cursor in the center of the viewport (Typewriter Mode?). In certain cases one could go up/down a line before auto-scroll gets triggered, deviating from user intent. - Fixes #63862 ## Solution - **The Issue:** When `Vertical Scroll Margin` is very high, the effective margin applied above and below the cursor is derived from the viewport's free space: ```rust ((visible_lines - (target_bottom - target_top)) / 2.0).floor() ``` - **The Fix:** Instead of using the same rounded number for both the top and bottom margins, calculate them separately: 1. The top margin stays the same as before. 2. The bottom margin is calculated by subtracting the top margin from the total free screen space. - This ensures the bottom margin automatically catches whatever fraction the floor operation on the top margin drops, so the two margins always sum to the full available space. ## Testing - Did you test these changes? If so, how? Ran `cargo test -p editor`, all passed. I've also attached the results of manual testing in the Showcase section 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)](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)](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 and after screen recording <details> <summary>Click to view showcase</summary> **Before:** https://private-user-images.githubusercontent.com/63847494/646999418-4dd388b8-4aba-4004-ac4f-6f1e0dad0f70.mp4?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODg5MTE3MTUsIm5iZiI6MTc4ODkxMTQxNSwicGF0aCI6Ii82Mzg0NzQ5NC82NDY5OTk0MTgtNGRkMzg4YjgtNGFiYS00MDA0LWFjNGYtNmYxZTBkYWQwZjcwLm1wND9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA5MDglMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwOTA4VDIzNTAxNVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWRhZGM5MWExMDkyMDIzZjVlYjcxYmQ4YTRmOTM3MDliNDcyOTUzZjFhYmY1ZTgwMDY0YzhlYmQ1NzllYWYyN2EmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT12aWRlbyUyRm1wNCJ9.DG6RpiEM-781ZctlvtQeWhw3kAYJ4KS6rNsAmMU38fg **After:** https://github.com/user-attachments/assets/4bf870e0-84ba-449a-bf2a-925c4a90d5ed </details> Release Notes: - Fixed the cursor not staying perfectly centered when using a high Vertical Scroll Margin (Typewriter Mode). --------- Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com> |
||
|
Kirill Bulatov
|
1753d7f52b |
Share GPUI and scheduler implementations (#64261)
Move GPUI window/entity updates, view rendering, listener adapters,
arena allocation, and scheduler task setup into shared implementations.
Keep the generic entry points as thin adapters.
Uses pretty much the same technique prior PRs did, but this time on
`gpui` which I am not too confident about — can close it if seems
dangerous, but the binary strip win looks good to try.
`cargo llvm-lines --locked -p gpui`:
Before (
|
||
|
Kirill Bulatov
|
87d3b5fdfd |
Disable share generics to reduce the binary size more (#64335)
After the new macOS nightly with https://github.com/zed-industries/zed/pull/64260 arrived, I've noticed that the binary had actually bloated back — run some bisecting and build comparison, and seems that the shared generics are the culprit. Platform / executable | Sharing enabled | Sharing disabled/default | Reduction | |---|---:|---:|---:| | macOS ARM64 editor | 304,794,488 bytes | 266,242,792 bytes | **38,551,696 bytes / 12.65%** | | Linux x86_64 editor | 334,001,336 bytes | 325,916,104 bytes | **8,085,232 bytes / 2.42%** | | Linux x86_64 remote server | 123,618,032 bytes | 106,211,592 bytes | **17,406,440 bytes / 14.08%** Each pair uses the same checkout and Rust **1.98.1**, was built with the bundling script: - macOS: `e0590874fd`, measured after `strip -x`. - Linux: `b664a4004269`, measured after `llvm-objcopy --strip-debug --discard-all`. The Linux section changes when disabling sharing are: | Component | Editor | Remote server | |---|---:|---:| | Retained `.symtab` + `.strtab` | **−47,560,049 bytes** | **−17,733,989 bytes** | | Allocated file-backed sections | +39,475,120 bytes | +327,448 bytes | | Headers, padding, and other bytes | −303 bytes | +101 bytes | | **Total** | **−8,085,232 bytes** | **−17,406,440 bytes** | Release Notes: - N/A |
||
|
Dom Porada
|
2229b4e2d6 |
Add support for the "..." entry in file_scan_inclusions (#64440)
## Objective Let projects add inclusion patterns without repeating defaults or patterns inherited from user settings. Part of #64399. ## Solution Extend the `"..."` behavior from #62769 and #64222 to `file_scan_inclusions` using the shared merge implementation. `"..."` includes the resolved inherited list, omitting it replaces the list, and `[]` clears it. Duplicate entries retain their first occurrence. Stop importing VS Code’s `files.watcherInclude` as inclusion patterns because it configures additional watch roots rather than overriding Git ignores. ## Testing Tested on macOS with settings merge, VS Code import, and worktree integration tests. Coverage includes preservation of the `.env*` default, layered inheritance, replacement, clearing, and deduplication. The worktree test verifies that inherited and project-specific patterns include Git-ignored files while exclusions still take precedence. To check manually, configure different user and project inclusion patterns and add ignored files matching each. Include `"..."` to retain inherited patterns, then repeat without it and with `[]` to verify replacement and clearing. Confirm that excluded files remain absent. ## 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 `file_scan_inclusions` so project settings can extend inherited inclusion patterns. |
||
|
Matei OpreaandSmit Barmase
|
18960e899a |
git: Fix git info exclude action for worktrees (#63967)
# Objective - This PR fixes #63760. According to git docs "Patterns read from $GIT_DIR/info/exclude". ## Solution - We were reading the directory's absolute path instead of reading the absolute path to the repository's common .git directory. ## 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 --- Release Notes: - Fixed "Add to .git/info/exclude" not working when used from a secondary git worktree --------- Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com> |
||
|
Cameron Mcloughlin
|
3eddbb7f4e |
gpui: Fix debug selectors with cached views (#64433)
The debug-selector test mapping skipped cached views that weren't rendered. Make sure we include them --- Release Notes: - [GPUI] N/A |
||
|
Smit Barmase
|
ae59a5be17 |
sidebar: Fix selection highlight flickering when clicking terminal threads (#64387)
Clear keyboard selection when clicking a terminal thread, as we already do for agent threads. The old test cleared selection itself instead of clicking a row. Replace it with seven scoped tests: | Test | Action | Expected result | |---|---|---| | Different terminal | Terminal A → click Terminal B | B active, selection cleared | | Same terminal | Terminal A → click Terminal A | A still active, selection cleared | | Different thread | Thread A → click Thread B | B active, selection cleared | | Confirm terminal | B active, A selected → Confirm | A active, A still selected | | Confirm thread | Thread A selected → Confirm | A active, A still selected | | Refocus without selection | Focus outside → sidebar | Search focused, selection still empty | | Refocus with selection | Focus outside → sidebar | List focused, selection preserved | Each click test starts with the source item active and keyboard-selected, with the sidebar list focused so the keyboard highlight is visible. Before: https://github.com/user-attachments/assets/eee8bc47-e962-402f-9268-8134dc20ba5b After: https://github.com/user-attachments/assets/a437f4c8-b2c0-47d8-99c6-c4600b49c359 Release Notes: - Fixed the selection highlight flickering in the sidebar when clicking terminal threads. |
||
|
Piotr Osiewicz
|
967a49ff34 |
ci: Gate test execution on check_style passing (#64408)
Release Notes: - N/A |
||
|
restlessroninandClaude Opus 5
|
99dddba6b8 |
agent_ui: Stop the sidebar creating two terminals for one new entry (#62151)
# Objective Starting a new terminal thread from the agent sidebar creates **two** terminals instead of one, in a project that has no terminals yet. With terminals already open, only one is created. ## Solution `Sidebar::create_new_terminal` calls `AgentPanel::new_terminal` and then focuses the panel. The spawn is async, so when `focus_panel` activates the panel, `base_view` is still `Uninitialized` — and `ensure_thread_initialized` reads that as an empty panel and spawns its own "initial" terminal on top of the one already in flight. Once terminals exist they are restored at panel load, so `base_view` is already `Terminal` and the second spawn never happens. That's why the bug only appears on a project with no terminals. `restore_terminal` already guarded against this by marking the spawn pending before calling `spawn_terminal`. This moves that marker into `spawn_terminal` itself, so every spawn path arms it, and drops the now-redundant assignment in `restore_terminal`. The marker is cleared exactly where it already was: when the terminal lands, when the spawn fails, and when the terminal is closed. ## Testing - Added `test_new_terminal_prevents_initial_terminal_creation`, which reproduces the sidebar's spawn-then-focus sequence. It fails without the fix (the panel ends up with two terminals) and passes with it. - `cargo test -p agent_ui --lib` — 405 passed. - `cargo test -p sidebar --lib` — 142 passed. - `./script/clippy -p agent_ui` — clean. - Tested on macOS only. The race is platform-independent, but I can't exercise the Linux/Windows terminal spawn paths. ## Self-Review Checklist: - [X ] I've reviewed my own diff for quality, security, and reliability - [ X] Unsafe blocks (if any) have justifying comments - [ X] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [ X] Tests cover the new/changed behavior - [ X] Performance impact has been considered and is acceptable --- Release Notes: - Fixed the agent panel creating two terminals when starting a new terminal thread in a project with no existing terminals --------- Co-authored-by: Claude Opus 5 <claude-opus-5@claude-cli> |
||
|
Anant Goel
|
30ba5d4ddb |
open_ai: Add GPT-6 Astra API support (#64420)
## Objective Make GPT-6 Astra selectable through the OpenAI API-key provider. The built-in catalog omitted it, even though it was available through the separately fetched ChatGPT subscription catalog. ## Solution Add `gpt-6-astra` with its documented context/output limits, reasoning efforts, image support, and Responses capabilities. Existing model defaults remain unchanged. Handle two API compatibility differences found during review: Astra rejects `temperature`, and its Fast-mode responses return `service_tier: "fast"` even when requested as `"priority"`. Both request converters now omit Astra's temperature, and response decoding accepts the new spelling while preserving legacy serialization. Two focused regressions cover these failures without duplicating the catalog declaration. References: [Astra model](https://developers.openai.com/api/docs/models/gpt-6-astra), [migration guide](https://developers.openai.com/api/docs/guides/latest-model?model=gpt-6-astra), [Fast mode](https://developers.openai.com/api/docs/guides/fast-mode). ## Testing - `corgi test -p open_ai --lib`: 88 passed. - `corgi check -p language_models --lib`: passed. - `corgi fmt -p open_ai -p language_models -- --check` and `git diff --check`: passed. - Live API probes confirmed model availability, a successful Responses function-tool call with parallel calls enabled, the `fast` response spelling, and rejection of configured temperature. - During development, Delta's existing API-key catalog test passed with a temporary local dependency override and an Astra frontier expectation. The override was removed; Delta's dependency bump is separate. - Validation was on macOS. No interactive picker, browser, or Cloud Runner workflow was exercised; image input, compaction, and Fast-mode regional availability were checked against the docs rather than live workflows. ## Before merge The README contains the repository-required human-review confirmation marker. The author must remove it after reviewing. Delta will need a separate dependency bump after this change lands. Cache-preserving reasoning-effort updates are outside this change. Release Notes: - Added GPT-6 Astra to the OpenAI API-key model picker. |
||
|
Hyeondong Lee
|
6eb036cfb1 |
Fix casing of libX11-devel SUSE package in script/linux (#64411)
## Objective `libx11-devel` is not a valid package name in SUSE: it should be`libX11-devel` (_should be a capital X!_). source: [RPM resource libX11-devel](https://rpmfind.net/linux/rpm2html/search.php?query=libX11-devel) ## Testing - [x] Did you test these changes? If so, how? - Tested on SLES 15.7 an [openSUSE Tumbleweed](https://software.opensuse.org/package/libX11-devel) - `script/bundle-linux` succeeds <img width="675" height="175" alt="Screenshot 2026-09-18 at 02 43 41" src="https://github.com/user-attachments/assets/4a89f6e5-de9f-4457-a6c2-8f5a15ad4283" /> --- Release Notes: - N/A |
||
|
Dom Porada
|
13b33084ab |
Document hidden_files setting (#64403)
## Objective While suggesting #64399, I realized `hidden_files` didn’t have an entry in the settings reference. This PR fills that gap. ## Testing Checked the descriptions against the implementation and existing 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: - N/A |
||
|
zooeywmandChris Biscardi
|
42038d0b14 |
gpui: Fix manifest path for cross-compilation (#62525)
# Objective Fixes #62522 `cargo xwin` fails to find the GPUI Windows manifest because `llvm-rc` resolves the path from the resource directory. ## Solution Reference the manifest relative to `gpui.rc` and explicitly add the resource directory to the include paths. This keeps both native Windows and xwin builds working. ## Testing - Tested with `cargo xwin clippy --target x86_64-pc-windows-msvc` ## Self-Review Checklist - [x] I've reviewed my own diff for quality, security, and reliability - [x] Performance impact has been considered and is acceptable --- Release Notes: - N/A - [GPUI] N/A --------- Co-authored-by: Chris Biscardi <chris@christopherbiscardi.com> |
||
|
Habis AhmadandChris Biscardi
|
2c8f682cd5 |
gpui: Fix centered window bounds to display settings header (#62073)
# Objective - Fixes https://github.com/zed-industries/zed/issues/61914 - The setting window gets cut off from the top of the screen when using a high DP on Windows (e.g. 250% 2560×1600). This is because `Bounds::centered` computes a wide rectangle with `origin = display.center() - size / 2` which can cause issues on higher DPI. ## Solution `Bounds::centered` now centers within the display's work area. ```rust let visible_bounds = display.visible_bounds(); Bounds::centered_at(visible_bounds.center(), size.min(&visible_bounds.size)) ``` Added visible_bounds() and size.min(&visible_bounds.size). Size::min will clamp each axis, windows that already fit are unaffected ## Testing - Reproduced the bug locally and on production that the settings header does not get clipped anymore; the video showcase shows this. ## 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/5cafd03c-7835-488c-a70b-ba559e4cfff3 0:00 - 0:11. Current behaviour in production, settings header gets clipped at 225% 0:11 - 0:20. My fix, header does not get clipped Release Notes: - Fixed the Settings window opening with its header off-screen at high DPI scaling on Windows - [GPUI] N/A Co-authored-by: Chris Biscardi <chris@christopherbiscardi.com> |
||
|
Vlad GaevskyandChris Biscardi
|
55387ea4b7 |
gpui_windows: Keep DirectWrite's default ligatures when no font features are set (#62338)
On Windows, ligatures are off by default: they only show up if `buffer_font_features` is set to something non-empty. `generate_font_features` always creates an `IDWriteTypography` and passes it to `apply_font_features` (`direct_write.rs:446-452`), and the layout code calls `SetTypography` with it unconditionally (`:567`, `:605`). `apply_font_features` returned early when no features were configured, so an empty typography object reached DirectWrite. `SetTypography` replaces the default feature set with exactly what the typography contains, so `liga`, `clig` and `calt` ended up disabled. Dropping the early return lets the rest of the function run, which adds `liga`, `clig` and `calt` at 1. Users who configure features explicitly are unaffected: that path already ran before this change, and an explicit `liga: 0` still resolves to 0 through the same loop. I went with this rather than guarding the two `SetTypography` calls, because the function already owns the knowledge of which features DirectWrite enables by default for the non-empty case, and guarding the call sites would duplicate it in two places. Other platforms are not affected: `generate_feature_array` on macOS (`gpui_macos/src/open_type.rs:77`) appends one dictionary per configured tag and does not replace the default feature set when the list is empty. No test here: `apply_font_features` takes a live `IDWriteTypography` from `CreateTypography()`, so covering it needs a real DirectWrite factory and cannot run off Windows. I can extract the tag resolution into a pure function and unit test that separately if you would prefer it. Checked on a Windows build with no `buffer_font_features` set: ligatures render with this change and are absent without it. Release Notes: - Fixed ligatures being disabled on Windows unless `buffer_font_features` was set - [GPUI] N/A Co-authored-by: Chris Biscardi <chris@christopherbiscardi.com> |
||
|
Minh VuandChris Biscardi
|
836c68bb20 |
gpui_windows: Fix reversed linear/sRGB transfer functions in shader (#57543)
## Summary - swap the Windows HLSL exponents for `linear_to_srgb` and `srgb_to_linear` - align the Windows Oklab gradient path with the existing Metal and WGSL implementations ## Testing - not run (shader-only change) Fixes #57542 Release Notes: - [GPUI] Fix reversed linear/sRGB transfer functions Co-authored-by: Chris Biscardi <chris@christopherbiscardi.com> |
||
|
Ben Brandt
|
1cea5261a1 |
agent_ui: Fix keyboard navigation in ACP elicitation forms (#64193)
Closes #61358 Address the keyboard-navigation portions. Image answers are intentionally not included. ACP form responses support primitive values rather than image attachments, and Claude Code's adapter treats the "Other" answer as text. This PR therefore only partially addresses the issue. Release Notes: - acp: Fixed submitting and navigating ACP elicitation forms with the keyboard. |