4f047acc1780eceed5be1f3dfd3f9ee652ed14cb
39372
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Ben Kunkle
|
4f047acc17 |
edit_prediction: Prevent v4 cursor marker leaks (#61957)
# Objective Prevent V4 cursor markers from appearing in edit prediction previews or accepted edits. ## Solution Replace the cursor marker with an internal sentinel before sub-line diffing, so matching source text cannot reconstruct the marker. ## 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 |
||
|
Yassen Damyanov
|
b209000d28 |
Make Install script reject 32-bit Linux architectures (#61919)
# Objective Prevent successful installations on 32-bit Linux architectures where the `zed` binary will **fail to execute** post-installation. Rather, fail at installation time with a proper verdict. `script/install.sh` maps `uname -m` onto the two architectures Zed publishes builds for. Two of the matchers named 32-bit userlands and mapped them onto a 64-bit tarball: - `linux-armhf` mapped to `aarch64` - `linux-i686*` mapped to `x86_64` Neither can execute the binary it selected. Tested on i386 Debian Trixie container: the installer downloaded, unpacked, symlinked and reported success, and the failure surfaced later as an exec error -- see [Showcase](##showcase). Thus the installer's correct behavior would be to reject the 32-bit architecture and terminate with an "unsupported" verdict. ## Solution Remove the case-statement-based mapping of `linux-armhf` to `aarch64`, and of `linux-i686*` to `x86_64`. ## Testing Tested in isolation, simulating supported and unsupported platforms, and supported and unsupported architectures: | Platform | `uname -m` | Outcome | | --- | --- | --- | | Linux | `x86_64` | ✅ Installed — resolves to `x86_64`, symlink created | | Linux | `i386` | ❌ Unsupported — `i386` doesn't match glob `x86*` (no case handles plain i386 anyway | | Linux | `i686` | ❌ Unsupported — same reason | | Linux | `aarch64` | ✅ Installed — resolves to `aarch64` | | Linux | `arm64` | ✅ Installed — resolves to `aarch64` | | Linux | `armv7l` | ❌ Unsupported — no 32-bit ARM case | | Linux | `riscv64` | ❌ Unsupported | | Darwin | `arm64` | ✅ Installed — resolves to `aarch64`, copied to real `/Applications/Zed.app`, symlink created; | | Darwin | `x86_64` | ✅ Installed — resolves to `x86_64`, copied to real `/Applications/Zed.app`, symlink created | | Darwin | `i386` | ❌ Unsupported — no case for macOS 32-bit | | FreeBSD | `x86_64` | ❌ Unsupported platform - expected | This is all correct behavior. Successful installations are expected to work. Unsupported architectures are detected and rejected as unsupported during installation. ## Showcase ```plaintext ~# file /usr/bin/dash # a sample executable showing the 32-bit arch /usr/bin/dash: ELF 32-bit LSB pie executable, Intel i386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=7e2e8652114c8c2ae595b6f78798716a9ba07671, for GNU/Linux 3.2.0, stripped ~# file .local/zed.app/bin/zed .local/zed.app/bin/zed: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=e550eeb1d97f0cdac2460de672bfa36e9e3f6e25, not stripped ~# .local/zed.app/bin/zed bash: .local/zed.app/bin/zed: cannot execute: required file not found # It cannot find ELF 64-bit interpreter /lib64/ld-linux-x86-64.so.2 -- this is # a 32-bit container on a 64-bit host. On a genuine 32-bit host it would fail with: # `Exec format error`. ``` ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Locally conducted tests cover the new/changed behavior --- Release Notes: - N/A |
||
|
Tai Nguyen
|
a5615f092d |
Reset panel saved size when default_size changes (#61855)
Closes #59235 When a panel's `default_size` changes (e.g. `git_panel.default_width` is edited in settings), the persisted per-workspace size is now cleared so the new default takes effect immediately. Previously the saved dragged size took precedence forever, making `default_width` effectively useless after the first manual resize. This fix is at the Dock level (`crates/workspace/src/dock.rs`), so it applies to all panels — Git Panel, Project Panel, Terminal Panel, etc. Release Notes: - Fixed panel `default_width` setting being ignored after manually resizing the panel https://github.com/user-attachments/assets/97ef69b2-387f-4e29-bc4c-0f336f24eb0b |
||
|
Tim Vermeulen
|
0b3621db47 |
terminal_view: Fix inline terminal clipping its first line of output (#61939)
Fixes #53518: | before | after | | --- | --- | | <img width="790" height="458" alt="before" src="https://github.com/user-attachments/assets/2314fb13-6782-4397-a022-0252c82bf7b9" /> | <img width="790" height="458" alt="after" src="https://github.com/user-attachments/assets/1058970c-ae0a-4a9f-8f14-84b810ddaba4" /> | `TerminalBounds::line_height` floors `height / line_height`, so `TerminalElement::request_layout` does the inverse logic to calculate the height for inline terminals with `displayed_lines * line_height`, but intermediate rounding in `to_taffy` could break this. Fixed by rounding up to the next integer device pixel in `TerminalElement::request_layout`. ## 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 first line of terminal output sometimes being hidden in the agent panel. |
||
|
Rabindra Kumar Meher
|
864ff0ba3f |
Run string-form dev container lifecycle commands in /bin/sh -c (#60792)
# Objective Fixes #60228. String-form dev container lifecycle commands are currently executed by splitting the command on spaces and running the first token directly. This means shell features such as variable expansion, pipes, redirection, and command chaining do not work. According to the Dev Container specification, string-form lifecycle commands should run through `/bin/sh -c`, while array-form commands should continue to execute directly. ## Solution - Added `LifecycleScript::shell_command()` to wrap string-form commands in `/bin/sh -c`. - Updated string deserialization to use `shell_command()` instead of splitting on spaces. - Kept array-form commands unchanged. ## Testing - Ran `cargo test -p dev_container` (107 tests passed). - Added a regression test to verify string-form commands run through `/bin/sh -c`. - Added a regression test to verify array-form commands still execute directly. - Updated the existing deserialization tests to match the expected behavior. ## 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 behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - Fixed string-form dev container lifecycle commands so they execute through `/bin/sh -c` as required by the Dev Container specification. |
||
|
9rum
|
58a3c0fa0e |
docs: Fix mismatch of default dock position setting in project panel (#61971)
# Objective Fixes #56277, the document-source mismatch of the default dock position setting in project panel. I also have found that the visual customization guide has the same issue, so this PR fixes it too. ## Solution I have updated the corresponding markdown files. ## Testing I have tested the updated documents by rendering them in my local. ## 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 |
||
|
AidanVandLukas Wirth
|
5f180e06dc |
editor: Add multiple_selections key context (#60018)
# Objective - I would like to have the Vim command `z z` do different actions depending on if I have multiple selections. If I only have one selection I want `z z` to center my only selection (current behavior); however, if I have multiple selections I would like `z z` to run `editor::OpenSelectionsInMultibuffer`. This PR does not add this specific functionality (happy to be convinced otherwise), but it does let users add this type of functionality. ## Solution - Add a new key context field that is active only when there are multiple selections. ## Testing - Changes are quite small. A test on this would really be testing other parts of the code-base more than this change. ## 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/2559e218-d6fa-492a-949b-f4ab8b880f28 This allows us to add something like the following to the `keymap.json`: ```json { "context": "VimControl && !menu && multiple_selections", "bindings": { "z z": "editor::OpenSelectionsInMultibuffer", }, }, ``` which lets us change the functionality of a keystroke based on if there are multiple selections. This video has the following keystroke sequence: `z z` (Center the cursor normally) `5 g l` (Select the 5 next occurrences of the word under the cursor) `z z` (Open selections in multi-buffer) (Previously `z z` in this context would just center the last selection) https://github.com/user-attachments/assets/a0dc1813-5420-4cda-a1ec-99e6681680e7 --- Release Notes: - Added `multiple_selections` keystroke context Co-authored-by: Lukas Wirth <lukas@zed.dev> |
||
|
aetos
|
2ec2997789 |
Honor window preference when opening remote projects (#61048)
# Objective Fixes #60873. `projects::OpenRemote` has two handling paths: - The remote-project picker handles `from_existing_connection: false`. - The active remote workspace handles `from_existing_connection: true`. The existing-connection path ignored the action’s `create_new_window` field. Consequently, selecting another project from an active SSH workspace always created a new OS window—even when: - the action explicitly specified `create_new_window: false`, or - `create_new_window` was omitted and `default_open_behavior` was set to `"existing_window"`. The expected behavior is: | `create_new_window` | `default_open_behavior` | Result | |---|---|---| | `true` | Any value | Open a new window | | `false` | Any value | Reuse the current window | | Not specified | `"new_window"` | Open a new window | | Not specified | `"existing_window"` | Reuse the current window | ## Root cause The `from_existing_connection: true` action handler forwarded the selected paths to `open_new_ssh_project_from_project` without reading `action.create_new_window`. That helper then called `open_remote_project` with: ```rust OpenOptions { workspace_matching: WorkspaceMatching::None, ..Default::default() } ``` This left `OpenOptions::requesting_window` as `None`. The remote-opening path interprets a missing requesting window as a request to create a new window, so the action always opened one regardless of the action payload or workspace setting. ## Solution The existing-connection action handler now resolves `create_new_window` before starting the asynchronous open operation. When the action does not provide an explicit value, it uses the same `WorkspaceSettings::default_open_behavior` fallback as the normal project-opening path: ```rust let create_new_window = action.create_new_window.unwrap_or_else(|| { matches!( WorkspaceSettings::get_global(cx).default_open_behavior, DefaultOpenBehavior::NewWindow ) }); ``` The resolved boolean is passed to `open_new_ssh_project_from_project`. The helper translates that policy into the existing `OpenOptions` API: - When `create_new_window` is `true`, `requesting_window` remains `None`. - When it is `false`, `requesting_window` is set to the current `MultiWorkspace` window handle. The existing `WorkspaceMatching::None` behavior is intentionally preserved. This PR changes only which OS window hosts the opened remote workspace; it does not change workspace matching, path selection, connection handling, telemetry, or error behavior. ### Why resolve the setting in the action handler? The action handler is where the explicit action value and the workspace setting are both available. Resolving the option there also matches the neighboring local and remote project-opening flows. Passing the resolved boolean keeps the helper’s input aligned with the user-facing policy while allowing the helper to translate it into the lower-level `requesting_window` representation. ### Why not change `open_remote_project`? `open_remote_project` is shared by several remote-opening flows. Inferring an active window inside that function would change the semantics of unrelated callers that deliberately omit `requesting_window` to create a new window. Keeping the change in the existing-connection action path limits the behavioral change to the reported issue. ### Dependency impact The regression test needs a real mock remote workspace so that it exercises the same action registration and remote-client checks as the application. The following test-support development dependencies were enabled for the `zed` crate: - `fs`, for `FakeFs` - `remote`, for the mock `RemoteClient` - `remote_server`, for `HeadlessProject` These are development-only dependencies and do not change Zed’s runtime dependency graph. The `Cargo.lock` change records `remote_server` as a dependency of the `zed` package under the test configuration. ## Testing Added an end-to-end GPUI regression test: ```text test_open_remote_from_existing_connection_reuses_window ``` The test: 1. Creates a fake remote filesystem with two project directories. 2. Starts a headless mock remote server. 3. Opens the initial project through `open_remote_project`. 4. Verifies that exactly one window exists. 5. Transitions the mock client to `ServerNotRunning`. 6. Injects `/other-project` as the path-prompt result. 7. Dispatches: ```rust zed_actions::OpenRemote { from_existing_connection: true, create_new_window: Some(false), } ``` 8. Verifies that the application still has exactly one window. 9. Answers the expected failed-reconnection prompt with `Cancel`, allowing the detached action task to terminate cleanly. The unavailable-server step keeps the test focused on window routing. It avoids requiring a second successful mock SSH lifecycle while still exercising the real action handler, path prompt, remote workspace, helper, and `open_remote_project` entry point. Before the production change, the test failed with: ```text create_new_window: false should reuse the current window left: 2 right: 1 ``` After the change, the test passes. ### Verification performed Focused regression test: ```sh cargo test -p zed test_open_remote_from_existing_connection_reuses_window ``` Result: ```text 1 passed; 0 failed ``` GPUI scheduler sweep: ```sh ITERATIONS=20 cargo test -q -p zed test_open_remote_from_existing_connection_reuses_window -- --nocapture ``` Result: ```text Seeds 0 through 19 passed ``` Complete `zed` test target, run serially because several existing tests share global session state: ```sh cargo test -q -p zed -- --test-threads=1 ``` Result: ```text 74 passed; 0 failed; 1 ignored ``` Formatting: ```sh cargo fmt -p zed --check ``` Repository-prescribed Clippy check: ```sh ./script/clippy -p zed ``` This ran the release, all-targets, all-features configuration with warnings denied and completed successfully. The change and test were run on Fedora Linux. ### Manual verification This can also be verified interactively: 1. Connect to a project over SSH. 2. Bind or dispatch: ```json [ "projects::OpenRemote", { "from_existing_connection": true, "create_new_window": false } ] ``` 3. Select another directory on the connected host. 4. Confirm that the project opens in the current Zed window. 5. Repeat with `create_new_window: true` and confirm that a new window is created. 6. Omit `create_new_window` and confirm that the result follows `default_open_behavior`. No screenshot is included because this does not change rendered UI; it changes which window contains the opened remote workspace. ## Scope and impact - No unsafe code was added. - No remote protocol or transport behavior changed. - No settings schema changed. - No action schema changed. - No user-facing strings changed. - No new runtime dependencies were introduced. - The added work is limited to resolving one optional boolean and downcasting the current window handle when reuse is requested. - The window-handle lookup occurs only when this action is dispatched and has no meaningful performance impact. ## 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 opening a project from an existing remote connection to respect the configured window behavior. |
||
|
Xin Zhao
|
2610332077 |
path: Normalize Windows paths independently of the host platform (#61374)
# Objective Zed's `PathStyle` is designed to handle paths across platforms. Its behavior should depend only on the selected path style, not on the platform where Zed is running. This is essential for remote development, where the local and remote platforms may differ. While fixing bugs involving Windows remote targets, I found that `PathStyle::normalize` does not behave consistently across host platforms. For `PathStyle::Windows`, it delegates to `crate::normalize_path`: https://github.com/zed-industries/zed/blob/914e1c9873b6b85bfeedc5b58e8270885bdd532e/crates/path/src/path.rs#L237-L263 That function uses `Path::components()`, which interprets paths according to the host platform. As a result, when Zed runs on a Unix-like system and connects to a Windows remote, something maybe wrong here. `PathStyle::normalize` should instead interpret paths according to the selected `PathStyle`, independently of the host platform. ## Solution Implement Windows path normalization directly in `PathStyle::normalize` without relying on `std::path::Path` parsing. The new implementation: - Recognizes drive-letter, rooted, relative, and UNC paths. - Treats both `\` and `/` as Windows path separators. - Resolves `.` and `..` components lexically. - Uses `\` as the normalized Windows path separator. - Produces the same result regardless of the host platform. ## Testing New test is added and tested with `cargo test -p util`, this test would fail on current main branch. ## 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 or Added/Fixed/Improved ... |
||
|
Alan P John
|
b7de76402c |
dev_containers: Preserve Compose entrypoints by default (#61897)
# Objective Docker Compose-based dev containers do not run their image or service entrypoint when `overrideCommand` is omitted. The Dev Container specification defaults `overrideCommand` to `true` for image and Dockerfile configurations, but to `false` for Docker Compose configurations. Zed treated an omitted value as `true` for every build type and generated a Compose entrypoint override, preventing the configured entrypoint from running. Fixes #60456 ## Solution Resolve the effective value of `overrideCommand` based on the dev container build type: - Preserve the existing default of `true` for image and Dockerfile configurations. - Use the specification default of `false` for Docker Compose configurations. - Continue to give an explicitly configured `overrideCommand` precedence over the default. Use the resolved value when deciding whether to generate Zed's entrypoint script. Add regression tests covering the defaults for image, Dockerfile, and Docker Compose configurations, along with explicit overrides in both directions. ## Testing Automated testing: - `cargo fmt --check` - `cargo test -p dev_container override_command --lib` - `./script/clippy -p dev_container --lib` - `cargo build -p zed` All three focused tests pass, and Clippy passes with warnings denied. Manually tested on Linux using the Docker Compose reproduction from #60456: 1. Built an Alpine image with an `ENTRYPOINT` that writes `/tmp/entrypoint-marker.log`. 2. Configured the Compose service with `command: sleep infinity`. 3. Omitted `overrideCommand` from `devcontainer.json`. 4. Opened the project in the current stable release and confirmed that the marker file was not created. 5. Opened a fresh container using this branch's development build and confirmed that: - `/tmp/entrypoint-marker.log` was created. - The Compose `sleep infinity` command remained active. Testing was performed with Docker Compose on Linux. I did not manually test this change on macOS or Windows, but the default resolution is platform-independent. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable ## Showcase ### Before Current stable Zed replaces the Compose entrypoint when `overrideCommand` is omitted, so `/tmp/entrypoint-marker.log` is not created. Zed 1.12.0 <img width="2827" height="1709" alt="image" src="https://github.com/user-attachments/assets/04dadd66-5e95-4ea8-8183-6156793f0654" /> ### After The development build preserves the Compose entrypoint by default. The marker file is created and the Compose service command remains active. <img width="2827" height="1709" alt="image" src="https://github.com/user-attachments/assets/cdd9808b-7867-42d8-bec7-97af9c170b0a" /> --- Release Notes: - Fixed Docker Compose dev containers not running their configured entrypoints by default. |
||
|
Mayank Verma
|
e99616cdd4 |
gpui: Add resizable and minimizable state to Window (#61473)
### Objective PR #36859 made native macOS and Windows controls respect `is_resizable` and `is_minimizable`, but custom window decorations cannot access those values from `Window`. Linux custom controls and client-side resize interactions remain active, macOS custom titlebar double-click does not check either option and custom Windows caption buttons still appear enabled even though the backend blocks their actions. ### Solution Expose `is_resizable` and `is_minimizable` on `Window`. Use them to disable custom window controls and titlebar actions and omit client-side resize cursors and hitboxes for non-resizable windows. ## 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: - N/A |
||
|
Ben Kunkle
|
ae394f3d47 |
edit_prediction: Disable jumps for staff (#61960)
# Objective - Stop enabling edit prediction jumps by default for Zed staff. ## Solution - Disable the staff default for the `edit_prediction_jumps` feature flag. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [ ] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - N/A |
||
|
Ibrahim Khan
|
b6b2148bd0 |
grammars: Highlight class instantiations in JavaScript, TypeScript, and TSX (#61890)
## Why JavaScript, TypeScript, and TSX class declarations were captured as `type.class`, but the same class names in `new` expressions were captured as the generic `type`. Themes that define a distinct style for `type.class` therefore rendered declarations and instantiations inconsistently. ## What Update the three highlight queries so constructor identifiers in `new` expressions use `type.class`. Themes without a dedicated `type.class` style continue to fall back to their existing `type` style. Add a regression test that loads the real JavaScript, TypeScript, and TSX grammars with distinct colors for `type` and `type.class`, then verifies that both the declaration and instantiation receive the class-specific highlight. ## Testing - `cargo test -p languages test_class_instantiation_highlighting` - `cargo test -p languages` - `cargo fmt --all -- --check` - `./script/clippy -p languages` ## References Closes #55943 Release Notes: - Fixed inconsistent class instantiation highlighting in JavaScript, TypeScript, and TSX. |
||
|
Mikayla Maki
|
9a631e5461 |
Fix path's license (#61955)
Release Notes: - N/A |
||
|
Nitin Krishna MucheliandClaude Sonnet 5
|
5638be1fe5 |
language_models: Stop logging noisy ChatGPT Subscription auth errors on startup (#61949)
# Objective
- On every startup (and whenever the agent panel initializes), Zed
authenticates all visible language model providers in the background to
populate the model selector. For every other credential-based provider,
"not signed in yet" is reported as
`AuthenticateError::CredentialsNotFound`, which is explicitly treated as
expected and not logged. The ChatGPT Subscription provider instead
returned a generic `anyhow` error, so it logged an `ERROR [agent] Failed
to authenticate provider: ChatGPT Subscription: ...` on every launch,
even for users who have never configured or used it.
- Fixes #60237
> **AI disclosure:** I used Claude (Anthropic) to investigate this
error, write the fix, and draft this PR description, based on a `Failed
to authenticate provider: ChatGPT Subscription` line I noticed in my own
Zed logs. I reviewed the diff and the reasoning below, ran the tests
myself, and understand and take responsibility for the change, per Zed's
[AI
Policy](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#ai-policy).
## Solution
- `OpenAiSubscribedProvider::authenticate` now returns
`AuthenticateError::CredentialsNotFound` (instead of a generic
`anyhow!(...)` wrapped into `AuthenticateError::Other`) when no ChatGPT
credentials are found after the initial load, matching how every sibling
provider (e.g. Anthropic's `ApiKeyState::load_if_needed`) signals "not
configured."
- The user-facing sign-in prompt in the settings UI
(`SUBSCRIPTION_DESCRIPTION`) is unchanged — this only affects the
background authentication sweep's error handling, not what the user sees
when opening provider settings.
## Testing
- `cargo test -p language_models -p openai_subscribed` — all 108 tests
pass, including
`provider::openai_subscribed::tests::test_authenticate_awaits_initial_load`,
which exercises this exact code path.
- `cargo check -p language_models` — compiles cleanly.
- Manually confirmed the log line no longer appears when starting Zed
without ChatGPT Subscription configured.
## 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
Before (this fix): startup log ends with a spurious `ERROR` even though
ChatGPT Subscription was never configured.
```
2026-07-30T21:37:46+05:30 INFO [zed] ========== starting zed version 1.15.0+dev.b90735ff317b83c4ec62ab3d73dd5385bbe1624d, sha b90735f ==========
2026-07-30T21:37:48+05:30 WARN [zed::reliability::hang_detection] debug build, only reporting hangs longer then 5s
2026-07-30T21:37:48+05:30 WARN [zed::reliability] Minidump endpoint not set
2026-07-30T21:37:48+05:30 INFO [zed::reliability] memory usage: resident 98 MiB, virtual 426367 MiB
2026-07-30T21:37:48+05:30 INFO [extension_host] extensions updated. loading 2, reloading 0, unloading 0
2026-07-30T21:37:48+05:30 INFO [prompt_store::rules_to_skills_migration] Rules-to-skills migration already marked done; skipping startup migration
2026-07-30T21:37:49+05:30 INFO [zed::reliability] worktree diagnostics: stores 0, slots 0, live 0, visible 0, strong 0, dead weak 0, loading 0, entries 0, visible entries 0, largest none
2026-07-30T21:37:49+05:30 INFO [workspace] Rendered first frame
2026-07-30T21:37:50+05:30 ERROR [agent] Failed to authenticate provider: ChatGPT Subscription: Sign in with your ChatGPT Plus or Pro subscription to use this provider.
```
After this fix: the same startup sequence completes with no `ERROR`
line.
```
2026-07-30T22:11:38+05:30 INFO [zed] ========== starting zed version 1.15.0+dev.a8491e63b54bf1881e10fe78bb3e7b1f8a5a2cac, sha
|
||
|
Kunall Banerjee
|
9dc8880b2b |
file_finder: Fix path:line navigation when target file is already open (#55875)
Three pieces of state combined to break `path:line` queries when the target file was already open: - The `CreateNew` lookup ran against `query.raw_query.as_str()`, so a path with a row suffix never matched the existing file and a stray `Create file: foo.rs:3` row was always pushed. - `calculate_selected_index` applied `skip_focus_for_active_in_search` even when the query carried a row/column, jumping past the file the user was asking to navigate inside. - The preserved-selection path only invalidated on `path_query()` changes. Appending `:3` to a typed-out path therefore kept the previously skipped-to fuzzy neighbor selected, hiding the fix above when the query was built up character by character. Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [ ] Unsafe blocks (if any) have justifying comments - [ ] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [x] Tests cover the new/changed behavior - [ ] Performance impact has been considered and is acceptable Closes #55551 Release Notes: - Fixed File Finder offering to create a file instead of navigating to a line when the target file is already open |
||
|
Ayush Patil
|
998fbf30ff |
Register Git submodules under their own project path (#61859)
Closes #61671 A submodule's `.git` is a file pointing into the superproject's `.git/modules/<name>`, which looks just like a linked worktree's `.git` file. The identity-path resolution used for recent projects and project grouping treated them the same, so submodules got registered under `.git/modules/<name>` instead of their own folder. The fix detects submodule git dirs (`is_submodule_git_dir`) and skips resolution for them, so a submodule keeps its own working directory as its identity. Linked worktrees and bare repos are unaffected. ### Current vs. Expected Current: opening submodule `Foo/Bar` registers the path as `Foo/.git/modules/Bar`. Expected: it registers as `Foo/Bar`, like any other project. ### Video https://github.com/user-attachments/assets/e2eee5e7-ef64-47ed-9780-6fcafda5ae30 ### Tests - `is_submodule_git_dir` unit test - `resolve_git_worktree_to_main_repo` returns `None` for a submodule - persistence test asserting the submodule identity stays at its own folder Release Notes: - Fixed Git submodules being registered under the parent repository's `.git/modules` directory instead of their own path |
||
|
AvoidTheKitchenandBen Kunkle
|
790dcefb01 |
edit_prediction: Support self-hosted Sweep Next Edit models (#51139)
This adds support for running self-hosted Sweep Next Edit edit prediction models through Zed's OpenAI-compatible provider. The target use case is a local deployment based on [sweepai/sweep-next-edit-1.5B](https://huggingface.co/sweepai/sweep-next-edit-1.5B), using the rewrite-window prompting approach described in [OSS Next Edit](https://blog.sweep.dev/posts/oss-next-edit). Personal user testing shows impressive quality from this small edit prediction model. This is valuable because it allows more flexibility for Zed users to self-host state of the art next edit prediction models! This PR addresses the self-hosted workflow discussed in https://github.com/zed-industries/zed/discussions/50929. Note that the self-hosted model path needed more than just a new dropdown value. Zed has to build the rewrite-window prompt shape the model expects, map the rewritten window back into anchored edits, and make `prompt_format: "infer"` work with the filename-style model identifiers that llama-server local server reports. The main changes are: - add a `Sweep` prompt format for OpenAI-compatible edit prediction providers and route it to a dedicated `SweepPrompt` model path - build Sweep rewrite-window prompts from the active cursor window, recent change history, and related file excerpts - convert rewrite responses back into anchored edits and suppress no-op rewrites - add fixed cursor-window extraction used by the Sweep rewrite prompt path - recognize `sweep-next-edit` model names during `infer`, including filename-style identifiers such as `sweepai_sweep-next-edit-1.5B_sweep-next-edit-1.5b.q8_0.v2.gguf` - reject reserved Sweep prompt tokens before sending malformed requests to a self-hosted server - update the docs to describe the actual Sweep rewrite-window prompt format Local setup used for manual verification: ```sh llama-server \ --hf-repo sweepai/sweep-next-edit-1.5B \ --hf-file sweep-next-edit-1.5b.q8_0.v2.gguf \ --ctx-size 8192 \ --host 127.0.0.1 \ --port 8080 ``` ```json { "edit_predictions": { "provider": "open_ai_compatible_api", "open_ai_compatible_api": { "api_url": "http://127.0.0.1:8080/v1/completions", "model": "sweepai_sweep-next-edit-1.5B_sweep-next-edit-1.5b.q8_0.v2.gguf", "prompt_format": "infer", "max_output_tokens": 512 } } } ``` The request that produced this PR included screenshots of the OpenAI-compatible provider configuration and the prompt format dropdown with `Sweep` selected. Tests added in this branch: - `test_sweep_prompt_format_routes_to_sweep_prompt_model` - `test_fixed_line_window_around_cursor_start_middle_and_end` - `test_sweep_prompt_request_prediction_diffs_rewritten_window_into_anchored_edits` - `test_sweep_prompt_request_prediction_returns_none_for_identical_rewrite` - `test_original_window_for_current_window_uses_latest_pre_edit_snapshot` - `test_original_window_for_current_window_returns_none_without_matching_history` - `test_recent_change_block_from_event_formats_original_and_updated_sections` Verification run locally: - `cargo test -p zed sweep_prompt_format_routes` - `cargo test -p zed subscribe_uses_stale_provider_config` - `cargo test -p edit_prediction sweep_prompt` - `cargo test -p edit_prediction fixed_line_window_around_cursor_start_middle_and_end` - `cargo test -p edit_prediction test_sweep_prompt_request_prediction_diffs_rewritten_window_into_anchored_edits` - `cargo test -p edit_prediction test_sweep_prompt_request_prediction_returns_none_for_identical_rewrite` - `./script/clippy -p zed -p edit_prediction -p settings_content` Release Notes: - Added support for self-hosted Sweep Next Edit models in OpenAI-compatible edit predictions, including the `sweep` prompt format and `infer` detection for `sweep-next-edit` model names. --------- Co-authored-by: Ben Kunkle <ben@zed.dev> |
||
|
Remco Smits
|
08994c411c |
zed: Wait for session restore before handling CLI open requests (#61814)
Closes #61346 # Objective At startup, a synchronous `try_recv` decides whether to restore the session. On a macOS cold launch the CLI request arrives via `application:openURLs:`, which AppKit dispatches only *after* the startup closure returns, so the check finds nothing, session restore begins, and the request lands moments later on the post-startup path. Both behaviors are individually correct: a user with `restore_on_startup: "last_session"` wants their session back, and the requested file should open. The defect is that they race, the CLI open runs its existing-window matching before restore has placed any windows, finds nothing to reuse, and opens a redundant window. ## Solution Make the post-startup open loop wait for restore to settle before handling a request, so `find_existing_workspace` sees the restored windows and honors `cli_default_open_behavior`. The wait races full restore completion against the first window being placed, so a slow or hung remote-workspace restore can't block a local open. No timeouts involved, the fix is ordering, not delay :). ## Testing **Steps**: 1. disable & enable the setting `close windows when quiting an application` in macos itself in `desktop & dock` section 2. create a bundled Zed app 3. install cli binary to actually test the change 4. Follow any of the steps inside the before/after video's to test all the cases we have I tested this with a manual prod build using a custom script that bundles Zed as a preview app. So I could actually test the cli baviour since it works different for non-bundled builds. So the easiest way to test this would be to run bundling on this PR and install the cli binary to actually test it with the fix included. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [ ] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable ## Showcase <details> <summary>**Disabled** Close windows when quiting an application</summary> **before** (disabled apps on close & `add to existing window` cli bahavior) https://github.com/user-attachments/assets/b497130b-3432-4fa8-9fbe-70c6f63d165e **After** (disabled apps on close & `add to existing window` cli bahavior) https://github.com/user-attachments/assets/354657f7-8dfe-4beb-9dd4-2bb615cb912c **After** (disabled apps on close & `open a new window` cli bahavior) https://github.com/user-attachments/assets/07fc3062-89a3-4e2a-811e-296533feaad7 </details> <details> <summary>**Enabled** Close windows when quiting an application (unchanged)</summary> **After** (enabled** apps on close & `add to existing window` cli bahavior (**unchanged**)) https://github.com/user-attachments/assets/445f1d3a-2987-46b1-9bfb-b2d61894ddec **After** (enabled apps on close & `open a new window` cli bahavior (**unchanged**)) https://github.com/user-attachments/assets/c3078b0d-7fb4-42db-9dea-095439e23830 </details> --- Release Notes: - Fixed an extra window opening on macOS when launching Zed from the CLI with session restore enabled |
||
|
Lena
|
5786fee55a |
Duplicate Bot: Discussions, second critic, more context (v5) (#61948)
Release Notes: - N/A |
||
|
mTvare
|
ae99a867d7 |
x11: Request repaint after exposure instead of within blocked loop (#61162)
# Objective Closes #61054 This PR fixes Zed window not repainting after they are uncovered on X11. When an X11 window becomes visible after being covered, X11 sends an `Expose` event to tell the application that the window contents need to be presented again. Previously, Zed stored this event and waited for the periodic refresh loop to request a presentation but, the refresh loop is stopped while a window is fully hidden to avoid unnecessary rendering. This meant there might be no refresh tick to handle the pending exposure. window is fully hidden -> periodic refresh loop stops window is uncovered -> expose event -> waits for refresh loop -> window may remain blank This change requests one presentation directly after processing the pending X11 events. Multiple `Expose` events for the same window are coalesced, and unmapped windows are ignored. ## Solution window is uncovered -> expose event -> presentation is requested -> window contents are displayed Required presentations are also excluded from inactive-window frame throttling, so the request is not dropped when Zed is unfocused. Regular rendering for unfocused or fully obscured windows remains throttled. ## Testing Check the issue being closed on steps to reproduction. ## 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 Zed windows sometimes not repainting after being uncovered on X11 |
||
|
Finn Eitreim
|
79cc17c216 |
gpui: Give divs (the option for) a better scrolling experience (#61797)
# Objective Closes #56127 Right now there is an issue where in certain contexts, specifically GPUI div elements, horizontal scrolling w/ a trackpad works very poorly, even when trying to scroll sideways, vertical scrolling will happen. This happens with both a trackpad and scrollwheel. The showcase video also shows the broken behavior. ## Solution The way that scrolling works in the editor is really nice, scrolls are locked to the axis they started on but with enough force can change axis. so by taking the ongoing scroll handler from the editor and moving it up into GPUI, we can get that same functionality for GPUI. I somewhat "take over" the functionality of the existing `restrict_scroll_to_axis` property, because it seems like its purpose was basically trying to fix this problem already, just unsuccessfully. The alternative, and would make things overall nicer to look at, would be to tie this to `allow_concurrent_scroll`, but the effect radius tied to that option is way bigger, so im holding off on that atleast right now. ## Testing Theres a good number of scroll related tests generally, so I don't think i've perturbed any common existing behaviors. attach the functionality to `restrict_scroll_to_axis` really limits the surface. There are also some new tests for the ongoing_scroll behaviors. Tested on my mac w/ both trackpad and mouse. ## 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 Video show casing all the behaviors: broken w/ trackpad working w/ trackpad broken w/ scroll working w/ scroll https://github.com/user-attachments/assets/1935cd2d-a255-4a77-81d5-daa9f72470a6 --- Release Notes: - markdown_preview: Fix horizontal scrolling inside certain elements |
||
|
Smit Barmase
|
a8491e63b5 |
gpui: Restore file drags when re-entering the source window on macOS (#61940)
Follow-up to #58161, which handed file drags to AppKit once the pointer left the window but left the handoff one-way. Re-entering the source window and dropping was not possible. GPUI now suspends the original drag when handing it to the platform and restores it when the drag re-enters the source window, so drop targets receive the original typed payload instead of the synthetic external-paths payload. No release notes this hasn't shipped yet. Release Notes: - N/A |
||
|
John Tur
|
933c85b134 |
Fix MCP servers not being populated sometimes in settings UI (#61928)
The MCP server list was always populated from the first workspace in the `MultiWorkspace`. If Zed is configured to `"restore_on_startup": "launchpad"`, the first workspace will always be the 'launchpad' workspace which has no worktees in it. Since there are no worktrees in this workspace, the MCP store is not populated, so the settings UI did not show any MCP servers. --- Release Notes: - Fixed an issue where the settings UI would sometimes not show the list of configured MCP servers |
||
|
Ben Kunkle
|
f9a5bf9181 |
agent_ui: Route MCP configuration to active workspace (#61882)
# Objective - Prevent MCP extension configuration dialogs from appearing when switching to background workspaces. - Closes FR-145. ## Solution - Route configuration requests through the active application window and workspace, while keeping uninstall settings cleanup global. ## Testing - Added a regression test covering active and retained background workspaces. ## 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: - Agent: Fixed MCP extension configuration dialogs appearing in other workspaces. |
||
|
Finn Evers
|
cdf3ccd036 |
extensions_ui: Move logic to render extension card details into ExtensionCard component (#61850)
This PR reworks the extension card component to take care of most the rendering. It no longer implements `ParentElement` and instead takes care of rendering the details of the card now. This also allows us to finally render the list of features for dev extensions amongst some other cleanup whilst working with these. ## Why this change? This is in preparation for allowing to show extensions locally when the fetch fails based on the information available. Currently, this would require a lot of duplication and would be tedious to add. With this in, we can much more easily just construct an extension card with the upstream metadata missing, removing the need for duplication. Lastly, this also adds a component preview for extensions cards so we can play around more easily with other designs. Release Notes: - Installed dev extensions will now show the features they provide and will also respect feature filters. |
||
|
Lukas Wirth
|
a6a23c7b80 |
fuzzy: Remove util dependency (#61933)
Release Notes: - N/A or Added/Fixed/Improved ... |
||
|
Lena
|
9677f83f87 |
Add second-line triage queue board automation (#61918)
GitHub issue search can't express the one filter we want here: "created at least one business day ago." That's the whole reason the project board #\87 exists — since we can't save it as a search, we keep a project's membership in sync to stand in for it. So: an hourly workflow runs script/github-triage-queue-board.py, which adds the open issues that fall in the eligibility window to project #\87 and removes the ones that have aged out. Also wires the workflow into the community automation failure Slack alert, so if it breaks we hear about it. Release Notes: - N/A |
||
|
Lukas Wirth
|
c9d1d0ddfe |
fuzzy_nucleo: Remove util dependency (#61929)
Release Notes: - N/A or Added/Fixed/Improved ... |
||
|
asdfer
|
27ca052629 |
docs: Add missing font fallback documentation (#55779)
Adds missing documentation about font fallbacks on `appearance.md` and `all-settings.md` `all-settings.md` only lacked terminal font fallback documentation so that's the only thing I added there. Self-Review Checklist: - [X] I've reviewed my own diff for quality, security, and reliability - [it's a doc update] Unsafe blocks (if any) have justifying comments - [there is no ui] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [it's a doc update] Tests cover the new/changed behavior - [i really hope that my extra bytes on documentation cause no performance impacts] Performance impact has been considered and is acceptable Release Notes: - N/A |
||
|
Ron HarelandSmit Barmase
|
a473ea63a8 |
image_viewer: Fix texture leak when reloading images (#58803)
When the image viewer reloads an image after the underlying file changes, it now tracks the `RenderImage` currently displayed by the view and drops that image’s atlas entry before replacing it with a newly decoded render image. This prevents rapidly updated images from accumulating atlas textures per reload while keeping cleanup scoped to the window that displayed the image. Closes #35894 Release Notes: - Fixed a memory leak when previewing images that are repeatedly updated on disk. --------- Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com> |
||
|
ᴀᴍᴛᴏᴀᴇʀ
|
d88f68217b |
vim: Fix Escape not dismissing release notes notifications (#61759)
# Objective Fixes #58492. With Vim mode enabled and an editor focused in normal mode, Escape does not close the release notes notification shown after an update. Vim consumes Escape before the workspace can handle `menu::Cancel`. ## Solution Add Windows-specific Escape bindings for `menu::Cancel` in Vim and Helix normal modes. Place them after the existing Escape bindings so GPUI tries `menu::Cancel` first. This is limited to Windows because macOS and Linux already provide non-conflicting `Ctrl-C` and `Ctrl-Escape` alternatives, respectively. ## Testing Added regression coverage for dismissing workspace notifications with Escape in Vim normal mode. I verified the test passes and the visible notification is dismissed locally. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable ## Showcase https://github.com/user-attachments/assets/3895385f-7be1-4c62-8d7c-05a5b580d855 --- Release Notes: - Fixed release notes notifications not closing with `escape` when Vim or Helix mode is enabled, on Windows. |
||
|
|
3652f3011a |
copilot: Use separate authentication paths for edit prediction and chat (#60535)
Release Notes: - copilot: Improve robustness of copilot chat provider by splitting authorisation paths for edit predictions and chat. Note: Existing users will have to re-authenticate with Copilot --------- Co-authored-by: cameron <cameron.studdstreet@gmail.com> Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com> |
||
|
Kirill Bulatov
|
410a8a06ed |
Do not drop other servers' data on semantic token refresh (#61795)
Closes https://github.com/zed-industries/zed/issues/60825 Release Notes: - Fixed semantic tokens overly invalidated on `workspace/semanticTokens/refresh` |
||
|
mTvareandKirill Bulatov
|
200fb85c90 |
language: Fix incomplete bracket matches during error recovery (#61604)
Closes #61410 ## Summary Tree-sitter bracket queries can become incomplete when recovering from syntax errors. The existing code handled incorrect matches by collecting the delimiters returned by the query and pairing them again in order. The query missed the innermost closing parenthesis. The repair therefore worked on an incomplete sequence, paired the innermost opening parenthesis with the next available close, and shifted every remaining pair outward. ## Solution This change records the syntax-node kinds used by each bracket pattern and, when a syntax layer contains errors, checks the concrete leaves inside those error nodes for delimiters missing from the query output. When the opening and closing kinds are different and the error range remains balanced, the missing delimiters are included in the existing reconstruction. ## Testing Reproduced the issue using the C snippet from #22679 and verified that each parenthesis is matched with its correctly nested partner. Also verified that unbalanced code does not cause the recovery logic to invent a missing bracket pair. ## How to Review The relevant changes are in `BufferSnapshot::fetch_bracket_ranges` in `crates/language/src/buffer.rs`. The important distinction is between the bracket-query output and the concrete syntax leaves inside an error node. Previously, the repair could only rearrange delimiters present in the query output. It can now detect when that output is incomplete, add the missing real delimiters, and run the existing reconstruction over the complete set. ## 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)](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 incorrect bracket matching when syntax-error recovery omitted a delimiter. --------- Co-authored-by: Kirill Bulatov <kirill@zed.dev> |
||
|
Ben Kunkle
|
f851d82e88 |
edit_prediction: Fix v4 cursor placement (#61901)
# Objective Prevent accepted v4 edit predictions from moving the cursor past the model's predicted position. ## Solution Keep the cursor's base anchor fixed while applying inserted text, then apply the model-provided offset. Add regression coverage based on the reported cursor jump. ## 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 |
||
|
Ben Kunkle
|
b9301f5c94 |
agent: Instruct agents to request approval before creating threads (#61898)
# Objective Instruct agents not to create persistent sibling threads without user approval. ## Solution Update the `create_thread` instructions to require an explicit request or approval. Agents may still suggest creating a thread. ## Self-Review Checklist: - [x] I’ve reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed’s UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [ ] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - N/A |
||
|
Victor RatonandKunall Banerjee
|
5e549b871f |
docs: Add note about toolchain selection for Python REPL (#60549)
# Objective Improve documentation to inform about toolchain in repl session and avoid issues like https://github.com/zed-industries/zed/issues/60465 ## Solution - Add a note in documentation about using toolchain for change python enviroment ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability Release Notes: - N/A --------- Co-authored-by: Kunall Banerjee <hey@kimchiii.space> |
||
|
ArneshandClaude Fable 5
|
b535bec7bf |
repl: Add a delete-cell action to the notebook editor (#61295)
The notebook editor has actions for adding and moving cells but no way to delete one. This adds `notebook::DeleteCell`: - Trash icon button in the notebook toolbar (own group below add-markdown/add-code, disabled when the notebook has no cells) - Jupyter-style `d d` binding plus `backspace` in cell command mode (macOS and Linux keymaps) - Deletes the selected cell; selection moves to the neighboring cell, focus returns to command mode, and the item is marked dirty via the existing structural-change tracking so saving persists the deletion Tested locally on macOS with the notebook feature enabled: button click and bindings delete the selected cell and saving writes the result. (Screenshots in comments.) Release Notes: - Added a delete-cell action (`d d` in command mode and a toolbar button) to the notebook editor (preview-only). Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
Kunall BanerjeeandMrSubidubi
|
6109c2e6d8 |
grammars: Support linked editing of custom elements in JSX and TSX (#58578)
JSX and TSX only treated the dot as a tag-name character during linked-editing, so renaming a tag to a custom element name such as `custom-el` stopped mirroring the closing tag at the dash. A follow-up to https://github.com/zed-industries/zed/pull/43179, really. Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [ ] Unsafe blocks (if any) have justifying comments - [ ] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [x] Tests cover the new/changed behavior - [ ] Performance impact has been considered and is acceptable Closes #58553. Release Notes: - Added support for linked-editing of custom elements in JSX/TSX --------- Co-authored-by: MrSubidubi <finn@zed.dev> |
||
|
Kunall BanerjeeandMrSubidubi
|
259297035a |
grammars: Enable Emmet completions in return and arrow function bodies (#53688)
Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [ ] Unsafe blocks (if any) have justifying comments - [ ] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [ ] Tests cover the new/changed behavior - [ ] Performance impact has been considered and is acceptable Closes #52205. Release Notes: - Enabled Emmet completions in return and arrow function bodies for JSX/TSX --------- Co-authored-by: MrSubidubi <finn@zed.dev> |
||
|
Kunall Banerjee
|
36911f8cab |
docs: Clarify window_decorations currently only works on Linux (#61883)
Also add the setting to our docs at https://zed.dev/docs -- it’s currently missing. Updated a stale comment as well -- window decorations were [always supported on X11](https://github.com/zed-industries/zed/pull/13611)? Closes #61788. --- Release Notes: - N/A |
||
|
Julien RoncagliaandMrSubidubi
|
33f1112fc2 |
theme: Specify color format and pattern in schema (#49136)
## Purpose
While developing a theme for Zed I remarked that the schema available
doesn't mark colors in a way that Zed recognize to display the color
annotations:
```json
{
"$schema": "https://zed.dev/schema/themes/v0.2.0.json"
}
```
<img width="119" height="190" alt="Screenshot 2026-02-25 at 23 15 10"
src="https://github.com/user-attachments/assets/3f1bb703-cb26-4630-9598-3a7cb8873c20"
/>
But Zed has support for it when colors are marked with `"format":
"color"` in the schema:
<img width="127" height="186" alt="Screenshot 2026-02-25 at 23 14 58"
src="https://github.com/user-attachments/assets/1a9387a4-613a-4cf8-a3af-f6ac201bdf54"
/>
So I searched if the schema file was Open Source somewhere, discovered
it was generated from the codebase and attempted the change.
## Implementation
This is essentially done using a `ThemeColor` wrapper for the color
strings that implements `JsonSchema` with a dedicated regex for
validation and the color format specified. This ends up with a new
`$defs` of `Color` being specified and used:
```json
{
"$defs": {
"Color": {
"type": "string",
"format": "color",
"pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{4}|[0-9a-fA-F]{6}|[0-9a-fA-F]{8})$"
}
}
}
```
## Other
- There is a small change I made for testing to the schema_generator
that adds an `--output` / `-o` flag. When provided it writes the
generated schema JSON to the specified file path instead of printing to
stdout. This was done to made testing easier but I can remove it or
split it to a separate PR (It's already a separate commit)
- For this PR to do anything a new schema version will need to be
published at something like `https://zed.dev/schema/themes/v0.3.0.json`
and documentation needs to be updated to point to it.
Before you mark this PR as ready for review, make sure that you have:
- [x] Added a solid test coverage and/or screenshots from doing manual
testing (Manual testing, couldn't find any existing good place to test
it)
- [x] Done a self-review taking into account security and performance
aspects
- [x] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
|
||
|
Kunall Banerjee
|
431734c9ac |
collab_ui: Open contact finder with empty query (#61363)
I ran into this while conducting some tests. If you search for a channel name in the Collab Panel and then try to “Add a Contact,” it seeds the query with your search term from the current contents of that channel search editor. Opted to just drop that method altogether as it’s not being used anywhere else. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [ ] Unsafe blocks (if any) have justifying comments - [ ] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [ ] Tests cover the new/changed behavior - [ ] Performance impact has been considered and is acceptable --- Release Notes: - Fixed the contact finder inheriting the channel search query in the Collab Panel |
||
|
Lee ByeongJunandSmit Barmase
|
f52fd9ac44 |
Add macOS file drag-out from project panel (#58161)
## Description Adds native macOS file drag out support for Project Panel entries. Local file paths are resolved only when a drag gesture starts, remote or missing paths are skipped, and unsupported platforms keep the default no-op behavior. The macOS implementation starts an AppKit drag session with file URL pasteboard items, allows Finder and other external apps to choose copy or move, keeps in-app GPUI drag/drop behavior in control for internal drags, and clears the active drag state when the native session ends. https://github.com/user-attachments/assets/42909389-1a32-4574-a200-9a14b913f55f 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 - [ ] Performance impact has been considered and is acceptable Closes #55370 Release Notes: - Added support for dragging files from the Project Panel to external macOS apps. --------- Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com> |
||
|
Cameron Mcloughlin
|
f620cbc04e |
sadbox: Fix bundling (#61873)
The type of this value varies across glibc and musl, this works on both --- Release Notes: - N/A or Added/Fixed/Improved ... |
||
|
Ben Kunkle
|
b9256fa8f0 |
Stop the npm cache from growing without bound (#61750)
# Objective - Fixes #59409. Closes FR-143. Zed's managed npm directory reaches 10–17GB on machines that use external agents, and is never pruned. - Two independent causes: registry agents are launched with `npm exec`, which keys its install directory on the requested version, so every agent release leaves a full ~250MB copy behind; and npm never evicts anything from its download cache. ## Solution - Install registry agents into a directory we reuse, so npm replaces the previous version in place instead of accumulating one copy per release. As a side effect, updates now download only the changed dependencies rather than the whole tree. - Empty the download cache on startup. Nothing in it needs to survive a restart, since packages are installed elsewhere. It has to go wholesale: deleting individual downloads leaves npm's index pointing at missing files, and npm then fails with `ENOENT` rather than fetching them again. - The first launch after this does one full agent install as it moves into its new home, and reclaims whatever the old directories were holding. ## Testing - Installed the real agent at 0.33.1, then upgraded to 0.42.0 in the same directory: 253MB → 256MB, against two separate copies today. The resolved executable answers an ACP `initialize`. - macOS only. Windows deserves a look — it should be better than before, since the agent is now launched as a plain `.js` file with Node instead of through npm's `.cmd` shim, but I can't verify 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) - [ ] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - Fixed the bundled npm cache growing without bound, which could consume many gigabytes of disk. |
||
|
zed-zippy[bot]
|
e24eeb71ad |
Bump Zed to v1.15.0 (#61866)
Release Notes: - N/A Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com> |
||
|
Mayank Verma
|
a11083f9a7 |
gpui: Defer appearance change callback to avoid reentrant borrow (#61789)
### Objective PR #58902 made native macOS window chrome follow the selected theme, but AppKit can synchronously invoke `viewDidChangeEffectiveAppearance` while the settings observer holds an `App` borrow. `handle.update` then fails with `RefCell already borrowed`, leaving `Window::appearance()` and its observers stale. ### Steps to reproduce 1. Set Zed's theme mode to Dark. 2. Set macOS Appearance to Light. 3. Change Zed's theme mode to System. 4. Notice that the window chrome switches to light, but Zed's UI remains dark. https://github.com/user-attachments/assets/f91962cc-76ba-4d8e-b587-2a2343f365ba ### Expectation Zed should switch to its configured light theme when returning to System mode. ### Solution Defer `Window::appearance_changed` to the foreground executor so the current `App` borrow finishes before refreshing the cached appearance and notifying observers. ### Testing - Added a regression test. ### Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [ ] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - N/A |
||
|
Mikhail PertsevandTom Houlé
|
dc1e815e47 |
gpui: Complete pending key bindings before IME input (#61270)
# Objective - Fix multi-stroke keybindings such as `ctrl-x k` being intercepted by the macOS Japanese IME before GPUI can complete the binding. - Preserve IME-first handling for ordinary Japanese text input and active marked-text composition. - Fixes #56043. ## Solution - Stop preferring IME-first printable input while a valid multi-stroke keybinding is pending. This allows the next printable keystroke to reach GPUI and complete the binding. - Consider pending input active only when it belongs to the window's current focus. This prevents stale pending state after a focus change or blur from bypassing normal IME handling. - Preserve the existing macOS active-composition path, so marked text, candidate selection, and composition commands continue to reach `NSTextInputContext` first. ## Testing Manually tested on macOS using Apple’s built-in Japanese–Romaji/Hiragana input source with a `ctrl-x k` keybinding. Also added regression test for pending keybinding routing. ## 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 multi-stroke keybindings not completing when using a Japanese IME on macOS. --------- Co-authored-by: Tom Houlé <tom@tomhoule.com> |