# Objective
Fixes#60192
Closes https://github.com/zed-industries/zed/issues/62308
`editor: align selection` lines cursors up by their buffer column, and
that column counts bytes. If a multi-byte character sits before the
cursor, the byte column is larger than the position the cursor is
actually drawn at, so the row gets padded with the wrong number of
spaces.
The issue reports it with `←` (3 bytes) and `π` (2 bytes):
```
a ← 1 # one
bc ← π # two
```
Put a cursor on each `#`, run the action, and the result is still
misaligned:
```
a ← 1 # one
bc ← π # two
```
This is not the columnar selection bug fixed in #57097. That one was
`select_columns` in `selection.rs`, where the output is a selection
range. This one is `align_selections` in `editor.rs`, where the output
is inserted spaces, so the same byte-column assumption was left behind
in a second place, and fixing it here needs a rounding step that the
first fix did not.
## Solution
Measure each cursor by its x offset in the laid-out display row
(`DisplaySnapshot::x_for_display_point`), take the target for a column
as the furthest x across the rows, then turn the difference into whole
spaces by dividing by the advance width of `' '`. The offset that
carries into later columns becomes an x offset instead of a column
count.
The display map has already expanded tabs by the time the row is laid
out, so a leading tab now counts as its expanded width instead of as a
single byte.
Two things I would look at first in review:
- The division rounds instead of truncating. The x offsets are built by
repeated float addition, so a gap that should be exactly three spaces
can arrive as 2.9999998, and truncating inserts two.
- The function returns early if the space advance is missing or zero.
Dividing by zero gives `inf`, which saturates to a huge `u32` and then
tries to allocate that many spaces.
I did not add any public items and did not touch `selection.rs`.
## Testing
`cargo test -p editor align` on Windows: 6 passed, 0 failed. That is the
new test plus the two existing `align_selections` tests, which I did not
change and which still pass.
`test_align_selections_with_multibyte_chars` covers the repro from the
issue, a second column whose offset has to carry past a multi-byte
character in the first, a leading tab, a non-BMP character, and a case
where multi-byte characters sit after the cursors and nothing should
move.
I also checked that the test catches the bug rather than just passing:
reverting the change in `editor.rs` and keeping the test makes it fail
on the repro, inserting four spaces where three are right. Putting the
change back makes it pass. The two older align tests pass either way,
since they are pure ASCII.
What I have not covered:
- Wide CJK characters, combining marks, and ZWJ clusters. These should
be right by construction, since the code measures advances rather than
counting characters, but I have no tests for them. The headless text
system behind `gpui::test` gives every BMP character the same advance,
so a test there would assert the test double's behavior rather than the
real renderer's.
- Proportional fonts. Aligning with inserted spaces cannot be exact when
glyph widths vary. The code rounds to the nearest whole space.
- Soft-wrapped rows. I measure x from the start of the wrapped row but
still group cursors by buffer row, so two cursors on one buffer row that
sit either side of a wrap boundary get measured from different origins,
and the carried offset crosses that boundary as if they shared one. The
old byte-column code did not have that particular failure. I left it
alone because fixing it is a different change, but I would rather flag
it than have you find it.
- I work on Windows and have no macOS machine. The arithmetic is
platform independent, so I do not expect a difference, but I have not
checked.
To try it: paste the two lines from the issue, put a cursor on each `#`
with `editor: select next`, then run `editor: align selection`. The two
`#` should line up.
## Self-Review Checklist:
- [ ] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed `editor: align selections` misaligning rows and Vim `ctrl-d` /
`ctrl-u` / `ctrl-f` leaving the cursor behind on lines with multi-byte
characters or tabs.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
# Objective
- There was no way to copy a cell's or a column header's text out of the
CSV preview table (at all).
## Solution
- Right-clicking a table cell now copies its full content to the
clipboard; the cell tooltip shows the content plus a "Right click to
copy content" hint.
- Right-clicking a column header name copies the column name to the
clipboard, with the same tooltip pattern ("Right click to copy column
name").
## Testing
- Right-click a cell: content is copied, tooltip shows the hint.
- Right-click a column header: column name is copied, tooltip shows the
hint.
## Demo
<img width="994" height="241" alt="image"
src="https://github.com/user-attachments/assets/827a0356-e152-4bfd-84ea-5745e638f13c"
/>
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Added copy-to-clipboard on right-click for CSV preview cells and
column headers
Dropped entities are released only inside an update's effect flush, and
releases cascade: one flush drops the entities whose handles are gone,
their drops release further handles and can queue foreground work, and a
later flush collects those. `BenchAppContext` callers that only pump the
executor between iterations therefore saw torn-down state linger in the
entity map until some woken task happened to run an update — in a
downstream benchmark this looked like a per-iteration leak of the whole
app graph (~35 MB per iteration), releasing on an apparently timer-bound
schedule.
This adds `BenchAppContext::settle`, which alternates draining queued
work with GPUI update cycles until the dispatcher reports idle,
mirroring the update cadence production gets for free from frames and
input events. `bench_batched_task` now settles before each iteration's
setup (outside the timed interval), so the previous iteration's state is
fully released and cannot accumulate across a measurement. A new
`ThreadedDispatcher::is_idle` predicate backs the loop's termination and
is covered by a unit test.
Release Notes:
- N/A
# Objective
A column's filter popover grays out values that would leave zero rows
given other active filters.
That check only looked at columns filtered _before_ the one being
viewed, so reopening a filter on a column filtered earlier than another
still-active one showed a value as available with count `0` —
selectable, but guaranteed to empty the table.
Separately, values already checked when they became blocked lost their
checkmark and couldn't be unchecked from the popover (matches IntelliJ's
reference behavior of always keeping values checkable with an honest
count, never fully disabled).
## Solution
- Availability now reuses the same `rows_passing_other_filters` set
already used for counts (every other active column's filter, own filter
excluded) instead of the old order-dependent cascade over
`activation_order`. Removed `activation_order` entirely — now dead code.
- `Unavailable` carries `is_applied`, same as `Available`.
Hidden-and-applied rows stay checked and toggleable (to uncheck); only
hidden-and-unapplied rows stay disabled.
- Filter popover footer no longer disappears when a filter's count drops
to `0` (`has_active_filters` instead of `selected_rows == 0`).
## Testing
Fixture:
```csv
A,C
1,red
2,red
1,blue
1,blue
```
Rendered as:
<img width="381" height="165" alt="image"
src="https://github.com/user-attachments/assets/fc12d1d3-26e6-4f8e-97f0-5522f67e70ea"
/>
Manual:
apply filters:
- C=red,blue
- A=2
reopening C's popover shows the blocked `blue` value grayed with count
`0`, stays checked and uncheckable.
## Demo
| Before (counds not updated) | After (counts reflect reality) |
| --- | --- |
| <img width="631" height="190" alt="image"
src="https://github.com/user-attachments/assets/df433449-826d-4f7e-8c35-d3779911b7fa"
/> | <img width="615" height="217" alt="image"
src="https://github.com/user-attachments/assets/ce067fb9-3fd5-4d2a-9689-8defc587f617"
/> |
Release Notes:
- Fixed CSV preview column filters showing incorrect availability/counts
depending on which filter was applied first
Fixes https://github.com/zed-industries/zed/issues/35780
Collab schema migration PR:
https://github.com/zed-industries/cloud/pull/3422
The corresponding database schema migration has been created in the
Cloud repo and applied to the production database.
Before, Zed scanned each and every entry in the tree down from the
directory it was opened in, except gitignored files and scan exclusions.
The approach is unchanged, if Zed detects it was open inside a git
repository: e.g. the directory open in Zed contains `.git` directory.
For the rest of the projects, 2 optimizations are made:
* Limit the depth of file scan traversal.
Now, `file_scan_depth` (default `5`) restricts Zed from traversing any
directory that has same number or more segments in its file path.
Such directories behave similar to gitignored directories: their
contents is not available in file finder, project search and project
panel, but can be lazily traversed when the directory is expanded (e.g.
project panel expands it or a nested file is open by path via terminal,
etc.)
To indicate that to the users, a status entry is shown firs time the
limitation is hit in the project:
<img width="858" height="133" alt="image"
src="https://github.com/user-attachments/assets/7da6cfbb-98b4-4cc3-bf2a-8902a9597a15"
/>
* During the scan, any git repositories that are not direct children of
the directory open in Zed (depth >= 2), are traversed and indexed
normally, but their git metadata is never fetched eagerly.
Only when Zed opens a buffer from that repo the git metadata is fetched
and applied.
All that combined now uses a way more moderate amount of CPU and RAM
when opening `~`:
<img width="1717" height="368" alt="Screenshot 2026-08-13 at 17 43 53"
src="https://github.com/user-attachments/assets/ec83e2a9-f7cc-452b-8eb7-af158284ca4e"
/>
File scan inclusions and exclusions are considered still for such
projects.
Set `file_scan_depth` to `0` to enable old behavior.
The setting is supported in the project settings, so custom values can
be set based on the project's structure.
---
Release Notes:
- Fixed Zed using a lot of memory and CPU in large, non-git-tracked,
directory trees
- Closes#31866
Currently, `Terminal::alacritty::make_content()` always carries over any
existing hovered word. With this PR we now:
- *Are more selective*: Only carry forward the hovered word if the
terminal grid shape and visible lines have not changed
- *Correctly handle a shifting viewport*: If the grid shape and visible
lines have not changed, but new lines were added to the terminal we
carry the hovered word forward, and adjust the lines of the `word_match`
so that the original text remains hyperlinked.
Also, this PR relaxes the test for displaying a hyperlink in
`TerminalElement::prepaint`. We now display hyperlinks as long as the
`hovered_word.id`s from terminal and terminal_view match. Previously we
required all fields to be equal, which resulted in the hyperlink
flickering when scrolled back with new lines being added.
Release Notes:
- Terminal: Made hyperlinks display correctly with changing content
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
# Objective
Make `G` keybinding in Helix mode work like in Helix and not like in
Vim.
Fixes https://github.com/zed-industries/zed/issues/61580
## Solution
Helix has two ways to jump to a line by line number.
One is the `goto_file_start` command (bound to `gg`) that optionally
takes a count to go to that line instead of the start of the file. Zed
already supports it as `vim::StartOfDocument`.
The other is the dedicated `goto_line` command (bound to `G`) that only
does that and nothing else. Zed did not have it.
What's worse, the default `"shift-g": "vim::EndOfDocument"` binding
leaked from Vim keymap into Helix keymap, which previously made
`<count>G` accidentally work in Helix mode for the wrong reason, until
https://github.com/zed-industries/zed/pull/59449 fixed the behavior of
`vim::StartOfDocument` and `vim::EndOfDocument` actions to match Helix
exactly. This broke `<count>G` and exposed that `G` was bound to the
wrong action in Helix mode, and the correct one didn't exist.
This PR fixes that in the following way:
- adds new`vim::HelixGotoLine` action
- binds it to `shift-g` in `helix_normal` and `helix_select` modes in
the default Vim keymap
## Testing
- Unit tests
- Manual testing
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed the behavior of `G` binding in Helix mode and added new
`vim::HelixGotoLine` action
Signed-off-by: Oleksii Orlenko <alex@aqrln.net>
## Objective
Improve cache hit rate of LLM requests sent to ChatGPT subscription API.
## Solution
Set headers that help route request to the correct servers. This is
ChatGPT specific; plain OpenAI API doesn't require it.
## Testing
I run a benchmark which imitates a thread that makes 20 sequential tool
calls. I tried different cache route strategies. Results are below:
| Configuration | Hit rate |
|-------------------------------------------------|---------:|
| No identity headers, no cache key | 22.2% |
| `thread-id` only, no cache key | 44.4% |
| `thread-id` + matching cache key | 42.1% |
| Cache key only | 53.6% |
| Turn state + cache key | 47.4% |
| `session-id` + matching cache key | 100.0% |
| `session-id` + `thread-id` + matching cache key | 97.4% |
---
Release Notes:
- Improved ChatGPT subscription caching
ChatGPT Subscription compaction currently uses the legacy `POST
/responses/compact` endpoint. The Codex backend now returns `404 Not
Found` from that route, which causes manual and threshold-triggered
compaction to fail even though ordinary model requests continue to work.
Use the current Codex compaction contracts over the normal streamed
`POST /responses` endpoint instead. Automatic compaction now advertises
server-side support and sends `context_management`, while manual
compaction appends the transient `compaction_trigger` input item used by
Codex's remote compaction v2 flow. Both paths consume the standard
encrypted `compaction` output item, preserving backend-owned state for
subsequent requests.
The manual action remains available through
`supports_explicit_compaction`; only its transport changes. The shared
Responses input type gains the `compaction_trigger` wire item and an
append operation for provider-specific request construction.
Testing performed:
- `cargo nextest run -p open_ai -p openai_subscribed --lib`
- `./script/clippy -p open_ai -p openai_subscribed`
- `cargo fmt -p open_ai -p openai_subscribed -- --check`
- Verified with ChatGPT OAuth against `gpt-5.6-sol`, `gpt-5.6-terra`,
`gpt-5.6-luna`, `gpt-5.5`, `gpt-5.4`, and `gpt-5.4-mini`:
`compaction_trigger` returned HTTP 200 with a streamed `compaction` item
for every model; forced `context_management` compaction also returned
HTTP 200 for every model. The legacy `/responses/compact` route returned
HTTP 404 for every model.
Release Notes:
- Fixed ChatGPT Subscription context compaction failing with an API
endpoint error.
ChatGPT subscription compaction failures currently flow through the
generic HTTP status conversion before callers can inspect the provider
response. A 404 therefore becomes `ApiEndpointNotFound`, which drops the
response body and leaves logs with only the inferred endpoint-not-found
message.
Log the original `RequestError` at the subscription compaction call site
before returning it unchanged. The log identifies the compact endpoint
and preserves the HTTP status and response body for diagnosis, without
logging credentials, request contents, or response headers. Error
classification, retry behavior, and user-facing presentation remain
unchanged.
Testing:
- `cargo fmt --all --check`
- `cargo nextest run -p openai_subscribed --lib`
Release Notes:
- N/A
---------
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
## Context
Add support for binary SVG data in the `Svg` component in the `gpui`
crate. The component now accepts raw SVG bytes via a new `.data()`
method, in addition to the existing `.path()` and `.external_path()`
methods.
**Example usage:**
```rust
svg().data(svg_bytes).color(colors::WHITE)
```
This solves the problem of unnecessary asset bundling and enables Rust's
dead code elimination to optimize binary size.
**Related issue:** Closes#52315
## How to Review
- Review `crates/gpui/src/elements/svg.rs` - the changes are localized
to this file
- Focus on: API design, caching strategy (hash-based virtual path),
priority ordering in paint()
- Verify the implementation properly integrates with existing
`SvgRenderer` and `Window::paint_svg`
## Self-Review Checklist
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (none in this change)
- [x] The content is consistent with the UI/UX checklist (trivial UI
change)
- [x] Tests cover the new/changed behavior (manual testing may be needed
for SVG rendering)
- [x] Performance impact has been considered (hash calculation is
minimal; caching prevents redundant work)
## Technical Details
The implementation:
- Adds `data: Option<Arc<[u8]>>` and `data_path: Option<SharedString>`
fields to `Svg`
- Adds `pub fn data(mut self, data: &[u8]>) -> Self` builder method
- Generates deterministic virtual path from SHA256-like hash:
`__binary_svg__{hash}`
- `paint()` checks sources in priority order: binary data >
external_path > path
- Uses existing `Window::paint_svg(..., data: Some(&bytes))` path
This is a minimal, non-breaking change that leverages existing
infrastructure.
Release Notes:
- Added `.data()` method to `Svg` element to accept raw SVG bytes
Co-authored-by: Lukas Wirth <lukas@zed.dev>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
# Objective
Tiny annoyance, the standalone `gpui_util::log_err` was never annotated
with `#[track_caller]` so whenever it was called, the source location
would be `gpui_util::lib` instead of the appropriate location.
I checked and this is actually used in Zed in exactly one place:
`crates/extension_host/src/extension_host.rs:1095`. So *technically*
this can be considered a bug.
I use it quite frequently in my code, so this is more of a self-serving
pr.
## Solution
I added `#[track_caller]` to `gpui_util::log_err`.
## Testing
I ran the tests just in case and they all passed.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Added track_caller to gpui_util::log_err
# Objective
Fixes#62529.
Prevent Python toolchain discovery from executing Apple's
`/usr/bin/python3` Command Line Tools shim when no active developer
Python exists. Executing that unresolved shim causes macOS to repeatedly
prompt users to install the Command Line Tools, even when Python is
managed through Nix, uv, or pyenv.
## Solution
Update Python Environment Tools (PET) to `bb8e046`, which includes
microsoft/python-environment-tools#506. That upstream change resolves
active Xcode and Command Line Tools Python executables from filesystem
state and skips unresolved macOS system Python shims before generic
process probing.
Adapt Zed to the updated PET API by:
- displaying the newly supported Hatch environment kind
- passing no refresh identifier when running in-process environment
discovery
## Testing
- `cargo check -p languages --locked`
- PET unit tests covering unresolved macOS system Python shims
- The Zed compilation check was run on Linux; the original dialog
reproduction was not manually tested on macOS.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed Python toolchain discovery prompting installation of Apple
Command Line Tools when using a separately managed Python installation.
# Objective
Zed normalizes all buffer text to `LF` internally, but was sending that
`LF`-normalized text to language servers even for `CRLF` files. This
caused servers such as ESLint (with a `linebreak-style` rule) to report
a false error on every line.
Fixes#38453
## Solution
Send the buffer's actual line endings to the language server instead:
- `didOpen` and full-document `didChange` now send
`text_with_line_endings()`, and incremental changes apply the buffer's
line ending to each edit.
- Normalize the line endings returning from the LSP before computing
changed regions
- This effectively incorporates the fix from #59151, which happens to be
the reason this change was [originally
reverted](https://github.com/zed-industries/zed/commit/1b6cde7032fea1ff38f885419ab4e79c4f8c3231).
As such, that PR should likely be integrated first.
- Detect when a buffer's line ending differs from what a server was last
sent and force a full-document resync, without this the server would
keep stale line endings, as the incremental change tracking does not
consider line ending differences.
- Route the `UpdateLineEnding` operation to `on_buffer_edited` so
toggling line endings via the status bar notifies the server immediately
rather than waiting for the file to be edited or reopened.
## Testing
- Did you test these changes? If so, how?
Yes, in addition to new unit test coverage, I used a test project with
ESLint configured with the `linebreak-style` rule set to enforce CRLF
line endings to verify that the LSP integration worked as expected.
- Are there any parts that need more testing?
The original reversion seems to have been due to a regression in which
LSP formatting would cause the editor to scroll to the bottom. I'm not
seeing this in my reproduction, and I believe this was due to a failure
to normalize line endings coming back from the LSP, but I don't know the
exact circumstances that led to the original reversion, so there might
be some additional things to test there.
- How can other people (reviewers) test your changes? Is there anything
specific they need to know?
Not really! As mentioned above, configuring ESLint with the
`linebreak-style` rule is probably the easiest way to test.
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
I tested on Linux, but I don't believe it's relevant.
## 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/881c5758-a5de-433c-8fd6-3cad7478aa90
---
Release Notes:
- Fixed an issue where language servers received incorrect line endings
for `CRLF` files, causing linters and formatters to report false errors.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
## Why
`textDocument/onTypeFormatting` edits that insert or replace text at an
empty cursor use its right bias and move it past the new text. In paired
tags, pressing Enter can therefore leave the cursor on the closing tag
instead of between the tags.
## What
- Capture a left-biased pin for each empty cursor before requesting
on-type formatting.
- Skip cursor tracking unless a matching language server advertises the
trigger.
- Restore only unchanged empty cursors whose displacement is fully
covered by formatting transaction ranges, so intervening user edits are
preserved.
- Reset vertical movement state when restoring a cursor.
## Testing
- `cargo test -p editor test_on_type_formatting` (5 passed)
- `./script/clippy -p editor`
## References
- Fixes https://github.com/zed-industries/zed/issues/61574
Release Notes:
- Fixed the cursor being moved past text inserted or replaced at its
position during on-type formatting.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
# Objective
Closes#61646.
For code completions, Zed currently fuzzy-matches against
`CodeLabel::filter_text()`:
https://github.com/zed-industries/zed/blob/d4010e91ccc9635853698af160f15bb479a484d0/crates/editor/src/code_context_menus.rs#L337-L343
`CodeLabel::filter_text()` is a substring of `CodeLabel.text`, which is
essentially the text itself. `CodeLabel.text` is constructed by Zed's
per-language adapters from the `label` and `detail` fields of the
completion items returned by the language server — the exact
construction differs from adapter to adapter, but the source data is the
same. In effect, `CodeLabel.text` ≈ `label` + `detail`. Zed therefore
filters on the server-returned `label` and `detail`, while the
server-returned `filterText` field is silently ignored.Per the LSP spec:
```
/**
* A string that should be used when filtering a set of
* completion items. When omitted, the label is used as the
* filter text for this item.
*/
filterText?: string;
```
we should use `filterText` when it is provided.
Normally, language servers populate `filterText` as a substring of
`label`, so the current behavior works fine. But for certain language
servers or functions, `filterText` can be entirely unrelated to `label`
and `detail`. For example, for `std::path::Path::parent()` in Rust,
rust-analyzer returns:
```json
{
"label": "parent()",
"labelDetails": {
"detail": "(alias dirname)",
"description": "fn(&self) -> Option<&Path>"
},
"kind": 2,
"preselect": true,
"sortText": "7ffffff6",
"filterText": "parentdirname",
...
}
```
Typing `dirname` therefore never surfaces this completion.
The root design issue behind this bug is that `CodeLabel` is not
well-suited to filtering LSP completions.
## Solution
`CodeLabel` and its related methods are kept untouched: the struct is
reused across the repo and is only unsuitable for filtering LSP
completions. Instead, the changes are made in `CompletionSource` and
`Completion`, each gaining a `filter_text()` method:
- `CompletionSource::filter_text()` handles LSP completions, returning
the server-provided `filterText` and falling back to the `label` when
`filterText` is absent.
- `Completion::filter_text()` is the general entry point used for fuzzy
matching; for non-LSP completions it falls back to the existing
`label.filter_text()`.
The fuzzy match target is switched from `CodeLabel::filter_text()` to
`Completion::filter_text()` — that is the core change.
Since the fuzzy match target is no longer guaranteed to be a substring
of the displayed `CodeLabel.text`, the matched characters no longer have
a direct position in the displayed text to highlight. Bold highlights
are therefore only rendered when `CodeLabel::filter_text()` equals
`Completion::filter_text()`. This is a safe choice, though not an ideal
one.
## Testing
Added a new GPUI test covering the new behavior; also built and tested
with a before/after comparison, 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
| Before | After |
|:--:|:--:|
| <img width="708" height="308" alt="Before"
src="https://github.com/user-attachments/assets/ca2e3820-7ea1-4dcc-a91f-28aab71aecc5"
/> | <img width="696" height="248" alt="After"
src="https://github.com/user-attachments/assets/334e240b-64d5-495b-aef6-772456b993ba"
/> |
---
Release Notes:
- Improved completion filtering for lsp completions.
# Objective
`WorktreeStore::find_or_create_worktree` inserts the shared
worktree-creation task into `loading_worktrees` and relies on the task
it returns to each caller to remove that entry once creation resolves.
But the creation task keeps running through the clone the map itself
holds, while the map cleanup lives only in the callers' returned tasks.
If every caller is cancelled before creation resolves, the resolved task
stays in `loading_worktrees` forever, retaining the `Entity<Worktree>`
captured in its result (a `Shared` task memoizes its output). Such a
worktree can never be released: `remove_worktree` only unlists it, so
its background scan keeps running and its snapshot keeps growing for the
lifetime of the window. The stale entry also keeps
`initial_scan_complete` permanently `false` (that flag is
`loading_worktrees.is_empty() && …`).
Callers are cancelled routinely — worktree creation is async and can
take seconds on a large tree, while the tasks awaiting it are owned by
UI that the user can close at any time (a tab or pane, a debugger panel
resolving a path, an agent session, or the whole window). See the
existing note in `crates/zed/src/zed.rs` that external-file worktrees
are "released on file close".
Observed in the wild: a home-directory worktree removed from the project
kept scanning for hours and grew Zed past 45 GB; neither removing the
folder nor ending the agent session freed it — only quitting Zed. (The
scan-amplification half of that incident is #60988.)
## Solution
Spawn the map cleanup as its own detached task, next to the map
insertion, so a loading entry always leaves `loading_worktrees` when
loading resolves regardless of what happens to the callers. The returned
per-caller task is unchanged apart from no longer owning that cleanup.
## Testing
- Added `test_worktree_released_when_creation_caller_is_cancelled`: it
requests a worktree, drops the returned task immediately (as a cancelled
caller would), lets creation complete, removes the worktree, and asserts
the entity is released. It fails on `main` and passes with this change.
- Full worktree-related project integration suite is green (45/45).
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed a memory leak where a worktree whose creation was requested by a
since-cancelled task (e.g. a folder opened as its owning
tab/panel/window closed) could never be released, leaving its background
scan running and its snapshot growing for the lifetime of the window.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
# Objective
`test_rename_that_also_renames_file` (added in #59104) is
order-dependent: it passes at seed 0, which CI runs, but fails on many
others (e.g. 11, 15, 17). Any unrelated change that schedules one extra
task shifts the deterministic test scheduler enough to flip it at seed 0
too — which is how it surfaced, while working on #61009. The bug it
exposes is real and pre-existing:
#59104 stopped the content swap, but the open buffer still relied on the
filesystem watcher to follow the file to its new path. Depending on the
order the watcher reports the old path's deletion and the new path's
creation, the entry id isn't carried over, and the buffer is stranded at
the now-deleted old path (shown as saved) and never re-associates.
## Solution
Move the worktree entry explicitly after the rename, preserving its id,
the same way `rename_entry` (project panel renames) already does.
## Testing
- `test_rename_that_also_renames_file` now runs 30 seeds to cover both
orderings.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed a symbol rename that also renames the file leaving the open
buffer on the old path
Closes#39860
This PR resolves relative image paths from the Markdown source file's
project path and load images through the project image store. SVG images
over remote connections remain unsupported and are left for a follow-up.
Release Notes:
- Fixed images not rendering in Markdown Preview over remote.
PR #62502 changed the ChatGPT subscription models to report the
corresponding public API context windows. That was based on a mistaken
assumption: subscription requests go through the separate Codex backend,
which still rejects requests around the previous context limit.
Because the advertised context window also determines when Zed compacts
a conversation, reporting 1.05M tokens delays compaction until after the
Codex backend rejects the request. This reverts #62502 and restores the
previous conservative limits. Longer term, we should load the
account-specific model metadata from the Codex `/models` endpoint rather
than maintaining this list by hand.
Release Notes:
- Fixed automatic context compaction for GPT models accessed through a
ChatGPT subscription.
ChatGPT subscription models currently report the short-context billing
thresholds (272k or 372k tokens) as their maximum context windows. Those
thresholds matter when Zed is paying metered API costs, but subscription
requests are billed directly by OpenAI.
This updates the subscribed models to report the full context windows
supported by the corresponding public API models: 1.05M tokens for
GPT-5.4, GPT-5.5, and GPT-5.6, and 400k tokens for GPT-5.4 Mini. It also
reports the 128k output limit so context accounting reserves capacity
for the response. Request serialization is unchanged; the unsupported
`max_output_tokens` parameter is still omitted from requests to the
Codex backend.
Release Notes:
- Improved context window usage for GPT models accessed through a
ChatGPT subscription.
# Objective
- Fixes#62238
- Properly escapes paths in the sftp PUT line
## Solution
- 10-line wrapper function that escapes paths as sftp expects. Namely:
paths in quotes with `\\` and `"` escaped.
## Testing
- Did you test these changes? If so, how? `cargo check`
- Are there any parts that need more testing? Up to you, this is a
simple change and I dont think sftp with default install paths ever
worked on MacOS
- How can other people (reviewers) test your changes? Is there anything
specific they need to know? Just connect to a remote on OSX and see if
the logs had an sftp upload failure in there
- 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
---
Release Notes:
- Fix remote uploads over sftp where the paths contain spaces
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Since #60772, a worktree's ignore rules are also applied to the
directories above its root. Because of this, an `info/exclude` pattern
naming one of those parent directories marks it as ignored, and with it
the whole worktree below.
Stop the walk at the repository containing the worktree root.
Also skip exclude rules for paths outside the work directory they are
anchored at, as `.gitignore` and global gitignore rules already do.
Release Notes:
- Fixed a worktree being reported as entirely ignored when its
repository's `info/exclude` named one of the worktree's parent
directories
# Objective
- Stop language-server update checks from waiting forever.
**Note:** I tried to find any existing issue but no luck.
## Solution
- Set one time limit for the full response body. If the GitHub, for
example, release request stops responding, return an error. Do not let
it block language-server update checks without limit.
## Testing
- Did you test these changes? If so, how?
1. This is a flaky issue, reproducing it is not that trivial.
2. The easiest way I found is just restarting Zed until you get the
notification in the status bar `Checking for updates
<language_server_naem>`
- Are there any parts that need more testing?
No
- How can other people (reviewers) test your changes? Is there anything
specific they need to know?
See above.
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
- macOS
- 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] 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
<img width="2624" height="2260" alt="CleanShot 2026-08-03 at 20 29
11@2x"
src="https://github.com/user-attachments/assets/83e2781c-15bc-4924-be33-88c26f20387d"
/>
---
Release Notes:
- Fixed language servers update checks
# Objective
I noticed that in workspace symbol search, the function's symbol kind
has become `Trait`.
## Solution
Add `to_proto` and a macro to define the mapping instead of `as i32`.
## Testing
Updated the 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)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed `SymbolKind` mapping to LSP protocol values
OpenAI reasoning summaries are streamed as multiple indexed parts, and
each new reasoning output item starts its indexes at zero. The Responses
event mapper previously treated those indexes as global, so adjacent
reasoning items could be concatenated without whitespace, producing text
such as `**First item****Second item**`.
Track the current summary part by both its item ID and summary index,
and emit a separator whenever that pair changes. Text delta events now
retain their summary index as a fallback when a separate part-added
event is absent, while sharing the same boundary handling to avoid
duplicate separators.
Testing performed:
- `cargo check -p open_ai`
- `cargo nextest run -p open_ai`
- `cargo fmt -p open_ai -- --check`
- `./script/clippy -p open_ai`
Release Notes:
- Fixed missing separators between OpenAI reasoning summaries.
Show a modal when invoking the stash action to allow users to provide an
optional custom message for the stash entry.
Closes#62430
# Image
<img width="1622" height="1106" alt="Screenshot 2026-08-10 at 9 14
00 PM"
src="https://github.com/user-attachments/assets/0d26dac2-919d-4bb1-b6a7-433ceff18955"
/>
<img width="1622" height="1106" alt="Screenshot 2026-08-10 at 9 14
11 PM"
src="https://github.com/user-attachments/assets/896b68ff-999f-4ec9-a6a4-e0e7a6867286"
/>
# Objective
Zed's stash action runs `git stash push --quiet --include-untracked --`
with no `-m`, so every stash is labelled with git's auto-generated `WIP
on <branch>: <sha> <subject>`. That text describes the commit you were
sitting on, not what you stashed — so two stashes taken from the same
commit are indistinguishable.
This undercuts the stash picker (`git::ViewStash`), which lists entries
as `#<index>: <message>` and fuzzy-searches over exactly that string.
The search box already exists; there is just nothing meaningful to
search, because every candidate is a variation of the same
auto-generated line.
## Solution
`git::StashAll` now opens a single-line modal ("Optionally provide a
stash message") before stashing.
- Confirming with text passes `--message <text>` to `git stash push`.
- Confirming with the field empty omits the flag entirely, keeping git's
default description — so the prompt is a one-keystroke pass-through and
existing muscle memory still works.
- Cancelling aborts the stash, so the prompt doubles as a confirmation
step.
Implementation:
- `StashMessageModal` (`Editor::single_line`) in `git_panel.rs`, toggled
from `GitPanel::stash_all`. `menu::Confirm` trims the input and maps
empty to `None`.
- `message: Option<String>` threaded through `Repository::stash_all` →
`stash_entries` → `GitRepository::stash_paths`. The flag is appended
before the `--` separator so a message is never parsed as a pathspec.
- New `message` field on the `Stash` proto message, so remote and collab
projects behave identically.
One non-obvious detail: the modal is opened via `cx.defer_in` rather
than inline. `git::StashAll` is registered on the workspace
(`git_ui.rs`) as well as on the panel element, and
`Workspace::register_action` dispatches while `Workspace` is leased — so
opening the modal inline re-enters that update and hits GPUI's
`double_lease_panic`. This only reproduces when focus is *outside* the
Git Panel, which makes it easy to miss.
`Option<String>` rather than `String` is deliberate: `--message ""`
produces a blank stash description, which is strictly worse than git's
default.
## Testing
Manually verified the modal in a local build on macOS: the prompt
appears on `git::StashAll`, accepts a message, and the named entry shows
up in the stash picker.
Also verified at the git level by replaying the exact argument vector
`stash_paths` builds against a scratch repo with mixed staged / unstaged
/ untracked changes:
| Case | Result |
|---|---|
| `stash push --quiet --include-untracked --message "my named stash" --
<paths>` | `stash@{0}: my named stash`; worktree clean, untracked file
included |
| same, without `--message` | `stash@{0}: <sha> <subject>` — git's
default text |
| `--message "x" --` with no paths (clean repo) | exit 0, no stash
created — the empty pathspec does **not** stash everything |
`cargo fmt --check` clean, `./script/clippy -p git -p fs -p project -p
git_ui` passes with `--deny warnings`, and the existing suites pass
(`cargo test -p project -p git_ui`, 436 tests).
Worth a reviewer's attention: trigger `git::StashAll` with focus in the
**editor** rather than the Git Panel. That routes through the workspace
action registration and is the case the `cx.defer_in` deferral exists to
keep from panicking.
No new automated tests — the behavior is testable with the existing
`git_panel.rs` harness (`init_test`, `GitPanel::new`) if reviewers would
prefer coverage over a manual check.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments — n/a, no unsafe
added
- [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 — no new tests; see Testing
- [x] Performance impact has been considered and is acceptable — one
extra process argument; no new work on any hot path
---
Release Notes:
- Added an optional stash message prompt when stashing changes
`
---------
Co-authored-by: Chris Biscardi <chris@christopherbiscardi.com>
# Objective
- Make Git Panel grouping sections collapsible so users can hide
sections they are not currently interested in.
- Support collapsible sections when grouping changes by tracking and by
staging.
- Provide a clear visual indicator showing whether each section is
expanded or collapsed.
## Solution
- Added per-section collapsed state to the Git Panel.
- Made grouping headers clickable to toggle their section between
expanded and collapsed.
- Added chevron indicators that point down when expanded and right when
collapsed.
- Applied the behavior to both flat and tree views.
- Kept the stage/unstage checkbox independent from the header collapse
interaction.
- Ensured a previously collapsed Tracked section does not hide files
after switching to Group by None.
## Testing
- Ran `rustfmt --edition 2024 crates/git_ui/src/git_panel.rs --check`.
- Ran `cargo check -p git_ui`.
- Ran `cargo test -p git_ui`:
- 129 tests passed
- 0 tests failed
- Ran `git diff --check`.
- Attempted `./script/clippy -p git_ui` twice. It produced no lint
diagnostics but did not finish compiling the release, all-targets,
all-features dependency graph within the available timeout.
- Manually verify by selecting both grouping modes in the Git Panel and
clicking each section header in flat and tree views. Confirm that:
- The section contents are hidden and restored.
- The chevron updates to reflect the current state.
- Clicking the stage/unstage checkbox does not collapse the section.
- Switching to Group by None does not leave tracked files hidden.
## 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
https://github.com/user-attachments/assets/77ec4c88-4a6d-4e49-ac9f-ddbf80e724ca
---
Release Notes:
- Improved Git Panel organization by allowing grouped change sections to
be collapsed
# Objective
When developing remotely, when I close the uncommitted changes tab, I
need some time to load before I can copy the path. Or have to switch to
the project panel to find the specific file. All of this is annoying, so
I added a copy path action to the git panel's context menu and key
bindings consistent with the project panel.
## Solution
Already described in the Objective section.
## Testing
I wrote a unit test and tested it manually.
## 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
<img width="411" height="535" alt="showcase"
src="https://github.com/user-attachments/assets/a17e7633-eb92-4737-aa30-958fe58bb99f"
/>
<img width="717" height="427" alt="showcase"
src="https://github.com/user-attachments/assets/d067e892-17de-4527-ac20-16cad6f38015"
/>
---
Release Notes:
- Added "Copy Path" and "Copy Relative Path" actions to the Git Panel's
context menu
GPUI's input-latency histograms only sample frames that were preceded by
input, so a window that janks while animating or while streaming content
(agent panel output, terminal scrollback) never shows up in the fleet's
latency reports. Hang detection catches outright stalls, but frames that
are merely late — stutters in the 30–100ms range during animation —
currently aren't visible anywhere.
This adds a `frame-duration-histogram` feature to GPUI with a per-window
tracker recording two histograms: the duration of every `Window::draw`,
and the interval between consecutively presented frames while the window
is animating (a next-frame callback was already scheduled at the
previous present, so frames are being produced back-to-back and a
stretched interval means frames were missed). Intervals are only
recorded for active windows, since inactive windows are deliberately
throttled to a lower frame rate, and re-presents of unchanged frames
(e.g. sustaining the display's refresh rate during high-rate input) are
excluded. Zed enables the feature and reports both histograms every five
minutes as a "Frame Duration Report" telemetry event alongside the
existing "Latency Report", bucketed at roughly the 120Hz/60Hz/30Hz frame
budgets so dropped-frame rates can be aggregated across the fleet.
Release Notes:
- Added frame rendering performance to the diagnostics Zed collects when
telemetry is enabled, to help find and fix stutters and dropped frames.
Closes https://github.com/zed-industries/zed/issues/61208
Before, Zed showed no toasts on startup when tasks.json contained
malformed entries, also if there were two top-level arrays, the last one
was silently discarded without any toasts too.
The PR fixes both.
Release Notes:
- Fixed error toast not showing for malformed tasks.json
# Objective
Zed's Markdown parser accepts tilde-fenced code blocks, but Mermaid
extraction only strips backtick fences. As a result, a block like this
is parsed as Mermaid while the fence itself is still passed to the
renderer:
```markdown
~~~mermaid
graph TD;
~~~
```
## Solution
Teach the Markdown code-block helpers to recognize triple-tilde fences
alongside triple-backtick fences.
The change stays in the existing parsing path, so Mermaid rendering does
not need a separate special case. A regression test covers extraction
from a tilde-fenced Mermaid block.
## Testing
- `cargo fmt --all -- --check`
- `cargo test -p markdown` (138 tests)
- `./script/clippy -p markdown`
- `cargo build -p zed`
- Opened a `~~~mermaid` block in the built Zed Dev app on macOS and
verified that Markdown Preview renders the diagram
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed Mermaid diagrams in Markdown previews when they use triple-tilde
fences.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
# Objective
Ensure that, when users undo project panel operations, we don't trash
files with unsaved edits as that could lead to data loss, as outlined
[here](https://github.com/zed-industries/zed/issues/62243#issuecomment-5203625087).
Closes#62243
## Solution
Update `UndoManager::trash` to require confirmation before moving files
to the trash. For files with unsaved edits, users can save, discard, or
cancel the operation while clean files receive a standard trash
confirmation, same as shown when trashing a file through the Project
Panel.
This helps avoid the issue where, if an user undoes a file creation for
a file that has unsaved edits and then quits Zed, the edits that were
saved in memory, as well as the Project Panel history, will now be gone
and there's no way to recover the data.
Batch operations have also been updated to now show a single
confirmation before making filesystem changes, preventing partial
execution when cancelled and warning about unsaved edits.
Lastly, the trash/delete prompt building has been refactored in order
for the Project Panel and Undo Manager to share the same wording,
file-list truncation, and unsaved-change warnings.
## Testing
Tested both manually as well as added the following tests:
* `project_panel::tests::undo::undo_create_cancel_trash`
* `project_panel::tests::undo::undo_create_dirty_file`
* `project_panel::tests::undo::cancel_partial_trash_batch`
* `project_panel::tests::undo::batch_trash_warns_about_unsaved_changes`
## 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
The screen recording below shows the trash confirmation dialog on both a
clean and dirty files, on both undo and redo flows.
https://github.com/user-attachments/assets/0f9b96f5-0357-4e3f-8ec2-141486942c89
---
Release Notes:
- Fixed issue with undoing or redoing project panel operations that
could lead to a file with unsaved edits being trashed without
confirmation.
Recommends GPT-5.6 Sol for both OpenAI BYOK and OpenAI subscription.
Also unifies the naming so that we use the same OpenAI model names for
the Zed/OpenAI BYOK and OpenAI subscription providers.
Release Notes:
- N/A
This reverts commit 6297c88f42.
---
fixes#62286fixes#62095https://github.com/zed-industries/zed/pull/61467 fixed its intended bug,
but at the same time introduced an issue where running tasks that would
cause new tasks to be terminated immediately.
https://github.com/zed-industries/zed/pull/62322 tried to fix that
forward, but was unsuccessful. In the mean-time I am going to revert the
original PR.
We can try to re-land the original bugfix in a future PR.
Release Notes:
- N/A
Follow-up to #59838, implementing what was discussed at the end of
#59829: cmd-click navigation now respects `lsp_results_location` when
go-to-definition falls back to find-all-references (invited in
https://github.com/zed-industries/zed/issues/59829#issuecomment-4989966493:
"It would! Feel free to hook that up if you'd like to!").
## Problem
Cmd-clicking a symbol's definition falls back to find-all-references,
but the results always open in a multibuffer even with
`"lsp_results_location": "picker"`. The hover-link click path calls the
editor navigation methods directly, so the action handlers registered by
`lsp_locations` never get a chance to intercept.
## Solution
- `handle_click_hovered_link`'s fallback now dispatches the
`FindAllReferences` action (with `open_results_in: None`, deferring to
the global setting) instead of calling the method, so the
`lsp_locations` handler can intercept it, or propagate to the editor's
built-in handler when the setting is `multi_buffer`, preserving today's
behavior exactly.
- The plain cmd-click arm of `cmd_click_reveal_task` now runs the
definition query via `go_to_definition_of_kind` (no internal references
fallback) instead of `go_to_definition`, so the click path has a single
fallback decision point: the dispatching one. Without this, the method's
baked-in fallback opened a multibuffer before the dispatch could run.
- `go_to_definition_of_kind` visibility widened to `pub(crate)` for the
call from `hover_links.rs`.
Shift/alt click variants (type definition, splits) are untouched.
Keyboard invocations were already intercepted and are unchanged.
## Testing
- New test `test_cmd_click_fallback_honors_lsp_results_location` in
`lsp_locations`, following the module's existing test patterns: fake LSP
returning no definition and two references, `lsp_results_location:
picker`, simulated cmd-click at the cursor's pixel position, asserts the
picker opens. The test fails without this change.
- `cargo nextest run -p lsp_locations`: 6/6.
- `cargo nextest run -p editor -E 'test(hover) or test(fallback) or
test(go_to_definition) or test(references)'`: 54/54.
- `cargo fmt` and `./script/clippy` clean.
- Verified manually in a release build: with the setting on,
cmd-clicking a definition opens the picker; with it off, behavior is
unchanged.
Per the contributing guidelines' note on AI assistance: this change was
developed with heavy AI assistance (Claude Code). I have reviewed and
understand the full diff and the reasoning behind each hunk, and I'm the
one answering review feedback.
Release Notes:
- Fixed cmd-click go-to-definition falling back to a references
multibuffer even when `lsp_results_location` is set to `picker`.
# Objective
The `gpui::img` element always overrides the `aspect_ratio` field, so if
you have an image element that applies its own `.aspect_ratio()` it just
gets wiped out.
## Solution
Only apply the aspect ratio default if one is not already set.
## Testing
It's a very minor change but I did add a small test to ensure it
actually gets overridden.
## 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
This came from an issue where vertical images inside an element (square
in this case, as you'd see in an image gallery) do not behave correctly
with `object_fit` values of `ObjectFit::Contain` or
`ObjectFit::ScaleDown`.
This was simply because despite the image element having a fixed square
size (`img().size(px(200.))`), the aspect ratio would be forced to the
ratio of the image itself, so vertical images weren't being properly
fitted into their containers.
Minimal repro for that issue:
https://github.com/zaknesler/gpui-object-fit
So with this change, you can set `.aspect_square()` and the object fit
will behave as you'd expect:
<img width="1237" height="986" alt="image"
src="https://github.com/user-attachments/assets/5b1045a8-bd71-4b77-8bbd-c3b12112bcb0"
/>
---
Release Notes:
- gpui: Fix image element's aspect ratio overriding existing value
## Summary
- Add `terminal.starts_open` setting so the terminal panel can open
automatically in new workspaces, like project and git panels already can
- Expose the setting through terminal settings docs, default settings,
Settings Editor metadata, and the terminal panel implementation
- I also added a matching settings page item for the existing
`git_panel.start_open` setting
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 behaviour
- I decided not to add tests as the behaviour seems covered by the
existing settings tests, and similar areas don't seem to have their own
explicit tests.
- [x] Performance impact has been considered and is acceptable
Related to #51542 (issue mentions possibly adding for all panels, closed
with implementation for `git_panel`)
Release Notes:
- Added `terminal.starts_open` to control whether the terminal panel
opens automatically in new workspaces
# Objective
Follow-up to zed-industries/extensions#7062.
## Solution
Add `("windows-batch", &["bat", "cmd"])` to
`SUGGESTIONS_BY_EXTENSION_ID`
## 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:
- Added a suggestion to install the `windows-batch` extension when
opening `.bat` and `.cmd` files.
Kirill Bulatov