`LanguageModelCompletionError` had eight near-duplicate variants
(PromptTooLarge, RateLimitExceeded, ServerOverloaded, InvalidEncryptedContent,
AuthenticationError, PermissionError, ApiEndpointNotFound, PaymentRequired)
that each independently encoded a provider-semantic outcome, alongside
ProviderRejection for everything else. Providers had to choose between two
places to report the same kind of failure, and retry logic had to special-case
each variant even though the underlying decision (retry or not, how long)
depended only on the HTTP status.
This collapses all of those into ProviderRejection, adding a `category:
ProviderErrorCategory` field that's derived once, centrally, in
`ProviderErrorCategory::classify` (status + code + message in, category out).
Provider-specific wire parsing (Anthropic's ApiErrorCode, OpenRouter's
ApiErrorCode) stays local, but now maps into this shared category instead of
duplicating the same classification. `status`, `code`, `message`, and
`retry_after` are still preserved verbatim, including for known categories, so
nothing that inspected the raw wire details loses information.
While touching OpenRouter's error path, fixed a real bug: `ApiErrorCode::
from_status` defaulted any unmapped HTTP status to `ApiError` (502), silently
replacing e.g. a real 500 with a fabricated 502. `ApiError` now carries the
real status separately from the (optional) documented code, so unmapped
statuses are preserved and classified as `Other` instead of being coerced into
a wrong, documented one.
Restored the retry-strategy enum in `agent::Thread` (a prior commit on this
branch had flattened it into a single-shape struct, losing the distinction
between "wait a fixed amount" and "back off exponentially"). ProviderRejection
now retries only for the same status set Delta already uses (408, 425, 429,
and all 5xx including the unofficial 529): a provider-given `retry_after`
becomes a fixed delay, otherwise attempts back off exponentially from
BASE_RETRY_DELAY. A rejection with no status (e.g. a content-policy code like
`cyber_policy`) or a non-retryable status never retries, since resending the
same request would just repeat the same rejection.
Testing:
- `cargo nextest run` across every touched crate (agent, agent_ui, anthropic,
open_ai, open_router, copilot_chat, language_model_core, language_models,
language_models_cloud): 1430 passed, 11 skipped (network-gated unit evals).
- `cargo check --workspace --all-targets`: clean.
- `cargo fmt --check`: clean.
- Added unit tests for the new retry rule (status-less and non-retryable
rejections don't retry; retryable statuses use exponential backoff without
`retry_after` and a fixed delay with it) and for OpenRouter preserving an
unmapped status instead of fabricating 502.
Environment note: `corgi` cannot build anything depending on `gpui` from this
worktree (it rejects gpui's build output for embedding an absolute path); used
plain `cargo`/`cargo nextest` for those crates instead, logged in
~/.corgi-feedback per instructions.
# Objective
Fixes#43932.
Extensions built with `zed_extension_api` 0.0.6 or 0.1 pass the absolute
worktree root in `SettingsLocation.path`. After #38744 changed core
settings locations to `RelPath`, `RelPath::new` returns an error for
that absolute value. The conversion produces `None`, so
`ProjectSettings::get` falls back to global settings. This regressed the
behavior fixed in #10859.
The current LaTeX and Typst extensions both use API 0.1, matching the
two extension surfaces reported in the issue.
# Solution
For the 0.0.6 and 0.1 WIT adapters, treat the legacy path as the
worktree root (`RelPath::empty()`) and preserve the worktree ID. API 0.2
and later already send an empty relative path, so their behavior is
unchanged.
The two version adapters each have a regression test for the legacy
absolute-root input.
# Testing
- `cargo test -p extension_host
settings_location_targets_the_worktree_root` (2 passed)
- `cargo test -p extension_host -- --skip
extension_store_test::test_extension_store_with_test_extension` (10
passed; the skipped fixture needs the `wasm32-wasip2` target, which is
not installed in the local Homebrew Rust toolchain)
- `cargo clippy -p extension_host --all-targets -- -D warnings`
- `cargo fmt --check`
- `cargo build -p zed`
End-to-end check with an isolated `--user-data-dir`, a trusted folder
worktree, LaTeX extension 0.2.3, and texlab 5.26.0:
- Zed 1.16.1 sent the global sentinel for both startup and a live
project-settings edit.
- This branch sent the project sentinel on startup.
- Changing the project sentinel from V2 to V3 produced a new
`workspace/didChangeConfiguration` with V3, and texlab's follow-up
`workspace/configuration` request also returned V3.
# 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 project-level language server settings being ignored by
extensions built with extension API versions before and including
v0.1.0.
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
This PR adds support for [Tangled](https://tangled.org/) as a Git
hosting provider.
Release Notes:
- Added support for permalinks to [Tangled](https://tangled.org/)
repositories.
`BenchReport`'s frame histograms only ever recorded a window's draw and
present timings, so a slow foreground task that never dirtied or drew a
window was invisible to `gpui::bench` consumers even though GPUI's
foreground journal already timed it. Delta hit this concretely: a
foreground task stalled for 76-130ms with no window draw in progress,
and the only way to see it in a benchmark was to manually queue a marker
task and time it by hand, outside the normal report.
GPUI already has the data needed to close this gap. The foreground
journal (`crate::profiler::journal`, merged separately in #62779) times
every foreground task poll, action handler, and input dispatch on the
main thread, independent of whether a window ever gets involved. This PR
wires that journal into `BenchAppContext`/`BenchReport` so the existing
benchmark harness reports it directly, instead of asking benchmark
authors to build their own timing side channel.
`TraceScope`, the type that already scopes frame-timing collection to a
measurement, now also owns a `ForegroundJournalCollector` created at the
same point it starts. Since a collector only observes journal entries
recorded after its own creation, per-iteration setup work (which runs
before the trace scope starts) is excluded from the measurement by
construction, the same way it already was for draw/present timings.
Drained task poll, action, and input events are recorded into a new
`foreground_work` duration histogram on `BenchReport` (draws and
presents are skipped there since the existing frame-timing histograms
already cover them), exposed through `BenchReport::foreground_work()` as
`count`/`total`/`max`/percentiles plus frame-budget overruns at the
report's configured FPS, and printed alongside the existing histograms.
Because this rides on the same per-task-poll instrumentation that
already powers GPUI's hang detection, it works for `bench_task`,
`bench_batched_task`, and `bench_renderer` without requiring a window at
all, and it aggregates every foreground event recorded during a
measurement (not just the first).
The `#[cfg(test)]`-only `install_test_foreground_journal` helper is
widened from `pub(super)` to `pub(crate)` so `bench_context`'s own tests
can install an isolated per-thread journal instead of sharing (and being
interfered by) whatever the shared production journal on that thread
happens to hold.
## Testing
- `cargo test -p gpui --features bench --lib bench_context` - two new
focused unit tests drive the foreground journal directly: one proves a
60ms synchronous task poll with no window is reported as foreground work
with no frame events recorded; the other proves an 80ms task poll before
the trace scope starts is excluded from the measured summary. A third
test exercises the real public API end to end, running
`BenchAppContext::bench_task` through an actual `criterion::Bencher`
(via `criterion::Criterion::bench_function`) and asserting the ~20ms
task shows up in `BenchReport::foreground_work()`.
- `cargo nextest run -p gpui --features bench --lib profiler` - the
existing foreground journal, hang detection, and frame-timing test
suites still pass unchanged.
- `cargo check -p benchmarks --benches` - the existing `#[gpui::bench]`
consumers (`bench_iter`, `bench_renderer`) still compile against the
updated `TraceScope`/`BenchReport` internals.
- `cargo fmt --package gpui -- --check` and `./script/clippy -p gpui
--features bench` are clean.
Release Notes:
- N/A
## Objective
There are [some formatting
issues](https://github.com/zed-industries/zed/issues/62955) with the
`ask_user` tool, but more importantly they seem to be confusing when
sub-agents are used, which are not always visible immediately. (Some
team members flat out also don't like being given options, which is the
purpose of the tool).
## Solution
disable the `ask_user` tool by default, allowing users who want it to
enable it in settings by setting `"ask_user": true,` as such:
```json
"agent": {
"profiles": {
"write": {
"name": "Write",
"enable_all_context_servers": true,
"tools": {
"copy_path": true,
"create_directory": true,
"create_thread": true,
"delete_path": true,
"diagnostics": true,
"apply_code_action": true,
"ask_user": true,
"edit_file": true,
"write_file": true,
"fetch": true,
"find_path": true,
"find_references": true,
"get_code_actions": true,
"go_to_definition": true,
"list_agents_and_models": true,
"list_directory": true,
"move_path": true,
"rename_symbol": true,
"read_file": true,
"grep": true,
"skill": true,
"spawn_agent": true,
"terminal": true,
"search_web": true,
},
},
},
},
```
## Testing
Ask an agent to ask you a question. By default, options should not be
shown, with the above configuration options should be shown.
## 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
Without tool:
<img width="1138" height="556" alt="CleanShot 2026-08-21 at 10 21 35@2x"
src="https://github.com/user-attachments/assets/6fd2cdbb-af84-49e9-acc5-db5a4359acbe"
/>
With tool:
<img width="1160" height="974" alt="CleanShot 2026-08-21 at 10 22 57@2x"
src="https://github.com/user-attachments/assets/7a4488e4-96f0-40d4-a4c4-70f489b70f12"
/>
---
Release Notes:
- Disable ask_user tool by default
Closes https://github.com/zed-industries/zed/issues/62435
Part of https://github.com/zed-industries/zed/issues/60548
Before:
https://github.com/user-attachments/assets/6b5147da-44cb-40c7-9da5-c50145e2ab4e
After:
https://github.com/user-attachments/assets/c58423cc-ea99-40d9-ad18-23b31dfb8e5d
Previously, `TerminalPanel::load` awaited full deserialization of
serialized
terminals (each awaiting directory environment capture via a login
shell)
before the panel was registered in the dock.
Until then, `terminal_panel::Toggle{Focus}` was a silent no-op: the
workspace finds no
panel in any dock, the keystroke is eaten, and nothing happens.
When it got eventually restored, it would close whatever panel in the
dock was open manually instead, wrecking the workflow.
Repro:
1. Add `case "$ZSH_EXECUTION_STRING" in *--printenv*) sleep 10;; esac`
to `~/.zshrc`.
2. Open a project, open at least one terminal in the panel, quit Zed
(Cmd+Q).
3. Relaunch via Dock/Spotlight (not the `zed` CLI, which skips env
capture via
`cli_environment`).
4. Press the terminal shortcut within 10s: nothing happens; after ~10s
the
panel appears and the shortcut works.
* `Register terminal panel before restoring serialized terminals` — the
panel
is now created and registered immediately, and restoration runs in
panel-owned tasks (cancelled on panel drop, nothing detached).
Terminal-adding paths were initially queued behind restoration (later
replaced by grafting, see below); the default shell spawns only if the
panel ends up active and empty after restore.
* `Stop replaying serialized dock state over manual panel changes` —
fixes a
related race: `Dock::add_panel` replayed the serialized dock state
(active
panel, visibility, zoom) on every panel insertion, so a late-loading
panel
would re-activate the serialized panel over one the user had switched to
in
the meantime (e.g. the terminal panel yanking the dock away from the
agent
panel), or re-open a dock the user had closed. Serialized state is now
applied at most once and is discarded as soon as the user changes the
dock
state manually. The new tests fail without this change and pass with it.
* `Show restoration progress in the terminal panel and allow spawning
terminals during it` — while terminals restore, the panel shows a
spinner
with "Restoring terminals…" instead of a blank pane, and logs the
restored
count and elapsed time. Supersedes the queuing from the first commit:
new
terminals spawn immediately, and any that land mid-restore are grafted
into
the restored layout instead of being lost. Serialization is paused
during
restoration, so quitting mid-restore can no longer persist a partial tab
list and silently drop terminals.
Release Notes:
- Fixed the terminal panel not opening at all under certain
circumstances, made panels no longer switching back to the serialized
one when opened during startup.
# Objective
- Make it easy to switch Git features between showing uncommitted
changes and all changes on the current branch.
## Solution
- Add `git::ToggleDiffBase`, which toggles the user setting between
`head` and `default_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:
- Git: Added an action to toggle the diff base between HEAD and the
default branch.
This PR adds some validation for the extension manifest.
Mostly,
- it tests that name and description are set and non-empty
- the authors-list is non-empty
- the repository URL is actually a parseable URL and reachable with a
200 code
Release Notes:
- N/A
Language model transport errors currently retain only a provider display
name after an HTTP request fails. Downstream clients therefore cannot
tell users which configured endpoint was unreachable without parsing the
source error or hard-coding provider names.
Make the request hostname a required part of
`LanguageModelCompletionError::HttpSend` and preserve it through the
Anthropic, OpenAI-compatible, OpenRouter, Vercel AI Gateway, and Zed
Cloud transports. Each transport captures the parsed hostname from the
request URI before sending it, using the configured base URL as the
defensive fallback. This supports production, development, and custom
endpoints without string matching.
Tests exercise transport failures through the real request paths and
verify hostnames for Anthropic, ChatGPT Subscription, generic
OpenAI-compatible providers, and Zed Cloud.
Testing:
- `cargo fmt --check`
- `cargo nextest run -p anthropic -p open_ai -p open_router -p
language_models_cloud -p language_models` — 209 tests passed
- `cargo check -p agent -p agent_ui --all-targets`
- `git diff --check`
- `./script/clippy -p language_model_core -p anthropic -p open_ai -p
open_router -p language_models_cloud -p language_models` — clippy
passed; the script subsequently failed in the repository-wide `cargo
shear --deny-warnings` step on 203 pre-existing target and doctest
configuration warnings
Release Notes:
- Improved language model connection errors to identify the unreachable
host.
# Objective
Ensure that the bindings displayed in the Git Panel's context menu do
not change between the first and subsequent frames.
## Solution
Git panel context menus could briefly display bindings from the generic
`GitPanel` context before switching to the more specific `ChangesList`
bindings. This was especially noticeable with Vim mode enabled, where
"Stage All" changed from `ctrl-cmd-y` to `shift-x`.
Since `GitPanel::dispatch_context` relies on
`FocusHandle::contains_focused` to be `true` in order to add the `menu`
and `ChangesList` contexts it could fail on the first frame the context
menu is shown, as the menu's focus handle is absent from the previous
frame's dispatch tree when first focused.
The simplest fix in this case is to fallback to
`GitPanel::context_menu::is_some()` in case
`GitPanel::focus_handle::contains_focused` returns `false`.
## Testing
Tested both manually as well as updated an existing test to ensure that,
when the context menu is first focused, both the `menu` and
`ChangesList` context are still present, even if no frame is rendered.
## 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)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
<details>
<summary>Before</summary>
Notice how the "Stage All" binding changes from `ctrl-cmd-y` (macOS) to
`shift-x` (vim).
https://github.com/user-attachments/assets/1d2e2de5-dce4-422c-8d63-4bcd93375431
</details>
<details>
<summary>After</summary>
https://github.com/user-attachments/assets/79e74c3f-8358-4e7c-8eb9-74fa36adde67
</details>
## Future Work
It's still possible for the bug to show up the first time the very first
time the context menu is actually opened, if the Git Panel was not
previously focused, that is, using `right-click` on the Git Panel while
the editor was focused, for example. I suspect this has to do with how
`Window::highest_precedence_binding_for_action_in` also relies on the
previous frame's dispatch tree, at which point the `GitPanel` was not
yet available in the context.
---
Release Notes:
- Fixed issue where the bindings shown in the Git Panel's context menu
would change after the first frame.
# Objective
Read-only marked files in zed could still be affected by format on save
feature. This PR fixes that.
FIXES#62899
## Solution
These changes add an early return on Editor's `Item::save`
implementation so neither formatting nor the write to disk occurs.
## Testing
I've tested by reproducing the issue in the original ticket.
## 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 read-only files being formatted and saved when `format_on_save`
is enabled
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
This PR updates the language extension docs for syntax-based rules,
line-based rules, and context-aware alignment. It is a follow-up to
#33370.
Release Notes:
- N/A
Closes#55345.
Wayland is the only platform whose frame ticks are conditional: a
wl_surface frame callback only arrives after a commit the compositor
goes on to repaint.
GPUI assumed unconditional ticks (any previously our Wayland backend
faked them), so an idle fullscreen window
stopped receiving callbacks and froze until external damage arrived.
This PR makes the Wayland render loop demand-driven, instead parking
when there's nothing to draw, and stops Zed committing empty frames on
every tick as the artificial heartbeat from the compositor.
---
Release Notes:
- Fixed the UI freezing in fullscreen on some Wayland compositors
- Fixed idle windows waking at the display's refresh rate on Wayland
---------
Co-authored-by: Philipp Schaffrath <philipp.schaffrath@gmail.com>
Co-authored-by: Daan De Meyer <daan@amutable.com>
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
- Notify the author when their PR has been in draft state with no new
commits for three weeks
- Close the draft PRs that didn't get updated after one more week
- Re-try the cla-bot check on PRs that are still unsigned after a week
- Close the PRs that are still unsigned after the re-try
## Testing
It works on my machine™
```
python script/github-pr-cleanup.py --dry-run
Checking 713 open pull requests
Dry-run mode: no comments or closures will be made
PR #60885: asking the CLA bot to check again
Would comment on PR #60885:
@cla-bot check
PR #61625: asking the CLA bot to check again
Would comment on PR #61625:
@cla-bot check
PR #57239: warning about a stale draft
Would comment on PR #57239:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #57241: warning about a stale draft
Would comment on PR #57241:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #61461: warning about a stale draft
Would comment on PR #61461:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #61722: warning about a stale draft
Would comment on PR #61722:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #61808: warning about a stale draft
Would comment on PR #61808:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
PR #61809: warning about a stale draft
Would comment on PR #61809:
<!-- zed-community-automation:stale-draft-warning -->
This pull request has remained in draft without new commits for three weeks.
If it remains a draft without new commits for another week, it will be closed
automatically.
Cleanup complete: 0 unsigned PR closures, 6 draft warnings, 0 draft closures
```
Release Notes:
- N/A
# Objective
- Prefer using `Duration` instead of integers when dealing with spans of
time. This prevents confusing different units of time and comparing
arbitrary integers with durations.
- Remove `_ms`/`_secs` suffixes from variables which are `Duration`,
since their unit is inside of the type.
- Initialize large integer constants using `Duration`, which has more
descriptive constructors, while maintaining the resulting integer type.
Release Notes:
- N/A or Added/Fixed/Improved ...
Anthropic now returns distinct error types for billing failures, request
conflicts, and gateway timeouts. Because the Anthropic client did not
recognize these values, they fell through to
`LanguageModelCompletionError::Other`, losing their structured status
and causing callers to apply generic handling.
Recognize the documented `billing_error`, `conflict_error`, and
`timeout_error` codes. Billing failures now become `PaymentRequired`,
conflicts preserve their HTTP 409 status and provider message, and
timeouts become typed upstream HTTP 504 failures. End-to-end tests
exercise each mapping through the HTTP response parsing path.
Testing:
- `cargo fmt --check`
- `cargo nextest run -p anthropic`
- `./script/clippy -p anthropic`
- `git diff --check`
Release Notes:
- Fixed handling of Anthropic billing, conflict, and timeout errors.
# Objective
Make it easy to conditionally enable the gpui inspector, with a goal of
eventually turning it on in nightly.
## Solution
The new `zed/inspector` flag (and supporting flags in other crates)
enables the relevant inspector features in `gpui`, `ui`, and
`inspector_ui` to be able to display the gpui inspector.
## Testing
- Enabling the inspector adds about 5mb to the binary, and for context
the zed binary is > 400mb at this time.
- Observationally, the inspector doesn't affect performance in a
meaningful way, but I did not run profiling.
```
# release with inspector (inspector on)
cargo run --release --features inspector
# release without inspector (inspector off)
cargo run --release
# dev build with debug assertions (inspector on)
cargo run
```
then trigger `dev::ToggleInspector`.
- linux: `ctrl-alt-i`
- windows: `shift-alt-i`
- macos: `cmd-alt-i`
## 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: Kirill Bulatov <mail4score@gmail.com>
This PR adds a 'clear' button to the search field in the Settings
window. The button becomes visible only when the field contains text.
Clicking the button clears the search field, which also resets the
navigation list.
Empty:
<img width="213" height="41" alt="image"
src="https://github.com/user-attachments/assets/03f97367-1036-453f-816a-5cbad219951c"
/>
With a search term:
<img width="213" height="38" alt="image"
src="https://github.com/user-attachments/assets/518047f4-c397-4a34-bb2f-147fcf37dc69"
/>
There are similar UIs, like the macOS and Windows System Settings
windows, and even Zed's 'Help' menu filter (on macOS), where the field
acts as a 'live filter', updating results on each keystroke, and the
'clear' action is more convenient than backspacing.
The first commit adds the button and the 'on click' functionality. If
the Zed team approves this change, I would also like to use the `escape`
key to clear the field. I have done some work on this, but there are
several issues and I would like some feedback before committing the
appropriate changes:
1. The `escape` binding to clear the field could arguably be built-in
(not user-configurable) since it's the standard key for this type of
action, and it may not make sense to allow other key combinations since
this field accepts keyboard input. Would the team approve a built-in key
binding, or must it be bound to a user-configurable `Action`?
2. For the Settings Window, `escape` is currently bound to the
`CloseWindow` Action by default. If the search field is focused,
pressing the `escape` key should clear the field, but not close the
window.
- If a new `Action` is used to clear the field (containing text), the
binding to that `Action` can have a more specific context
(`SettingsWindow > NavigationMenu && search`) than the `Action` on the
window (`SettingsWindow > NavigationMenu`), so the window won't close …
but if the field is *already empty*, should `escape` close the window
(and is there a way to re-enable the `CloseWindow` action in that case)?
- If a `KeyDownEvent` listener for `escape` is used to clear the field,
the `CloseWindow` Action still closes the window – is there a way to
cancel the `CloseWindow` Action in this case?
3. There is at least one other location with a similar 'live filter'
field, namely the Filter field in the Keymap Editor, where this same
functionality could be implemented. (I could update that too if this PR
is approved). Are there other similar instances in Zed? This 'clear
filter' UX should be consistent in all those locations.
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)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
(I could not find an existing issue or discussion about this feature.)
Release Notes:
- Added a 'clear' button to the search field in the Settings window,
which clears the field and resets the navigation list.
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
Makes `ztracing` spans work on the web, by mapping them to browser
`performance` APIs.
Since calling into JS from wasm has fairly high overhead, we instead
have a dedicated reporter task that threads send timing information to.
This approach significantly decreases the performance overhead of the
span-capturing thread (which is usually the performance sensitive one),
at the expense of:
- erasing thread information for spans in the browser devtools
- potentially dropping events if the bounded queue becomes full
The first issue can be mitigated by some slightly more sophisticated
capturing, along with a fixup script, which will come in a later PR
---
Release Notes:
- N/A or Added/Fixed/Improved ...
# Objective
Add configurable inline completion debounce timeout
Fixes/implements #23159
## Solution
I initially wanted to make a global setting for this, but it would
conflict with hardcoded debounces in codestral (150ms) and copilot
(75ms) which I assume are there for a reason.
So I ended up using the same mechanism used for the hardcoded debounce
in Codestral (`DEBOUNCE_TIMEOUT`) and Copilot
(`COPILOT_DEBOUNCE_TIMEOUT`)
and made it accessible and configurable for all providers.
Also fixed a bug with `DelayMs` `Display` trait adding "ms" into the
input field which then fails to parse something like "150ms" as a `u64`
by implementing `FromStr` which strips the "ms" suffix if present.
So now both "1000" and "1000ms" are parsed correctly and apply.
If the parsing fix is not relevant enough I can open a separate issue +
PR for that (and the inconsistent use and therefore display of
`Option<u64>` vs `Option<DelayMs>` in other ms input fields).
## Testing
#### Did you test these changes? If so, how?
Added a separate test which passes
`test_refresh_prediction_from_buffer_honors_debounce_duration`
Manually tested with openapi compatible prediction
All other tests in affected crates pass (`cargo test -p settings_content
-p settings_ui -p editor -p edit_prediction -p language
`)
#### How can other people (reviewers) test your changes? Is there
anything specific they need to know?
Open provider settings and adjust debounce, then see how long it takes
for a prediction to render.
#### If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
Tested on Fedora 43 KDE, but it shouldn't matter as none of the affected
code is platform specific.
## 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/14efa628-765e-4c2a-ac44-01aaa3657097
---
Release Notes:
- Added configurable inline completion debounce timeout, fixes#23159
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Closes https://github.com/zed-industries/zed/issues/62801
# Objective
Fix issue https://github.com/flathub/dev.zed.Zed/issues/395 (reported
against the flathub package, but as described in it, it was introduced
by https://github.com/zed-industries/zed/pull/57440 ).
The symptom was that when running `flatpak run dev.zed.Zed <project
path>` (or some alias), then you'd get two "files" opened `--zed` and
`zed-editor`, with `zed-editor` also being added to the Zed project list
in the open window, which was quite annoying.
## Solution
- The flatpak CLI launcher, which self-launches with potential extra
arguments, now puts those arguments first rather than last.
## Testing
- A simple unit test targets the helper function that adds the arguments
- It also verifies that the parsed args come out as expected
## 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
Note: I believe that other bullets than self-review and tests are not
relevant, as there is no unsafe, no expected performance impact, and no
UI changes.
---
Release Notes:
- Fixed an issue where Flatpak CLI launches would open
unrelated/nonexistent files due to a bug in argument construction
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
# Objective
Closes#52429Closes#56735Closes#62495Closes#62878
Reverts #13071
This PR fixes Zed windows sometimes remaining blank when first opened on
X11.
The issue remained very inconsistent across WMs and conditions to
reproduce and was finally consistently reproducable on my dwm build with
no compositor and on i3 with no compositor after removing the workaround
earlier added, which made it occur in i3 but not on my dwm build because
it was more aggressive with it's EWMH policy. It happened only on
opening a newer repo not opened the last time.
While running foreground work, a synchronous X11 request can read events
from the socket and place them in x11rb's internal event queue, calloop
monitors the underlying socket rather than this internal queue, so if
the socket is empty when the foreground work finishes, these events may
remain unprocessed until unrelated X11 activity occurs.
window is mapped -> events are buffered by x11rb
-> X11 socket is no longer readable
-> calloop does not wake
-> MapNotify is not processed
-> refresh loop does not start
-> window remains blank
This explains why the problem was inconsistent and differed between
window managers. Later focus, scrolling (on any window), exposure, or
other X11 activity could make the connection readable again and
incidentally process the older events.
My earlier PR #61162 fixed the related case where an already processed
`Expose` event could wait indefinitely for a stopped refresh loop. It
did not fix this initial-window case because the relevant events had not
reached Zed's event handler yet, which was again not perfectly
reproducable and lead me to assume was fixed.
## Solution
Process any X11 events buffered by x11rb after each foreground runnable
completes:
foreground work completes
-> buffered X11 events are processed
-> MapNotify starts the refresh loop
-> initial window contents are displayed
This also removes the unconditional
[`SetInputFocus`](https://tronche.com/gui/x/xlib/input/XSetInputFocus.html)
added in #13071. That call frequently masked the issue by generating
additional X11 activity, but also bypassed the window manager's focus
policy despite Zed already sending the standard `_NET_ACTIVE_WINDOW`
request.
With the event queue handled correctly, Zed no longer needs to force
focus to make the initial frame appear.
## Testing
Repeatedly opened fresh and existing workspaces under dwm while another
application retained focus with a new-project being opened everytime (at
least not the previous one).
Before this change, fresh windows could remain blank until later X11
activity occurred. After this change, they render immediately without
focusing, scrolling, resizing, or switching workspaces.
Also verified that window activation is left to the window manager
through `_NET_ACTIVE_WINDOW`.
## 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 remaining blank when first opened on X11
* Fixed Zed overriding window-manager focus policies when activating
windows
# Objective
Closes#52822
When hovering over the LSP status tooltip for a running language server,
the binary path is displayed. Currently, this tooltip shows
`LanguageServerBinary.path`. However, many language servers are executed
through runtimes such as Node or Python. For example, Zed-managed
`Basedpyright` produces a `LanguageServerBinary` like:
```Rust
LanguageServerBinary {
path: "/usr/bin/node",
arguments: [
"/home/xin/.local/share/zed/languages/basedpyright/node_modules/basedpyright/langserver.index.js",
"--stdio",
],
env: ...
}
```
In this case, only `"/usr/bin/node"` is displayed, which doesn't convey
useful information about the actual language server script being
executed.
## Solution
There was a PR #53076 in which I was involved, and the solution there
was to populate every language server adapter with a special marker for
the path to be shown in the tooltip. That solution is accurate, but in
order to make this solution work for extension-provided servers, the
final diff became huge for a simple fix.
So here, as commented in
https://github.com/zed-industries/zed/pull/53076#pullrequestreview-4204849892,
a guess is performed by a newly introduced function
`tooltip_for_server_binary()` to get the real path to be shown. It may
have some edge cases, but works for current cases and is simple to
implement.
## Testing
Added new unit tests, built and tested locally, with the comparision
attached in the Showcase section.
## 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
For the mentioned `Basedpyright` language server case, the comparision
is shown below:
| Before | After |
|:--:|:--:|
| <img width="431" height="187" alt="before"
src="https://github.com/user-attachments/assets/0611f2fe-687b-4d67-ba78-380d89ed0212"
/> | <img width="582" height="185" alt="after"
src="https://github.com/user-attachments/assets/6ad08720-ac53-4b2d-a72c-3febb441e2f1"
/> |
---
Release Notes:
- Improved the LSP status tooltip to display the target script path for
runtime-managed language servers
# Objective
When a worktree has no enclosing git repository, the `global-gitignore`
check falls back to matching the raw, unbounded absolute path. This lets
an ancestor directory outside the worktree, or the worktree's own root
name, incorrectly match a bare global-ignore pattern (e.g. a global
entry like `tmp` or `*.com`) and mark the entire worktree as ignored,
which silently breaks project search and greys out every file in the
project panel.
Fixes#62126Fixes#48887
## Solution
- In `Snapshot::ignore_stack_for_abs_path`, when no containing
repository is found, fall back to the worktree's own root as the
boundary for `IgnoreStack.repo_root`, instead of leaving it `None`.
- This reuses the existing repo-root-relative matching logic in
`IgnoreStack::is_abs_path_ignored` (already correct for the
git-repository case since #61689) without needing any changes to
`ignore.rs` itself: ancestors outside the worktree now correctly fail
the prefix check and are treated as not ignored, while the global
gitignore still applies to files and directories within the worktree.
## Testing
- Added `test_global_gitignore_without_repository` in
`crates/worktree/tests/integration/worktree_tests.rs`, covering both
variants in one worktree: an ancestor directory outside a non-git
worktree matching a global pattern, and the worktree's own root name
matching one, while also confirming a file that matches the pattern from
within the worktree is still ignored.
- Verified the new test fails without the fix (reproducing both #62126
and #48887) and passes with it.
- Ran the full `worktree` integration test suite (`cargo test -p
worktree --test integration`); all tests pass.
- Not tested on Windows or macOS, only Linux.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] Tests cover the changed behavior
---
Release Notes:
- Fixed global gitignore entries incorrectly matching directories
outside the opened project and marking the entire project as ignored
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Fixes https://github.com/zed-industries/zed/issues/62780
When formatting changed-only regions, we have received formatting
changes that are larger than the regions submitted.
Previous code merged only adjacent hunks in a single response, without
merging anything else, e.g. multiple responses' ranges that overlapped.
Release Notes:
- Fixed overlapping range format results duplicating the text
The inline assistant's streaming-tool path waited for the first
`rewrite_section` output, but treated any other completion event as
terminal. Responses API providers can emit `ReasoningDetails`,
`Thinking`, and other metadata before the tool call. This stopped the
stream early and marked generation as done without applying a
replacement.
EOF was not handled explicitly. Parse errors, provider errors,
incomplete tool calls, and truncated responses could also be reported as
successful completions.
Continue consuming informational events until a supported tool call
arrives. Track the rewrite tool call's streaming state, reject a second
`rewrite_section` call instead of concatenating unrelated outputs,
accept `failure_message` only after its input is complete, and reject a
`rewrite_section` arriving after a failure message (and vice versa).
Stop, EOF, malformed tool input, and stream errors now surface as
`CodegenStatus::Error` instead of silently completing. A completed tool
call followed by `Stop(MaxTokens)` or `Stop(Refusal)` is also an error:
the OpenAI Responses mapper flushes truncated tool calls as complete
before emitting the stop reason, so the stop reason must be checked even
when the tool input parsed. Completed failure messages are stored before
`Finished` is emitted, and a failure message left over from a previous
generation is now cleared when a new one starts.
Add regression coverage for metadata around streamed rewrites, Stop and
EOF without a tool call, incomplete rewrites, interrupted responses,
multiple rewrite calls, failure messages, malformed input, mixed tool
calls, and stream errors before and after rewrite output begins.
---
Closes#52714
Release Notes:
- Fixed the inline assistant doing nothing when the model emits
reasoning before its tool call.
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Saves the recent navigation history (up to 20 entries) to the workspace
DB so it survives restarts. When reopening a workspace, persisted paths
that resolve to the current project are merged into the file finder's
history, deduplicated against files already opened in the session.
https://github.com/user-attachments/assets/3d8934e1-0da6-4445-8f3d-acc5597d7ac8
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes: https://github.com/zed-industries/zed/issues/56271
Release Notes:
- Improved file finder history to include recently opened files from
previous sessions.
# Objective
When an user uses the Project Panel to rename a file, it is possible to
change its path too. For example, renaming `README.md` to
`documents/README.md` will create the `documents/` directory, in case it
doesn't yet exist.
Unfortunately, even though undoing a rename operation is already
supported, we were not yet considering this scenario where directories
had been created specifically to support the rename. As such, when undo
was used, for the scenario above, we'd end up moving `README.md` back to
its original location but would leave the empty `documents/` directory
behind.
## Solution
Introduce two new operations and changes specifically for this use-case,
`Operation::CreateDir`, `Operation::RemoveDir`, `Change::DirCreated` and
`Change::DirRemoved`, which we can then batch together with the
`Operation::Rename` in case directories need to be created or removed.
An initial approach of just keeping the list of created directories in
the `Operation::Rename` and `Change::Renamed` variants was considered
but it would require all users of `Operation::Rename` to now set it,
even if they don't actually need it, like the drag and paste operations.
Having separate operations and change variants also makes it clearer
what these are meant to be used for.
Something else worth noting is that, for `Operation::CreateDir`, the
directory will only be created if it doesn't yet exist, otherwise we'll
ignore. Same happens for `Operation::RemoveDir`, where if the directory
is not empty, we don't delete it, as it's possible for new files to have
been added to the directory outside of Zed and we don't want to delete
those.
## Testing
Tested both manually as well as introduced a new test case
– `project_panel::tests::undo::rename_with_dir_undo_redo` .
## 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)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
> This section is optional. If this PR does not include a visual change
or does not add a new user-facing feature, you can delete this section.
- Help others understand the result of this PR by showcasing your
awesome work!
- If this PR includes a visual change, consider adding a screenshot,
GIF, or video
- A before/after comparison is very useful for changes to existing
features!
While a showcase should aim to be brief and digestible, you can use a
toggleable section to save space on longer showcases:
<details>
<summary>Before</summary>
https://github.com/user-attachments/assets/15384fa8-9b94-495c-8992-19eee7a8f038
</details>
<details>
<summary>After</summary>
https://github.com/user-attachments/assets/c5be9f38-a2b4-4acc-8a1e-178161e326bb
</details>
---
Release Notes:
- Fixed undoing a file rename leaving behind directories created by the
rename.
# Objective
On case-insensitive volumes (the macOS default), language servers may
return `Location` URIs whose path casing differs from the worktree's
stored casing - e.g. `Utils/helpers.py` when the on-disk (and worktree)
path is `utils/helpers.py`. `LspStore::open_local_buffer_via_lsp` used
the LSP path verbatim, and worktree selection
(`WorktreeStore::find_worktree`) does a case-sensitive prefix match, so
the existing worktree was either missed (creating a duplicate invisible
worktree) or matched but with a relative path that retained the LSP's
intermediate-component casing. That relative path was then used to
`load_file`, which inserted a brand-new `Entry` keyed by the
differently-cased path alongside the existing one - producing duplicate
file entries in the project panel. This was most visible when navigating
Python imports (Go to Definition) where the LSP returned
differently-cased paths.
https://github.com/user-attachments/assets/e36930b5-8dfd-4b43-8fe4-5317d401e198
## Solution
Canonicalize the LSP-provided absolute path via `fs.canonicalize` before
the worktree lookup in `LspStore::open_local_buffer_via_lsp`, so the
path casing matches the filesystem and the existing worktree/entry is
reused. Canonicalization failures (e.g. a path that doesn't exist on
disk yet) fall back to the original path to preserve prior behavior.
To enable testing this on a fake filesystem, `FakeFs` now supports
`set_case_sensitive(false)` and its `canonicalize` resolves names
case-insensitively, returning the stored (canonical) casing.
## Testing
Added `test_open_buffer_via_lsp_case_variant_no_duplicate` in
`crates/project/tests/integration/lsp_store.rs`. It opens a buffer via
an LSP URI with differently-cased intermediate component
(`/root/SRC/main.rs` vs `/root/src/main.rs`) on a case-insensitive
FakeFs and asserts that no differently-cased entry is created and the
canonical entry is preserved. Verified the test fails without the fix
(`SRC/main.rs` duplicate appears) and passes with it. Existing worktree,
fs, and project_panel test suites remain green.
## 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/f052cf10-8b45-4547-8425-00ce4050ee7c
---
Release Notes:
- Fixed duplicate file entries in the project panel on macOS when
navigating to definitions via the language server returned paths with
different casing than the worktree root.
---------
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
# Objective
use pickers for all kinds of lsp definitions
## Solution
add handlers for `GoToDeclaration` and `GoToTypeDefinition` in
`lsp_locations.rs`
## Testing
- Did you test these changes? If so, how?
- Are there any parts that need more testing?
- How can other people (reviewers) test your changes? Is there anything
specific they need to know?
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
## 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
this rust code can be used to test for multiple type definitions on `a`
```rs
macro_rules! foo {
($e:ident) => {
let $e: Vec<()>;
let $e: String;
};
}
fn main() {
foo!(a);
}
```
<img width="735" height="288" alt="image"
src="https://github.com/user-attachments/assets/578e6dc2-b201-4194-bd8b-e8d17b4d3d50"
/>
---
Release Notes:
- Respect `"lsp_results_location": "picker"` for go to declaration and
type definition
Bundled GLib shadowed the system libraries for host plugins dlopen'd
into the process, like PipeWire's videoconvert on 1.6+, which would
break Wayland screen sharing on newer distros. This PR makes Zed rely on
system GLib instead, since the bundled version pulls from whatever is in
CI (presently Ubuntu 20.04).
Release Notes:
- Removed GLib libraries from Linux release bundle, which could conflict
with system plugins
# Objective
On X11, GPUI raises the ICCCM `WM_HINTS` urgency flag to ask for
attention, but
it never clears it. The window stays urgent for the rest of its life.
`request_attention` was the only thing touching the bit. There was no
code
anywhere to clear it.
Docks and taskbars latch on the rising edge, so they show the attention
state
once and then sit there with a permanent urgent indicator, no further
notifications.
## Solution
Clear the flag when the window becomes active.
The read/modify/write moves out of `request_attention` into a helper,
`set_wm_hints_urgency(xcb, x_window, urgent)`. The raise and clear sites
are on
different self types (`X11Window` vs `X11WindowStatePtr`), so it takes
the
connection and window id.
The clear goes in `set_wm_properties`, where `state.active` gets set
from
`_NET_WM_STATE_FOCUSED`. That's the same field `request_attention`
already checks
in its `if self.is_active() { return; }` guard.
Two implementation notes:
* The clear is edge triggered (`state.active && !was_active`).
`set_wm_properties` recomputes everything on every `_NET_WM_STATE`
change, so a
level triggered check would do a blocking `WmHints::get` round trip on
every
maximize, fullscreen, hide and workspace switch while focused. Edge
triggering
is safe here because `request_attention` early returns when active, so
urgency
only ever gets raised while inactive, and the false to true transition
always
follows a raise.
* Clearing reads the hints first and skips the write if the bit isn't
set.
Otherwise focusing a window that never asked for attention would create
a
`WM_HINTS` property just to say "not urgent".
The raise path behaves exactly as before. The skip can't fire when
`urgent` is
true, so repeat raises still write every time.
Focusing clears the flag even if a second thread is still waiting.
That's already
how it works, since `request_attention` early returns when the window is
active.
## Testing
Tested on X11, Cinnamon with Muffin.
On an unpatched build the window had `_NET_WM_STATE_FOCUSED` and the
urgency bit
set at the same time.
W=$(xdotool search --class "dev.zed.Zed" | head -1)
xprop -id $W WM_HINTS
xprop -spy -id $W WM_HINTS
1. Fresh window says `WM_HINTS: not found`, and still does after
focusing it.
2. With focus on another window, the urgency bit shows up when attention
is
requested. `request_attention` early returns when active, so the window
has to
be unfocused for this to fire.
3. Focusing Zed clears the bit.
4. Repeating 2 and 3 re-arms it every cycle, not just once.
5. No `WM_HINTS` writes during normal use (resize, maximize, workspace
switch).
No automated test. It's an X11 round trip on a real window and there's
no X11
test harness in the tree.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments (none added)
- [x] The content adheres to Zed's UI standards (no UI change)
- [x] Tests cover the new/changed behavior (see Testing)
- [x] Performance impact has been considered and is acceptable
Note this was manually tested, there wasn't a good way to test it
through the current harness.
---
Release Notes:
- Fixed the X11 urgency hint never being cleared, which left Zed showing
a permanent attention indicator in taskbars and docks after the first
notification
# Objective
Closing a project while a large local text file is loading can be
delayed
because file-reading and UTF-8 streaming loops have no await points.
Partially addresses #27283.
## Solution
Yield between 1 MiB blocks while:
- streaming UTF-8 files into a Rope
- reading files handled by the fallback decoder, including BOM, UTF-16,
and other non-UTF-8 encodings
Release Notes:
- Improved responsiveness when closing projects that are loading large
text files.
