Normalize application-facing mode presentation and saved-default APIs
onto the existing v2 config select-choice types.
- [Shared mode
contracts](baf15a799b/crates/acp_thread/src/connection.rs (L353-L359))
and mode-update events use v2 value IDs; legacy choices retain opaque
IDs, labels, descriptions, metadata and order.
- Keep the current config-options-first UI and the legacy mode-selector
fallback. No synthetic config option ID or new mode DTO; selection,
cycling, keybindings and tool-availability wire operations are
unchanged.
- Server default-mode APIs use v2 value IDs, while persisted
`default_mode` remains a string, separate from `default_config_options`.
No settings migration.
- V1 mode state and `session/set_mode` stay in the external adapter,
with the same optimistic selection and failure rollback.
Release Notes:
- N/A
Use `(String, String)` pairs for local terminal environments instead of
ACP v1 environment DTOs.
- Update the [native environment
interface](4973994016/crates/agent/src/thread.rs (L780-L789)),
implementation, shared launch API and two test fakes.
- Keep environment assembly unchanged: directory environment, pager
defaults, then extras in vector order; the last duplicate wins. Native
temp-directory variables remain appended after caller entries under the
same platform/local-project guards.
- Leave external protocol environment DTOs at their existing adapter
boundary. Output/status contracts, sandbox policy, remote execution and
turn lifecycle are unchanged.
Release Notes:
- N/A
Use v2 metadata spelling in application-owned shared APIs rather than
coupling them to the v1 namespace.
- Update [session-list
wrappers](2ab0f94a44/crates/acp_thread/src/connection.rs (L381-L393)),
retry metadata and tool-name/subagent/sandbox/refusal-fallback helper
signatures and factories.
- Both aliases in the pinned schema are exactly `serde_json::Map<String,
serde_json::Value>`. After normalizing the alias spelling, both changed
files are byte-identical to the base.
Release Notes:
- N/A
Decouple local process output and completion from ACP v1 wire responses,
without changing terminal behavior.
- Add a small application-owned [ProcessOutput
snapshot](6799112199/crates/acp_thread/src/terminal.rs (L471))
containing text, truncation and optional v2 exit status. Keep the cached
UI output and agent-reported display updates separate.
- Return v2 exit status from local process waits, and migrate native
handles, terminal-tool consumption and existing test fakes mechanically.
- Convert snapshots/status back to v1 only in the external client
response adapter, retaining text, truncation, exit code, signal and exit
metadata.
Release Notes:
- N/A
- Reuse receipt tracking for already-started transports; support
optional receipt retry and backend preflight validation.
- Add explicit local keyed message/checkpoint/cleanup/action-state
helpers and retain typed local errors alongside reported state.
- Normalize withdrawn receipts as cancellation, not provider failure.
- Prepare reported-state follow/error handling and hidden command-marker
composer behavior.
- Keep native and external v1 agents completion-based. No native receipt
override, driver, retry recipe, eval migration, SDK pin or rollout flag
changes.
Stacked on #65502. The native switch will remain in #65420 on top of
this branch.
Release Notes:
- N/A
Release native command work with its session instead of keeping the ACP
thread alive through an awaited command task.
- Retain weak ACP-thread handles through MCP, skill and compact-command
awaits.
- Cancel native work before removing a released session, including when
another native Thread handle is retained.
- Add one concise permission-wait lifetime regression.
Release Notes:
- N/A
## Summary
Another follow-up of #64149
The old `strip_prefix` did not only do the stripping, but also had the
functionality to build `RelPath`; this PR removes the `RelPath` building
part. It also reimplements this method based on components instead of
strings, which gives us the ability to handle non-UTF-8 paths and
Windows prefixes reliably.
Most of the callers of `PathStyle::strip_prefix()` are replaced by the
following chain:
```rust
PathStyle::strip_prefix()
.ok()
.and_then(|path| RelPath::new(path, path_style).ok())
```
In certain places, RelPath is not needed, and the updated `strip_prefix`
gives a direct result.
## Testing
Added new tests to guard `PathStyle::strip_prefix`'s functionality.
Tests passed for the crates where the callers live.
## Self-review
- [x] I've reviewed my diff for quality, security, reliability, and
performance.
- [x] UI changes follow the
[checklist](https://zed.dev/docs/development/ui-checklist).
- [x] Tests cover the new or changed behavior.
Release Notes:
- N/A
## Summary
When jumping to code locations, which have been folded away, one needs
to manually unfold the section and do the same jump action (e.g. go to
line) again.
With this change, the required sections are unfolded automatically when
jumping, while preserving other folded sections in the same buffer.
Without automatic unfolding:
https://github.com/user-attachments/assets/89017150-80a5-4c70-ba75-5627807a02fe
With automatic unfolding
https://github.com/user-attachments/assets/373498e7-6daf-4ff1-8352-eceb422b37b5
## Testing
To test this change, take any piece of code and fold sections of the
code. Then use go-to-line or jump-to-definition to jump into one of
these sections. All sections leading up to the jumped to line should be
unfolded automatically.
## Self-review
- [x] I've reviewed my diff for quality, security, reliability, and
performance.
- [x] UI changes follow the
[checklist](https://zed.dev/docs/development/ui-checklist).
- [x] Tests cover the new or changed behavior.
Release Notes:
- Added automatic unfolding of folded sections when using one of the
following features: go to line, go to
definition/declaration/implementation/type definition, symbol
navigation, outline or project-symbol pickers, multibuffer location
results, and navigation history
## Summary
#64095 restricted `FontFamilyName` in the settings JSON schema to the
fonts installed on the system. The virtual aliases that GPUI resolves
itself (`.ZedMono`, `.ZedSans`, `.SystemUIFont`, `Zed Plex Mono`, `Zed
Plex Sans`) are not installed fonts, so they were flagged as "Value is
not accepted" even though they work.
Add `gpui::VIRTUAL_FONT_NAMES` and include those names in the schema
enum.
Closes#64806
## Testing
Tests added and passing
## Self-review
- [ ] I've reviewed my diff for quality, security, reliability, and
performance.
- [ ] UI changes follow the
[checklist](https://zed.dev/docs/development/ui-checklist).
- [ ] Tests cover the new or changed behavior.
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
## Summary
Follow-up of #64149,
Zed currently has three handcrafted, identical `is_absolute()`
functions, living in `crates/path/src/path.rs` and
`crates/util/src/paths.rs`. They read as follows:
93d7456688/crates/path/src/path.rs (L409-L420)
In fact, these handcrafted methods behave like `Path::has_root()` rather
than `Path::is_absolute()`. The difference between the two is that
`Path::has_root()` only checks whether a path has a root, whereas
`Path::is_absolute()` checks whether the path is truly absolute. On
Unix, which has a single root, `has_root()` and `is_absolute()`
coincide. Windows, however, is multi-rooted (`C:\` and `D:\` are
different roots), so a rooted path such as `\temp\path` is not absolute:
depending on the working directory, it may resolve to `C:\temp\path` or
`D:\temp\path`, which are different paths. This misleading naming can
lead to misuse of the API.
This PR does three things:
1. Deduplicates the methods, keeping only `is_absolute()` in the
`PathStyle` body.
2. Reimplements `PathStyle::has_root()` and `PathStyle::is_absolute()`
based on the standard library’s implementations; the former replaces the
old `is_absolute()`.
3. Updates some callers of the old `is_absolute()` (now `has_root()`,
per step 2) to the new `is_absolute()`, based on each call site’s
semantics and the actual behavior of the methods.
Steps 1 and 2 are pure refactors; the only functional change is in step
3. I believe this fixes some edge cases — or at least surfaces things
that need fixing — though I am not entirely certain that every
replacement is correct.
## Testing
No new tests are introduced. The refactored parts pass the existing
tests in the affected crates.
## Self-review
- [x] I've reviewed my diff for quality, security, reliability, and
performance.
- [x] UI changes follow the
[checklist](https://zed.dev/docs/development/ui-checklist).
- [ ] Tests cover the new or changed behavior.
Release Notes:
- N/A
## Summary
Closes#65376. Replaces #65411 with the hover behavior handled inside
the button component, as requested in review.
My original description of the problem:
> The main problem is when I hover in the blank area the icon color got
changed
Each commit editor button now uses 0.6 opacity normally and 1.0 only
while that button is hovered. The opacity options are handled by
`IconButton` and `ButtonLike`, and the component preview includes an
example.
### Before fix
https://github.com/user-attachments/assets/b7ad6980-e382-4bef-904a-74d877da0291
### After fix
https://github.com/user-attachments/assets/3089e783-c54a-4a94-9e47-a169483aface
## Testing
- Built and ran the development app on macOS. Manually checked
blank-area hover, each icon independently, expand/collapse actions, and
light and dark themes.
- `cargo test --locked -p ui --lib`: all 89 existing tests passed. This
visual change is covered by manual testing; no dedicated automated
regression test was added.
- `cargo fmt --all -- --check` and `git diff --check` passed.
- `cargo build --locked -p zed --bin zed` passed with the macOS
development environment configured.
To check, open a Git repository and its Git panel. Move the pointer
between the blank space below the commit editor buttons and each button.
Only the hovered button should brighten. Also expand and collapse the
commit editor.
## Self-review
- [x] I've reviewed my diff for quality, security, reliability, and
performance.
- [x] UI changes follow the
[checklist](https://zed.dev/docs/development/ui-checklist).
- [x] Tests cover the new or changed behavior through the manual checks
described above.
Release Notes:
- Fixed Git panel commit editor buttons changing opacity when hovering
empty space.
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
displayed when nothing is specifically selected for it.
## Summary
Fix for issue: #65300
Fixes an issue where the there was nothing displayed when no value was
selected for the markdown font family and markdown code font family
settings. See images below.
Current:
<img width="819" height="697" alt="image"
src="https://github.com/user-attachments/assets/10bdf09e-f34c-41cb-8529-94d326c36db1"
/>
Fix:
https://github.com/user-attachments/assets/b511b08d-0e5f-4de2-9f35-b878765a58ba
## Testing
See video above for test. I used Windows for my testing, but it should
be the same for all platforms.
## Self-review
- [x] I've reviewed my diff for quality, security, reliability, and
performance.
- [x] UI changes follow the
[checklist](https://zed.dev/docs/development/ui-checklist).
- [x] Tests cover the new or changed behavior - not applicable.
Release Notes:
- Fixed an issue where no fonts would show for the markdown preview
configurations in the settings UI.
- Advertise the implemented, now-stable session notice and compaction
capabilities without the ACP beta gate.
- Handle structured error/custom stop reasons.
- Honor the stable compaction chunk contract: a first-seen chunk creates
an in-progress entry, later chunks append in receive order regardless of
existing status, and chunk metadata stays delivery-scoped. Existing
status, error, record metadata and timeline positions are preserved.
Release Notes:
- Enable session notices and compaction for ACP agents.
Fixes https://github.com/zed-industries/zed/issues/65320
Key cached highlights by typed event indices instead of source offsets,
which can collide during tab expansion. Add a layout regression test
covering the crash and related edge cases.
Release Notes:
- Fixed crashes on tab-indented code blocks
# Objective
`endpoint_url` was not mentioned anywhere in the gateway docs for the
Bedrock provider, so there was no way to discover that it exists, that
it only redirects the Converse API, or that the built-in GPT and Grok
models are Mantle models that ignore it and go to AWS regardless.
## Solution
- Describe the solution used to achieve the objective above.
Document the setting, the Converse-only scope, and the
`available_models` workaround for gateways that expose the Converse API
but not an OpenAI-compatible one -- including that model names there are
sent verbatim without a cross-region inference prefix.
Separately, it might be nice to describe how the Mantle models can be
redirected using custom `anthropic_compatible` or `openai_compatible`
providers, since Mantle implements the Messages, Responses, and Chat
Completions routes.
## Testing
>- Did you test these changes? If so, how?
Yes, I tested the documented config and confirmed that the model is
displayed in the model picker and that when selected the request is sent
to the gateway. I am using Tailscale Aperture in this environment, and
it captures and logs the entire request and response.
>- Are there any parts that need more testing?
I don't think so.
>- How can other people (reviewers) test your changes? Is there anything
specific they need to know?
You'll need a gateway and access to AWS Bedrock, or evaluate the source
and the tests. Tailscale Aperture is remarkably easy to set up as a
gateway.
>- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
I don't think the platform is relevant, but I was testing Zed on
Windows, with WSL.
## 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
---------
Co-authored-by: Loren Gordon <8457307+lorengordon@users.noreply.github.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
## Summary
Add Claude Opus 5.5 to the Amazon Bedrock BYOK provider. Upstream #64627
added Opus 5.5 to the Anthropic provider; this brings the same model to
Bedrock.
The model mirrors the Opus 5 definition: 1M context window, 128K max
output, tool use, image input, prompt caching, and adaptive thinking
(including xhigh effort). Cross-region inference profiles cover global,
us, ca, eu, au, and jp. Opus 5.5 publishes a jp geo profile that Opus 5
does not.
## Model-level behavior
Opus 5.5 carries model-level constraints, matching the Anthropic
provider:
- Opus 5.5 always runs adaptive thinking and rejects an explicit
thinking.type.disabled opt-out, so the provider never sends one. This
also fixes a substring bug where claude-opus-5-5 matched the Opus 5
request id and incorrectly received the opt-out.
- Adaptive thinking does not accept sampling controls, so temperature is
omitted (top_k and top_p were already unset), as the Anthropic provider
does.
- Forced tool use (tool_choice any) is reported as unsupported by
reusing the shared anthropic::supports_forced_tool_use list, since
Bedrock friendly ids match Anthropic model ids. Automatic tool use is
unaffected, and no other Bedrock model changes behavior.
## Tests
- bedrock: model id, request id, display name, token limits, thinking
modes, and cross-region inference (including jp) for Opus 5.5.
- language_models: Opus 5.5 omits the thinking opt-out and temperature,
and rejects only forced tool choice.
Release Notes:
- Added Claude Opus 5.5 support to the Amazon Bedrock provider
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
## Summary
The FIM edit prediction path (`open_ai_compatible_api` and `ollama`)
always sent a fixed list of 14 stop sequences, covering the control
tokens of every supported prompt format, regardless of the configured
`prompt_format`. OpenAI-compatible servers that enforce the OpenAI limit
of 4 `stop` entries (e.g. vLLM) reject every such request with a 400, so
no predictions appear and the error is only visible in the log.
This change replaces `get_fim_stop_tokens()` with
`fim_stop_tokens(prompt_format)`, which returns only the markers that
`format_fim_prompt` uses for the selected format, plus the format's
end-of-text token where applicable, and never more than 4 entries. The
prompt format is already resolved (including `Infer`) before
`fim::request_prediction` is called, so no settings or schema changes
are needed. `clean_fim_completion` is unchanged and still truncates the
completion at all known markers client-side as a safety net.
Closes#65359
## Testing
- Added `fim_stop_tokens_respect_openai_stop_limit`, which asserts that
every FIM prompt format sends between 1 and 4 stop sequences.
- Added `fim_stop_tokens_match_prompt_markers`, which asserts that every
non end-of-text stop token actually appears in the prompt built by
`format_fim_prompt` for that format, so the two can't drift apart.
- `cargo test -p edit_prediction --lib fim`
To reproduce manually: run vLLM with a Qwen coder model, configure
`edit_predictions.provider` as `open_ai_compatible_api` with
`prompt_format: "qwen"`, and type in a source file. Before this change
every request fails with a 400 about too many stop sequences; after it,
predictions appear and the request body contains exactly 4 `stop`
entries.
## Self-review
- [x] I've reviewed my diff for quality, security, reliability, and
performance.
- ~~[ ] UI changes follow the
[checklist](https://zed.dev/docs/development/ui-checklist).~~
- [x] Tests cover the new or changed behavior.
Release Notes:
- Fixed OpenAI-compatible edit predictions failing on servers that limit
stop sequences to 4.
---------
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
## Summary
Fix Zed AI edit predictions for a selected team organization with no
active subscription. The menu previously showed the personal account's
unlimited allowance even though requests from that organization failed.
- Show a no-subscription explanation instead of the personal allowance.
- Stop prediction requests and disable **Predict Edit at Cursor** while
that organization is selected.
- Show an unavailable indicator and tooltip. Update them when the
organization changes.
Personal accounts, subscribed organizations, and other prediction
providers keep their existing behavior. Cloud access rules, billing
records, and `deny-free-edit-predictions` are unchanged.
## Tests
- `cargo test -p client -p edit_prediction -p edit_prediction_ui` — 22
client, 101 edit-prediction, and 5 UI tests passed.
- `./script/clippy -p client -p edit_prediction -p edit_prediction_ui` —
passed with warnings denied.
- `cargo fmt --all -- --check` and `git diff --check` — passed.
Tests cover subscription state, blocked requests, another prediction
provider, switching to a subscribed organization, and main's Free-plan
handling. The new UI still needs a manual check. Requests already in
progress are not cancelled when the organization changes.
Release Notes:
- Fixed edit predictions showing an unlimited allowance and available
controls for a selected team organization with no active subscription.
## Summary
On macOS 27, `WindowBackgroundAppearance::Blurred` doesn't blur
anything: the window is only transparent, so whatever is behind it shows
through sharp. In Zed, this affects themes with
`"background.appearance": "blurred"`.
`BlurredView` is an `NSVisualEffectView` with the `Selection` material,
and `blurred_view_update_layer` strips the material's tint and
saturation so that only its backdrop blur remains. On macOS 27,
`Selection` no longer has a `CABackdropLayer`, so there's no blur left
to keep. This switches to `UnderWindowBackground`, which still has one,
so the existing stripping leaves the same colorless blur as before. It
also sets the behind-window blending mode explicitly (it's already the
default).
#64284 describes the same root cause, and #62605 proposed the same
change; it was closed while waiting on the before/after screenshots
requested there, which are below.
A translucent window with `WindowBackgroundAppearance::Blurred` over a
striped window, on macOS 27.0 (26A428):
| Before (`main`) | After (this PR) |
| --- | --- |
| <img width="680" alt="Before: the stripes behind the translucent
window are sharp"
src="https://github.com/user-attachments/assets/5ec94418-7313-4595-bf29-6a6646454a24"
/> | <img width="680" alt="After: the stripes behind the translucent
window are blurred"
src="https://github.com/user-attachments/assets/2901e570-8db9-4e1f-a152-fc8c1895e0c3"
/> |
<details>
<summary>Example</summary>
```rust
use std::rc::Rc;
use gpui::{
AppContext as _, Application, Bounds, Context, IntoElement, Render, Window,
WindowBackgroundAppearance, WindowBounds, WindowOptions, div, point, prelude::*, px, rgb, rgba,
size,
};
use gpui_macos::MacPlatform;
struct Stripes;
impl Render for Stripes {
fn render(&mut self, _: &mut Window, _: &mut Context<Self>) -> impl IntoElement {
let colors = [0xff3b30, 0xffffff, 0x007aff, 0x000000];
div()
.size_full()
.flex()
.children((0..60).map(move |i| div().w(px(24.)).h_full().bg(rgb(colors[i % 4]))))
}
}
struct Translucent;
impl Render for Translucent {
fn render(&mut self, _: &mut Window, _: &mut Context<Self>) -> impl IntoElement {
div()
.size_full()
.flex()
.items_center()
.justify_center()
.bg(rgba(0x0d0e1066))
.text_color(rgb(0xffffff))
.text_xl()
.child("WindowBackgroundAppearance::Blurred")
}
}
fn main() {
Application::with_platform(Rc::new(MacPlatform::new(false))).run(|cx| {
let bounds = |x, y, w, h| {
Some(WindowBounds::Windowed(Bounds::new(point(px(x), px(y)), size(px(w), px(h)))))
};
cx.open_window(
WindowOptions { window_bounds: bounds(200., 200., 900., 560.), focus: false, ..Default::default() },
|_, cx| cx.new(|_| Stripes),
)
.unwrap();
cx.open_window(
WindowOptions {
window_bounds: bounds(350., 300., 600., 340.),
window_background: WindowBackgroundAppearance::Blurred,
..Default::default()
},
|_, cx| cx.new(|_| Translucent),
)
.unwrap();
cx.activate(true);
});
}
```
</details>
## Testing
- Ran the example above against `main` and against this branch on macOS
27.0 (26A428), Apple silicon: on `main` the stripes behind the window
stay sharp; with this change they're blurred.
- Inspected the `BlurredView`'s layers at runtime: with `Selection`
there's no `CABackdropLayer`; with `UnderWindowBackground` there is one,
and after the existing tint and saturation stripping only its
`sdrNormalize` and `gaussianBlur` filters remain.
- Not tested on macOS 26 or earlier. `UnderWindowBackground` is
available from macOS 10.14.
To check it, run the example on macOS 27, or use a Zed theme with
`"background.appearance": "blurred"` and put a window with sharp detail
behind Zed.
## Self-review
- [x] I've reviewed my diff for quality, security, reliability, and
performance.
- [x] UI changes follow the
[checklist](https://zed.dev/docs/development/ui-checklist).
Release Notes:
- Fixed blurred window backgrounds not blurring on macOS 27.
- [GPUI] Fixed windows with `WindowBackgroundAppearance::Blurred` being
transparent but not blurred on macOS 27.
# Objective
Add GPT-6 Astra and Claude Fable 5.1 as built-in Amazon Bedrock models.
## Solution
- Use `bedrock-runtime` Converse for both models. Astra's Mantle
endpoint offers Responses and Chat Completions; Converse lets it reuse
Zed's Bedrock client. Fable 5.1 uses the same endpoint and API as Fable
5.
- Add the documented model IDs, geo/global profiles, token limits, and
capabilities. Astra has a 1,050,000-token context window; Fable 5.1 has
1,000,000. Both allow 128,000 output tokens.
- Handle Astra's reasoning fields, encrypted replay, and tool-result
images. Apply Fable 5.1's adaptive thinking, binding controls, and
tool-choice restrictions.
- Limit inference routing to each model's supported source Regions, keep
model-specific reasoning out of other Bedrock models' histories, group
parallel tool results before their images, and report Fable and Astra
refusals.
## Testing
- `cargo test -p bedrock -p language_models --lib`: 33 Bedrock and 116
language-model tests passed. The provider suite was rerun after the
final refusal-handling change.
- `./script/clippy -p bedrock -p language_models`, `cargo fmt -p bedrock
-p language_models -- --check`, and `cd docs && npx --yes prettier@3.5.0
--check src/`: passed.
- Live `bedrock-runtime` Converse/ConverseStream in `us-east-1`: Astra
and Fable 5.1 responded successfully. Astra's streamed encrypted
reasoning replayed on a second turn. Astra accepted forced tool use;
Fable 5.1 rejected it as expected.
- A live Astra request with two parallel tool results followed by two
sibling images succeeded. `aws bedrock list-inference-profiles`
confirmed the commercial US and EU profiles tested.
- GovCloud profile routing was not tested: no GovCloud credentials were
available. Zed's GUI was not run.
## References
- [GPT-6 Astra Bedrock model
card](https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-openai-gpt-6-astra.html)
- [Claude Fable 5.1 Bedrock model
card](https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-anthropic-claude-fable-5-1.html)
Release Notes:
- Added GPT-6 Astra and Claude Fable 5.1 to the Amazon Bedrock provider.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Replace canonical v1 tool locations with a Zed-owned `ToolCallLocation`
as the next bounded ACP v2 data-model cleanup after #65350.
- Retain raw `PathBuf`, line, and item metadata, including relative
native paths and absolute protocol paths.
- Move v1/v2 location fields directly into the canonical model instead
of converting v2 locations into v1 wrappers.
- Compare raw `OsStr` spelling so component-equivalent path changes
replace retained source and invalidate old resolved projections.
- Keep resolved editor locations as projections and migrate the existing
image-output UI consumer.
- Add focused conversion, raw-equality, and patch/projection
regressions, including Unix non-UTF-8 paths.
Release Notes:
- N/A
## Summary
Removes the min width of the remote project picker to responsibly scale
with the size it actually needs and not have awkward extra padding at
the bottom.
## Testing
Manual, see screenshots
| Before | After |
| -- | -- |
| <img width="896" height="792" alt="Bildschirmfoto 2026-10-09 um 12 49
41"
src="https://github.com/user-attachments/assets/be77577d-bfba-4209-9329-e7579e507af6"
/> | <img width="896" height="792" alt="Bildschirmfoto 2026-10-09 um 12
48 55"
src="https://github.com/user-attachments/assets/b880c50b-598d-485c-a30f-a97ff4ee609b"
/> |
## Self-review
- [X] I've reviewed my diff for quality, security, reliability, and
performance.
- [ ] UI changes follow the
[checklist](https://zed.dev/docs/development/ui-checklist).
- [ ] Tests cover the new or changed behavior.
Release Notes:
- Fixed the remote projects picker sometimes reserving more space than
needed.
Standardize shared, application, and native session/tool-call identity
on ACP v2 ID wrappers as the next bounded ACP v2 migration slice.
- Use v2 `SessionId` and `ToolCallId` across connection APIs, canonical
thread/tool/permission state, native session storage, UI navigation, and
sidebar consumers.
- Keep legacy wire and native tool payloads as v1, converting IDs at
those boundaries by moving or cloning the existing `Arc<str>` rather
than stringifying or normalizing them.
- Preserve existing serialized ID strings, database schemas, drafts
without session IDs, subagent metadata, and mention records.
Release Notes:
- N/A
## Summary
Closes#64454
Going back (`ctrl-o` in Vim mode, the mouse back button, or the back
button in the tab bar) after switching away from a markdown preview
skipped the preview and landed on the tab before it.
Panes record history entries when an item is deactivated, but only if
the item adds itself: `Item::set_nav_history` and `Item::deactivated`
default to doing nothing, and `MarkdownPreviewView` didn't implement
either. The preview now stores its `ItemNavHistory` and pushes an entry
when deactivated, the same way other items do.
The entry carries no navigation data, so going back reactivates the
preview without restoring its scroll position. If the preview has been
closed, its entry is skipped, since it has no project path to reopen.
In Vim mode, `ctrl-o`/`ctrl-i` were only bound for editors, so pressing
them while the preview was focused opened the file dialog instead of
navigating. They're now also bound in the `MarkdownPreview` context.
## Testing
- Added `go_back_returns_to_preview_after_opening_another_file`. It
opens a markdown file and its preview, opens another file, goes back,
and asserts that the preview is active again. It fails without the fix.
- Manually tested on Linux (KDE Wayland): open a markdown file, open its
preview, open another file with the file finder, then go back with
`ctrl-o` and with the tab bar's back button. Both return to the preview,
and going forward returns to the other file.
- In Vim mode, `ctrl-o` and `ctrl-i` from the focused preview now go
back and forward instead of opening the file dialog.
## Self-review
- [x] I've reviewed my diff for quality, security, reliability, and
performance.
- [x] Tests cover the new or changed behavior.
Release Notes:
- Fixed navigating back to a markdown preview tab after switching to
another file, and `ctrl-o`/`ctrl-i` in Vim mode opening the file dialog
when the preview is focused.
## Summary
Closes#65147
Fixes partially unclickable rows of wrapped links in Markdown tables,
affecting Markdown previews and rendered agent responses. A detailed
video of the bug, provided by issue author
[@machadinhos](https://github.com/machadinhos), can be found
[here](https://github-production-user-asset-6210df.s3.amazonaws.com/101654160/665208322-97183453-77c1-4364-94cf-d6f7eae85810.mp4?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAVCODYLSA53PQK4ZA%2F20261008%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20261008T220525Z&X-Amz-Expires=300&X-Amz-Signature=c92d295ab82d512815bd9d4dc011293c3c8a2b34134781823d835d757a633f11&X-Amz-SignedHeaders=host&response-content-type=video%2Fmp4).
Currently vertically centered table cells can cause hit testing to
mistake a position inside a later cell for a gap between text blocks.
Defer the first gap fallback until all text blocks have been checked,
allowing actual text hits to take precedence.
## Testing
Implemented `#[gpui::test]'s` for different table layouts and link
lengths
- 6f8a223669d9b8eb6c8c810c3467dbe8dea72230
- 87e2e59176f3258eb8c200749823ee68af87167e
- b6456a474c5daa871ad57c08894140f157296490
- 15b581003241be0b2868a663ad56a274569cc7a3
The fix passes all 188/188 tests for the markdown crate, the previous
implementation fails all newly added test cases.
```text
test tests::test_wrapped_table_links_hit_testing ... ok
test tests::test_wrapped_table_link_mouse_release ... ok
test tests::test_wrapped_table_link_unicode_and_surrounding_text ... ok
test tests::test_wrapped_table_link_column_positions_and_alignment ... ok
test tests::test_wrapped_table_link_hover_click_and_resize ... ok
test tests::test_copy_button_copies_commonmark_code_block_content ... ok
test tests::test_wrapped_table_link_interactions_in_all_columns ... ok
test result: ok. 188 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 4.89s
```
Build passed on **macOS** and **Windows**
## Self-review
- [x] I've reviewed my diff for quality, security, reliability, and
performance.
- [ ] UI changes follow the
[checklist](https://zed.dev/docs/development/ui-checklist).
- [x] Tests cover the new or changed behavior.
Release Notes:
- Fixed wrapped links in Markdown tables being partially unclickable in
Markdown previews and agent responses
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
## Summary
I'm building a single-threaded web app on `gpui_web`, served as static
files, and I can't build it on stable Rust. `gpui_web`'s default feature
`multithreaded` pulls in `wasm_thread`, which needs the unstable
`stdarch_wasm_atomic_wait` feature gate. With `default-features = false`
the crate checks clean on stable, but `gpui_platform` depends on
`gpui_web` with defaults, so using the platform helper on wasm,
including its `single_threaded_web()`, brings the feature and nightly
back. Threads in a browser also need COOP/COEP headers and `build-std`,
so for a static site the single-threaded platform is the normal case.
This declares `gpui_web` without default features in the workspace and
has `gpui_platform` forward `multithreaded`, on by default. Nothing
changes unless a consumer opts out with `default-features = false`.
`hello_web` keeps its threads since it takes the helper's defaults.
## Testing
In this workspace, on stable: `cargo check -p gpui_platform --target
wasm32-unknown-unknown --no-default-features`. On nightly, the same with
defaults, which is the status quo path. `cargo check -p gpui_platform`
on the host, since `gpui_web` is only a wasm dependency and the feature
reference must still be accepted there. And `cargo tree -p gpui_platform
-e features --target wasm32-unknown-unknown` with and without
`--no-default-features`, showing `wasm_thread` present and then absent.
## Self-review
- [x] I've reviewed my diff for quality, security, reliability, and
performance.
- [ ] UI changes follow the
[checklist](https://zed.dev/docs/development/ui-checklist). (No UI
change.)
- [ ] Tests cover the new or changed behavior. (A manifest change, the
tree and check commands above are the test.)
I used an AI assistant, which helped me trace where the feature gets
switched on. I've reviewed the changes and verified the checks above
pass on my machine.
Release Notes:
- N/A
- [GPUI] The multithreaded feature for `gpui_web` can now be forwarded
Co-authored-by: Lukas Wirth <lukas@zed.dev>
## Summary
`uniform_list` computed the visible range and each item's origin from
the scroll offset in `f32`. Past 2^27px, adjacent `f32` values are 16px
apart. In a list of 24px items, that point is about 5.6 million items
in. From there:
- items are placed with alternating 16px and 32px gaps instead of 24px;
- the visible range can start one item late, leaving a blank strip at
the top of the list (and sometimes at the bottom);
- smaller errors start earlier, such as a 1px offset at about a million
items, because the large offset is added to the viewport origin in
`f32`.
This change computes the visible item indices and the viewport-relative
item offsets in `f64`, then converts only the small offsets back to
`Pixels`. The arithmetic stays local to `uniform_list`'s prepaint, and
nothing changes for ordinary list sizes.
The stored scroll offset (`ScrollHandle`) is still `f32`, so very far
down a long list the scroll position itself stays quantized.
`scroll_to_item` can land up to half a step (8px at this depth) away
from the item's exact top, and very small scroll deltas can be lost.
Fixing that would mean changing the scroll offset representation used by
every scrollable element, so I left it out of this PR.
I hit this in a GPUI file search app showing ~9.8 million results in a
table built on `uniform_list`:
<img width="1336" height="874" alt="image"
src="https://github.com/user-attachments/assets/c25b2c1d-3151-4a87-9742-c3820c1d4aac"
/>
## Testing
- Added `test_item_positions_far_down_long_list`: 10M items of 24px in a
200px list, with the scroll offset set 16px into item 9,000,002. It
asserts which items render and their tops (`-16, 8, 32, … 176`).
- On `main` it fails: item 9,000,002 is missing and the tops are `0, 32,
64, 80, 96, 128, …`.
- With this change it passes.
- `cargo test -p gpui --lib uniform_list` passes, including the existing
`test_scroll_strategy_nearest`. `cargo clippy -p gpui --lib --tests` is
clean.
- Manually on Windows, in a real window with 9,824,090 rows of 24px, I
checked 12 scroll positions, including odd rows reached from far away.
Each check verifies consecutive rows, uniform 24px spacing, and that
rows cover the viewport top and bottom.
- Before: 7 of 12 failed.
- After: 12 of 12 passed.
To reproduce: run the new test against `main`, or render a
`uniform_list` with ~10M fixed-height items and scroll near the end.
## Self-review
- [x] I've reviewed my diff for quality, security, reliability, and
performance.
- [x] UI changes follow the
[checklist](https://zed.dev/docs/development/ui-checklist). (No visible
UI changes in Zed.)
- [x] Tests cover the new or changed behavior.
I used Claude to help investigate this and write the change. I've
reviewed it and understand it.
Release Notes:
- [GPUI] Fixed layout glitches for uniform_lists with a lot of
virtualized content.
---------
Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Pull request [#61335] fixed this issue for the project search, but the
text finder (the "telescope" search) still had the same issue. This
commit copies that behavior by reusing that logic.
#### Summary
When you have the regex mode turned on in the text finder, the selected
query isn't escaped.
This recording shows how it's escaped in the project search, but not in
the telescope search:
https://github.com/user-attachments/assets/02554192-5939-4cef-9d2e-201de332568f
After the fix:
https://github.com/user-attachments/assets/4bc9501a-493d-4b28-9793-166c3a7e230c
#### Testing
To see the issue:
- Open the text finder
- Turn on the regex mode
- Select something with any "special" regex character e.g.`(`
- Call the text finder
=> The query isn't escaped
## Self-review
- [x] I've reviewed my diff for quality, security, reliability, and
performance.
- [x] UI changes follow the
[checklist](https://zed.dev/docs/development/ui-checklist).
- [x] Tests cover the new or changed behavior.
Release Notes:
- Fixed text finder search queries seeded from the current selection
being interpreted as a regular expression instead of literal text when
regex mode was enabled.
[#61335]: https://github.com/zed-industries/zed/pull/61335
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
Frame and hang telemetry judged every frame against a fixed 24 ms
budget. That's too lax on 120–360 Hz displays and too strict at 30 Hz,
so the numbers couldn't be compared across users or catch regressions on
fast displays. This judges each frame against its window's display
refresh interval (from #65059), as measurement version 3.
**Frame timing.** A frame's work runs from the later of its frame signal
and its first invalidation until its submission to the platform begins,
on every platform, so time spent waiting for a late frame signal or
inside the submission doesn't count. A frame is late when its work
exceeds one refresh interval, but never less than 8.33 ms (one refresh
at 120 Hz), since frames rarely fit a single refresh on faster displays
yet; on displays whose refresh interval is unknown (X11, web) the budget
is 16.7 ms. Missed refreshes still count against the real interval.
**Frame Duration Report**, per window and refresh interval: on-time,
late, and unmeasured frame counts and missed refreshes, overall and for
frames that responded to input; work (as a percentage of the refresh
interval) and draw-time buckets, computed from hdrhistogram histograms;
GPU and CPU.
**Hang Incidents.** Threshold incidents (one event of 100 ms or more)
are unchanged. Budget incidents are split by trigger:
- `late_frame`: a presented frame over its budget, listing the events
that overlap that frame's work;
- `blocking_work`: in an interval with no measured frame, a single event
of at least the frame budget (16.7 ms in release builds), long enough to
delay a frame. Total foreground time across an interval no longer
counts, since gaps between short work don't block frames.
Draw contributors carry request-layout, prepaint, and paint times, and
any entity view phase whose own work (excluding nested views) takes 0.5
ms or more becomes a contributor named by its view type. Events also
report counts per trigger, incidents during active use (within a minute
of a key press, click, or scroll) with active seconds for rates per
active hour, stall buckets, and contributor totals summed across every
incident (`view:<type>:<phase>`, `action:…`, `task:…`).
**Verification.** With a synthetic render delay on a 240 Hz display,
on-time frames went from 99.9% at no delay to 0% at 6 ms. In a real Zed
on Linux at 360 Hz, scrolling a markdown preview with #63138's per-frame
code-block highlighting reintroduced roughly doubled missed refreshes
per frame (3.2 to 6.0) and attributed the extra time to
`MarkdownPreviewView`'s request-layout phase. Profiler overhead was
+2.3% of main-thread time in a 1,500-view GPUI stress test and about
0.3% in the Zed scroll run. Not yet verified: Windows, and input-driven
frames from real use. Time spent inside the platform submission (GPU,
compositor) isn't measured on any platform.
Release Notes:
- [GPUI] Improved frame and hang telemetry to measure frames against
each window's display refresh rate
This moves three pieces of macOS platform code into `gpui_apple` so the
upcoming iOS backend (#63068) can share them: the CoreText text system,
the Keychain credential helpers, and thermal-state reporting. macOS
behaves the same as before. Credential reads still return `None` when
nothing is stored or the prompt is canceled, deleting a missing
credential is still an error, and text rendering keeps font smoothing
and dilation. Along the way the Keychain and OpenType code switch from
hand-written FFI to the generated objc2 bindings, which also fixes an
over-release of temporary CoreText feature strings, and thermal
notifications now reach the main thread through a channel instead of a
raw-pointer `dispatch_async_f`. It also replaces the old `core-video`
crate with `objc2-core-video`, because `core-video` pulls in
`io-surface` and `cgl`, which link OpenGL and break iOS builds. That
changes GPUI's public surface API: `SurfaceSource`, `PaintSurface`, and
`Window::paint_surface` now take
`CFRetained<objc2_core_video::CVPixelBuffer>`, and LiveKit's video
frames follow suit. I tested this with the gpui, gpui_apple, and
gpui_macos test suites, including a new Metal test that renders a real
NV12 pixel buffer, plus checks of the `zed` and `remote_server` builds;
the iOS link was verified on the iOS branch. LiveKit playback and the
Keychain paths are only compile-checked, so a quick sign-in/sign-out on
macOS before relying on this is worth doing.
Release Notes:
- [GPUI] Added shared Apple CoreText text rendering, Keychain, and
thermal-state services in `gpui_apple`, and migrated `SurfaceSource`,
`PaintSurface`, and `Window::paint_surface` from `core-video`'s
`CVPixelBuffer` to `CFRetained<objc2_core_video::CVPixelBuffer>`
Upgrade ACP SDK and derive to the published **3.2.0** release and use
its prepared requests/cancellation handles to register new sessions
before processing their first updates.
Previously, `session/new` used an ordinary response future. A peer could
reply and immediately send an update before foreground session
registration, causing the update to be discarded as belonging to an
unknown session. The prepared ordered callback now delivers the result
to the creation task and waits for synchronous foreground registration
to be acknowledged before later inbound dispatch proceeds.
Caller abandonment explicitly requests RPC cancellation through the
SDK-owned handle without discarding eventual response handling. If an
abandoned caller receives a late successful session, Zed requests close
when the peer advertises support. Peer rejection, EOF, and abandonment
release the registration barrier; a failed creation does not terminate
an otherwise usable connection. Default mode/config work remains
asynchronous and is not awaited inside the barrier.
The callback does not retain `Rc<AcpConnection>` or await later traffic
on the same connection. Cancellation is request-scoped and cooperative,
not cancellation of already-completed RPCs or ongoing session work.
Client writes no longer hide already-captured agent stderr when startup
fails. A deterministic interleaving regression covers this
diagnostic-selection race without weakening the physical-process startup
assertion or adding retries. Caller-drop cancellation uses the existing
`util::defer` helper rather than a bespoke guard type.
Release Notes:
- Fixed initial ACP session updates being dropped and agent startup
diagnostics being lost.
When a language server omits the `range` field in its hover response and
syntax tree fallback fails, Zed falls back to a zero-width hover range
(`anchor..anchor`). Previously, because the check used an exact offset
match, any slight cursor movement within the same symbol would treat it
as a new hover target, immediately dismissing the existing popover and
triggering repeated requests. This caused flickering and made it
impossible to move the cursor into the popover to interact with it.
This PR fixes the issue by falling back to `surrounding_word` when
checking if an anchor is contained within a zero-width hover range,
allowing cursor movement within the same word without dismissing the
popover.
Release Notes:
- Fixed hover popovers flickering or prematurely dismissing on mouse
movement when using language servers that omit range information.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Closes#56525
# Objective
Zed's branch picker shows a "Delete Branch" trash icon for both local
and remote-tracking branches. For remote-tracking branches (e.g.
`origin/feature`), this action only deletes the local tracking ref (`git
branch -dr`) — it never contacts the remote, and the branch still exists
on the actual remote repository. The label gives no indication of this,
so users can't tell whether the action is local-only or will delete the
branch upstream.
## Solution
`Branch.is_remote()` was already used internally to pick the right git
flag (`-d`/`-dr`) when deleting, but this distinction was never surfaced
in the UI copy. This PR threads that same `is_remote` value through to
the delete tooltip and branches the displayed text on it:
- Local branch: unchanged — "Delete Branch" / "Force Delete Branch",
with the existing "Hold alt to force delete" hint.
- Remote-tracking branch: "Delete Local Tracking Branch" / "Force Delete
Local Tracking Branch", with a "Does not delete the branch on the
remote" hint.
Also updated the stale `DeleteBranch`/`ForceDeleteBranch` action
doc-comments, which still said "Deletes the selected git branch or
remote" — a leftover from an earlier (already-fixed, see #48338)
implementation that really did delete the whole remote config.
No behavior change to the underlying delete logic — this is a copy-only
fix that makes existing, correct behavior legible to the user, per
[maintainer guidance on the
issue](https://github.com/zed-industries/zed/issues/56525#issuecomment-5095069397).
## Testing
- `cargo check -p git_ui` passes.
- Manually verified in the branch picker: hovering the trash icon on a
local branch shows the original text; hovering it on a `origin/...`
remote-tracking branch shows the new "local tracking branch" text and
meta line, for both the plain and alt-held (force) states.
- No behavior/logic change, so no new automated test was added — purely
a UI string change in `DeleteBranchTooltip::render`.
- Reviewers: open a repo with at least one remote-tracking branch
visible in the branch picker (`git fetch` a repo with a branch you don't
have locally), hover the delete icon on it vs. on a local branch, and
compare tooltip text.
## 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: hovering the trash icon on `origin/feature` shows "Delete
Branch" / "Hold alt to force delete" — identical to a local branch, no
indication the remote is untouched.
After: hovering it shows "Delete Local Tracking Branch" with meta text
"Does not delete the branch on the remote".
---
Release Notes:
- Improved the branch picker to clarify that deleting a remote-tracking
branch only removes the local ref, and removed the force delete option
for remote-tracking branches since it had no effect.
---------
Co-authored-by: Agus Zubiaga <agus@zed.dev>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
## Summary
> PR #62597 changed the Threads Sidebar background color, but introduced
a regression where the background becomes transparent in some themes,
such as VSCode Dark Modern, which assigns a semi-transparent color to
`surface_background`.
>
> This PR blends the Threads Sidebar background color with `background`
to prevent it from becoming transparent.
>
> Additionally, while the default themes are unaffected, the Threads
Sidebar background was found to be inconsistent with other panels in
themes such as VSCode Dark Modern. To address this, this PR also changes
the blended color from `surface_background` to `panel_background`,
preserving the appearance of Zed's bundled themes while improving
consistency in other themes.
#62597でThreads
Sidebarの背景色が変更されましたが、`surface_background`に半透明の色が割り当てられているVSCode Dark
Modernなど一部のテーマでサイドバーの背景色が透明になってしまうリグレッションが発生しました。
このPRでは、Threads Sidebarの背景色を`background`とブレンドし、背景色が透明になることを防ぎます。
また、デフォルトのテーマでは問題ありませんが、VSCode Dark ModernなどではThreads
Sidebarの背景色がほかのパネルと一致せず一貫性がなくなることが判明したため、ブレンドする色を`surface_background`から`panel_background`に変更しました。これにより、Zedに同梱されているテーマでの外観を維持しつつ、一部のテーマで背景色に一貫性を持たせます。
Before:
<img width="867" height="457" alt="image"
src="https://github.com/user-attachments/assets/c98e5063-abee-4110-bf6c-2b7ae91d2fbc"
/>
After:
<img width="846" height="388" alt="image"
src="https://github.com/user-attachments/assets/72e253c4-a713-4245-9c18-ce57572bbb6c"
/>
Closes#65310
## Testing
> Install a theme that assigns a semi-transparent or transparent color
to `surface_background`, such as VSCode Dark Modern.
>
> Before this change, the Threads Sidebar background appears transparent
(or white on Windows). After this change, the background remains opaque.
VSCode Dark
Modernテーマなど、`surface_background`に半透明または透明の色が割り当てられているテーマをインストールします。変更前はThreads
Sidebarの背景色が透明（Windowsでは白色）になってしまいますが、変更後は不透明の背景色になります。
## Self-review
- [x] I've reviewed my diff for quality, security, reliability, and
performance.
- [x] UI changes follow the
[checklist](https://zed.dev/docs/development/ui-checklist).
- [x] Tests cover the new or changed behavior.
Release Notes:
- Fixed an issue where the background color of the Threads Sidebar was
transparent in some themes
GPUI now tracks connected displays and the display each window is on.
`App` caches every display's bounds and refresh interval, rereading them
whenever a platform reports that displays may have changed, and reports
`Added`, `Removed`, and `Changed { id, changes }` through
`App::observe_displays`. Windows report only moves between displays;
`Window::refresh_interval(cx)` reads App's cache, and
`Window`/`Context::observe_window_display` fire when a window moves or
its display changes, with App updated first. This is implemented on
macOS, Windows (whose platform window is now a hidden top-level window
so it receives `WM_DISPLAYCHANGE` and `WM_ENDSESSION` with no windows
open), and Wayland, and was exercised at runtime on all three by
switching refresh rates; X11 and web report no refresh interval, and
headless Linux now reports no displays. Planned consumers are
refresh-rate-aware frame telemetry and the screen-share display picker.
Release Notes:
- [GPUI] Added `App::observe_displays`, `Window::refresh_interval`, and
`observe_window_display` for tracking connected displays, their refresh
rates, and each window's display
Replace the bounded `futures::mpsc` response-body channel with
`async-channel`, using the workspace's default-features-disabled
configuration. The browser Fetch pump runs on the main thread while
response bodies can be consumed by workers. `futures::mpsc` locks an
internal sender mutex during `poll_flush`; contention can attempt an
unsupported `Atomics.wait` on the browser main thread.
Release Notes:
- [GPUI] Fixed a browser crash when streaming Fetch response bodies to
background workers.
Pin `khronos-egl` to the Zed fork's defensive error-handling fix for
[FR-522](https://linear.app/zed-industries/issue/FR-522/zed-c82-called-optionunwrap-on-a-none-value).
An EGL call can fail while `eglGetError()` reports `EGL_SUCCESS`. The
binding currently unwraps the missing error, which caused the reported
panic during Wayland surface creation. The fork returns a distinct
`Error::Unreported` instead, preserves real EGL errors, and applies the
same rule consistently to failed-call wrappers.
- Fork commit:
[42214b3](42214b3634).
- Upstream PR:
[timothee-haudebourg/khronos-egl#37](https://github.com/timothee-haudebourg/khronos-egl/pull/37).
- This PR changes only `Cargo.toml` and `Cargo.lock`. Remove the
temporary fork patch once an upstream release includes the fix.
The new public error variant is source-breaking for exhaustive matches,
so the upstream PR explicitly leaves release/versioning to the
maintainer. This integration uses a controlled Git pin and has been
checked against the GLES downstream consumer.
Release Notes:
- [GPUI] Fixed a panic when EGL calls fail without reporting an error.
## Summary
Closes#64273
Running a case conversion (or any other `manipulate_text` command) with
several cursors inside the same word inserted the converted word once
per cursor:
| Before | Upper case result |
|---|---|
| `some_ˇvariˇable_naˇme` |
`SOME_VARIABLE_NAMESOME_VARIABLE_NAMESOME_VARIABLE_NAME` |
### Cause
`manipulate_text` expands each empty selection to its surrounding word,
so several cursors in one word produce identical ranges, and a cursor's
word can also overlap other selections. The buffer coalesces overlapping
edits by concatenating their texts, so the converted text was inserted
once per selection.
### Fix
After expanding, the ranges are sorted by start and overlapping ones are
merged, then each merged range is transformed once. Sorting matters
because expanding a cursor can move its range's start before earlier
selections (e.g. `«a»b«cd»e|f`, where the cursor's word starts at `a`).
Selections that only touch are kept separate, so non-overlapping
selections behave exactly as before.
This applies to every command that goes through `manipulate_text`: all
case conversions, ROT13/ROT47, and Base64 encode/decode.
## Testing
Added `test_multicursor_manipulate_text`, which reports every failing
case at once. It covers:
- multiple cursors in one word, and in two different words
- a cursor's word partially overlapping a selection
- a cursor's word starting before earlier selections
- a conversion that changes nothing, which keeps the cursors unchanged
## Self-review
- [x] I've reviewed my diff for quality, security, reliability, and
performance.
- [x] Tests cover the new or changed behavior.
Release Notes:
- Fixed case conversion and other text transformation commands
duplicating the word when multiple cursors are inside it.
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
## Summary
What problem does this solve, how, and why does this change matter?
Use "Closes #123" for each issue resolved.
Include artifacts produced when testing: before/after screenshots, GIFs,
videos, benchmarks.
## Testing
Manually test your changes; report results, mention platforms if
relevant.
How can reviewers test this easily? Include setup and steps.
## Self-review
- [ ] I've reviewed my diff for quality, security, reliability, and
performance.
- [ ] UI changes follow the
[checklist](https://zed.dev/docs/development/ui-checklist).
- [ ] Tests cover the new or changed behavior.
Release Notes:
- Added telemetry for usage of checkpointing feature in the agent panel.
This telemetry is opt-in and has no effect with telemetry disabled.
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
