5245 commits

Author	SHA1	Message	Date
Kirill Bulatov	d6449a9e3f	editor: Truncate oversized LSP hover contents before display (#63022) ... Closes https://github.com/zed-industries/zed/issues/45728 Similar to VSCode, trims the hovers down to 100KB of text. Release Notes: - Fixed overly large LSP hovers causing performance issues	2026-08-24 08:56:20 +00:00
Kirill Bulatov	6bf539cd52	Do not show useless toasts during recursive blaming (#63111) ... Follow-up to https://github.com/zed-industries/zed/pull/62614 <img width="1728" height="1084" alt="bad" src="https://github.com/user-attachments/assets/5fafb9cb-38be-44ba-b8a3-a33dc10106da" /> Properly disable actions instead of showing odd toasts and do nothing when invoked without the prerequisites. Release Notes: - N/A	2026-08-23 19:29:43 +00:00
Matei Oprea	907ed09c9f	editor: Prevent auto save formatting on read only files (#62921) ... # 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>	2026-08-21 13:19:58 +00:00
tidely	5b70f793d3	Use Duration to improve type safety and unit correctness (#62969) ... # 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 ...	2026-08-21 07:28:05 +00:00
Daniel	cb1352a29d	Add configurable inline completion debounce timeout (#61568) ... # 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>	2026-08-20 16:42:42 +00:00
Kirill Bulatov	deb194b49b	Properly deduplicate overlapping range formatting results (#62935) ... 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	2026-08-20 12:15:06 +00:00
Anıl Zeybek	09adbb01f6	workspace: Persist recent navigation history across sessions (#55034) ... 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.	2026-08-20 11:27:03 +00:00
xdBronch	dbdcb310d1	Respect lsp_results_location for declaration and type definition (#61060) ... # 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	2026-08-20 11:17:57 +00:00
Neel	282f47a544	Switch from cargo-machete to cargo-shear (#62643) ... This results in ~110 crates being removed, and some orphaned files also. --- Release Notes: - N/A Signed-off-by: Neel <neel@zed.dev>	2026-08-20 10:08:48 +00:00
Nikita Demin	30aea6ac4a	editor: Add in_preview boolean context for keybindings (#61777) ... # Objective - Add an `in_preview` context that is available when the current editor is in preview mode (opened from project panel or go to definition). - closes https://github.com/zed-industries/zed/discussions/61765 ## Solution - In `editor.rs`, added a check in `key_context()` that detects if the editor is the active preview item in its pane, and if so, adds `"in_preview"` to the key context. - Uses existing `workspace.pane_for_item_id()` and `pane.is_active_preview_item()` methods — no new APIs introduced. ## Testing - Added two tests in `editor_tests.rs`: - `test_in_preview_context_added_when_in_preview_mode` — verifies `in_preview` is present when editor is set as preview item. - `test_in_preview_context_not_added_when_not_in_preview_mode` — verifies `in_preview` is absent for regular (non-preview) tabs. - Tested on 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 --- Release Notes: - Added `in_preview` keybinding context for when an editor is in preview mode.	2026-08-19 21:35:38 +00:00
Enzo GAZZOLI	e3056061d4	Render control characters in tab titles and project panel entries (#62875) ... # Objective Fixes #62664 File names may contain control characters (`\n`, `\r`, `\t`, …) on most platforms. Zed rendered them verbatim, so a file named `notes\ndraft.md` broke the layout of its tab and of its project panel entry instead of showing a readable name. The same held anywhere else a name reached the screen without going through `Label::single_line`. ## Solution The substitution lives in one shared place, `ui::utils::replace_control_characters`, reached through `Label::single_line`. `\n` keeps rendering as the `⏎` Zed already used, so nothing that renders correctly today changes; every other C0 control character maps onto the Unicode "Control Pictures" block by a single rule (`U+2400 + code point`), giving `␉` for tab and `␍` for carriage return. `DEL` maps to `␡`. C1 controls are left alone, having no equivalent there. Where that is wired in: - **`Label::single_line`** — replaces its previous `\n`-only substitution. The project panel already used it everywhere, including folded directory components, so the panel is fixed by this alone. - **Editor tabs** and the **default `Item::tab_content`**, neither of which called `single_line`. - **Terminal tab titles**, which render through their own `tab_content`. Those titles come from OSC escape sequences, so the control characters in them are attacker-controlled. - **`HighlightedLabel::single_line`**, which never substituted anything — not even `\n`. See below. - **The file finder**, for both the file name and the path. - **Nine `tab_content` overrides in git_ui**, by deleting them. - **`HighlightedMatchWithPaths`**, for both the match label and its paths — it backs the tab switcher and the outline panel, among others. ### `HighlightedLabel` needs its offsets moved, not just its text Its highlight indices are byte offsets, and every stand-in is wider in bytes than the character it replaces, so the offsets have to move with the text. Left alone they index into the middle of a character, and `highlight_ranges` slices the string at exactly those offsets — which panics in release builds too. The constructor's `debug_panic!` does not cover this, since `single_line` runs after construction. So `replace_control_characters_remapping_offsets` substitutes and remaps in one pass, over an old-to-new byte offset table built the way `ensure_uniform_list_compatible_label` does it in `lsp_store`. This also fixes the call sites that already asked for a single line, including the branch picker and the tabular column filter values. ### Deleting the git_ui overrides Nine files replicated the default `Item::tab_content` verbatim except for the colour, hardcoding `selected ? Default : Muted` instead of `params.text_color()`. Deleting them lets those tabs inherit the fixed default, and fixes a second bug along the way: none of them dimmed when the pane lost focus. Titles and icons are unaffected — they come from `tab_content_text` and `tab_icon`, which the default calls. `git_graph.rs` already did it this way. ### Tabular column headers These never went through a `Label` at all: the raw `SharedString` was a child of a `div`. They now display stand-ins, while right-click-copy still yields the real column name. Two notes for reviewers: - Both helpers avoid allocating when there is nothing to replace, so the common path is untouched. The previous `self.label.replace('\n', "⏎")` allocated a `String` on every render for every label — including every visible project panel entry, every frame. - Every stand-in is exactly one character, so character offsets are preserved and the existing `truncate_and_trailoff` math on tab titles stays correct. ## Testing - Unit tests cover both helpers: each control character's substitution, repeated occurrences, multi-byte characters (accents, emoji), the borrow-vs-own behaviour, the preserved character count, C1 passthrough, and — for the remapping — offsets before, at and after a replacement, offsets at and past the end, and the invariant that every remapped offset lands on a character boundary. - Unit tests cover `Label::single_line` and `HighlightedLabel::single_line`, the entry points every call site uses. `highlighted_label.rs` had no tests before. - `cargo test -p ui -p file_finder -p workspace -p project_panel -p git_ui -p git_ui_core -p terminal_view -p tabular_data_preview` passes (774 tests), as do `cargo clippy` and `cargo fmt --check`. - No existing test changes behaviour: tests assert on `tab_content_text`, which is untouched; only rendering paths changed. - Verified manually on macOS (aarch64) — see Showcase. ## 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 - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable ## Showcase A directory holding `report<TAB>table.csv`, `notes<LF>draft.md`, `carriage<CR>return.txt` and a normally named `normal.txt`, all four open as tabs. **Before**  **After**  Three things change: 1. **The `notes<LF>draft.md` tab** is the clearest one. Before, the literal newline splits the tab across two lines — `notes` above `draft.md` — distorting the whole tab bar. After, it stays on one line. 2. **`carriage<CR>return.txt` in the project panel** renders as `carriagereturn.txt` before: the `\r` is completely invisible, so the name reads as one word and there is no way to tell a character is there. After, it renders as `carriage␍return.txt`. 3. **`report<TAB>table.csv`** shows a bare gap before, indistinguishable from a space. After, it renders as `report␉table.csv`. Note that `notes<LF>draft.md` looks the same in the project panel in both shots: that entry already called `single_line`, which already handled `\n`. That is precisely the asymmetry this PR removes. ### File finder Before, the newline also breaks the list itself — the `notes<LF>draft.md` row grows to two lines and overlaps the row beneath it. **Before**  **After**  Searching for `table` exercises the offset remapping, the match falling after the control character: **Before**  **After**  One thing this PR does **not** cover: the breadcrumb below the tab bar still renders the raw tab character, as it goes through a different path. ## Release Notes: - Fixed file names containing control characters, such as tabs and newlines, rendering unreadably in tabs, the project panel, the file finder, the tab switcher and terminal tab titles. --------- Co-authored-by: Kirill Bulatov <kirill@zed.dev>	2026-08-19 21:10:56 +00:00
Ibrahim Khan	828544342d	search: Fix regex replace with lookahead and lookbehind (#61900) ... # Objective - Fixes #25905 - Regex search-and-replace silently does nothing when a same-line pattern contains a lookahead or lookbehind. Searching highlights the correct hits, but Replace All or `:s` in Vim mode leaves the buffer untouched. Reproduce with `316227766016837933199`, search `(\d)(?=(\d{4})+$)` in regex mode, and replace with `$1,`. Expected: `3,1622,7766,0168,3793,3199`. Actual before this change: nothing changes. The same problem affects `(?<=foo: )bar` replaced with `BAZ`. `SearchQuery::replacement_for` expanded the replacement by re-running the whole pattern against the matched text alone. Lookaround assertions inspect text outside the match, so the isolated hit no longer matched and the edit replaced the hit with itself. ## Solution - `replacement_for` now expands from captures located at the exact hit range within its source context. - Single-line regex hits use the complete source line, so lookahead, lookbehind, and line anchors see the same surrounding text used by search. - Literal and escaped-regex searches bypass context reconstruction because their replacements do not use captures. - Multi-line hits retain the exact matched text, preserving the prior cross-line behavior. - If selection boundaries prevent the pattern from matching the reconstructed line, replacement falls back to the isolated hit, preserving prior behavior. - Replace All caches the source line across hits on the same line. Cross-line lookaround remains unchanged: assertions that need text outside a multi-line hit still produce a no-op replacement. Search-within-selection can also retain the prior no-op behavior when the selection boundary changes assertion context. ## Testing - `cargo test -p search test_replace_with_lookaround` (2 passed) - `cargo fmt --all -- --check` - `./script/clippy -p editor -p project -p search` - Tested on Linux arm64. The change is platform independent. ## Self-Review Checklist: - [x] I have reviewed the diff for quality, security, and reliability - [x] Unsafe blocks, if any, have justifying comments - [x] The content adheres to Zed UI standards - [x] Tests cover the changed behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - Fixed same-line regex replacements that use lookahead or lookbehind	2026-08-19 15:55:24 +00:00
Buyun Xu	3624a5bfda	project: Anchor diagnostic related information that points into the buffer (#62805) ... Closes #62796. Follow-up to #62110. # Objective The range of a diagnostic entry is anchored when it is ingested, so it follows edits. The ranges in the related information kept on the diagnostic were the ones the server published. A code action request carried both and reported the same note at two different lines: the entry Zed flattened that note into had followed the edit, the related information had not. The distance does not correct itself either. When diagnostics are merged rather than replaced, the existing entries are re-collected from their anchors while the payload is cloned as it is, so the two positions drift further apart with every edit that passes. `mlir-lsp-server` shows what this costs. `MLIRTextFile::getCodeActions` takes the line number out of `relatedInformation`, and `getCodeActionForDiagnostic` resolves it against its own current document, reading that line to copy its indentation before inserting the `expected-note` check. ## Solution The related information moves from `Diagnostic` onto `DiagnosticEntry<T>`, next to the range it belongs with. The locations of the diagnostic's own file are then in the same coordinate space as that range: anchors inside the buffer, points in the worktree's store. `Diagnostic` carries no coordinates again, so nothing that is only meaningful inside one buffer travels with a payload that outlives it. Every transition goes through `DiagnosticEntry::map_coordinates`: the unsaved-edit adjustment and the clipping when diagnostics are ingested, the anchoring in `DiagnosticSet::new`, and the conversion back to points in `merge_diagnostic_entries`. Only the diagnostic's own range is widened when it is empty, since that is for how it is rendered, while the related locations are reported back as the server framed them. Locations in another file have nothing here to anchor to and are kept as published, which is also what `mlir-lsp-server` expects, since it skips them. `DiagnosticEntryRef` is left alone. It is what the rendering path iterates, down to the scrollbar markers that walk every diagnostic of the buffer on each frame, so nothing there converts or allocates. The entries are read through `diagnostic_entries_in_range` where the request is built, and `diagnostics_in_range` is now implemented on top of it. The field is an `Option`, as an empty `Arc<[_]>` still allocates and most diagnostics carry no related information. `data` has the same staleness and cannot be anchored, as it is opaque. ## Commits The third commit is mechanical: it introduces `DiagnosticEntry::new` and rewrites the literals at its call sites, so that the last commit holds only the change of behaviour. ## Testing Three tests, all failing before this change. The first two are added as separate commits, so that they can be run against `main`: - `test_code_actions_related_information_follows_edits` edits above the note and requests code actions, where the two positions for it used to disagree. - `test_code_actions_related_information_drifts_across_merges` edits and pulls diagnostics twice, where the distance used to be every line inserted since the diagnostic was published rather than the last edit alone. - `test_code_actions_related_information_of_disk_based_diagnostics` publishes a diagnostic computed against the file on disk while the buffer holds an unsaved edit, covering the adjustment the two positions share. - `cargo test -p project` - `cargo test -p language -p diagnostics -p editor` - `cargo fmt --all -- --check` - `./script/clippy -p project -p language` ## 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 language servers receiving outdated positions for the related information of a diagnostic when code actions are requested.	2026-08-18 15:06:02 +00:00
afdul	a7d74150ac	Fix the git_gutter_width setting (#62704) ... # Objective - Fixes #62645 ## Solution Since the default value isnt constant.It now has two options 1) Default 2) custom where user inputs a value. ## 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 - [ ] Performance impact has been considered and is acceptable ## Showcase <img width="798" height="361" alt="Screenshot 2026-08-16 at 4 29 54 PM" src="https://github.com/user-attachments/assets/0af302f6-4733-4a23-9e93-1f9d98dd772f" /> <img width="798" height="92" alt="Screenshot 2026-08-16 at 4 30 13 PM" src="https://github.com/user-attachments/assets/2c87c2a3-2947-45c7-8495-f6a0b36dd793" /> Release Notes: - Added git_gutter_width setting to the Settings UI with default (font-size-scaled) and custom (fixed pixel width) options --------- Co-authored-by: Abdul Rafey Ahmed <abdul.r@hyperverge.co> Co-authored-by: MrSubidubi <finn@zed.dev>	2026-08-18 12:40:18 +00:00
vinod akshat	dfb696697e	Fix horizontal autoscroll not following cursor on long selections (#62691) ... # Objective Fixes #62524 This bug was introduced in a regression from #61487, which fixed horizontal autoscroll for multi-row selections (word wrap off) by computing target_left/target_right from the selection's actual start/end instead of just head.That fix changed target_left/target_right from always being a single point (head's column) to spanning the full selection width. This tripped an existing guard (if target_right - target_left > viewport_width { return None; }) whenever a selection was wider than the viewport, previously dead code, since target_left/target_right were never far apart before #61487. The function now bails out before adjusting scroll at all in that case. ## Solution In `autoscroll_horizontally`, compute the selection's span width per row. If it exceeds the viewport width, fall back to tracking just head (the pre-#61487 behavior) instead of the full start/end span. If it fits, keep using the full span so the #61409 fix is unaffected. ## Testing - Did you test these changes? If so, how? - Tested manually in-app on macOS: selecting a long line with cmd+shift+end now scrolls correctly. (NOTE: I used Claude to write these unit tests for me) - Added test_autoscroll_horizontally_long_selection_tracks_cursor: selects a 250-character line in a narrow viewport and asserts the scroll position moves to follow the cursor, instead of staying frozen at 0. - Added test_autoscroll_horizontally_fitting_selection_reveals_full_span: selects a short span that fits within the viewport and asserts the full span is revealed, confirming the #61409 fix still holds. - Ran the full editor test suite locally (cargo test --package editor --lib), all passing. ## 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 --- Release Notes: - Fixed horizontal scroll not following the cursor when selecting a line longer than the viewport width --------- Co-authored-by: Kirill Bulatov <kirill@zed.dev>	2026-08-17 16:39:45 +00:00
Xin Zhao	378d6254d5	language: Fix auto-indent overwriting manual indentation when replacing a line's contents (#62644) ... # Objective Closes #62617 Turns out #62617 is just a special trigger point of a more general issue: replacing a line's contents can silently rewrite the line's indentation with the auto-indent suggestion. Consider the following Rust code, where the line has an extra tab, making its indent 8 spaces instead of the default 4: ```Rust fn main() { println!("hello world"); } ``` If we select and replace the line's contents (without the indentation): ```Rust fn main() { «println!("hello world");» } ``` with `let a = 8;`, the result is: ```Rust fn main() { let a = 8; } ``` The extra indent has been stripped. Tracing this down to `Buffer::edit_internal()` in `crates/language/src/buffer.rs`, the code decides whether the edited line needs an indent update via the `first_line_is_new` flag, which ends up as the `old_row` of an `AutoindentRequestEntry`. One of these checks is: cdc537c690/crates/language/src/buffer.rs (L2913-L2918) When replacing a line's contents, the edit range ends exactly at the end of the line, so `old_start.column + (range_len as u32) == old_line_end`. Because the check uses `<`, this case meets none of the these conditions, `first_line_is_new` stays `true`, and an indent update is triggered. If the manual indent differs from the suggested indent, it gets overwritten — exactly as in the example above. For IME input, composition updates replace the previously marked preedit text, which sits at the end of the line — the same geometry as a full line-content replacement. In some environments (observed on KDE Wayland with fcitx), a single keystroke delivers the preedit update twice, so the replacement happens on the very first keystroke, which is what #62617 reports. On other platforms, the replacement may happens once the composition changes, i.e. on the second keystroke, so it takes at least two characters to trigger. ## Solution Simply change the guard from `(old_start.column + (range_len as u32) < old_line_end` to `(old_start.column + (range_len as u32) <= old_line_end`. ## Testing Two new tests are added: `test_ime_composition_keeps_manual_indent` covers the IME input path, and `test_replacing_line_content_keeps_manual_indent` covers a plain line-content replacement. ## 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 manual indentation being lost when replacing a line's contents or typing with an input method	2026-08-17 12:58:34 +00:00
Kirill Bulatov	e0931d5a9d	Reuse char-scan invisibles detection in highlight_invisibles (#62715) ... Follow-up to https://github.com/zed-industries/zed/pull/62478#discussion_r3769810809 New bench results: | corpus | old | new | speedup | |---|---|---|---| | ascii, no invisibles | 83 MB/s | 580 MB/s | **7.0x** | | unicode, no invisibles | 88 MB/s | 442 MB/s | **5.0x** | | sparse invisibles | 63 MB/s | 431 MB/s | **6.9x** | | dense invisibles | 82 MB/s | 109 MB/s | 1.3x | Release Notes: - N/A	2026-08-17 09:45:39 +00:00
hvck	8968bf7808	git: Decode non-UTF-8 blobs for project diffs (#60821) ... ## Summary Fixes #56449. Related to #16965. Zed’s Git panel and Project Diff build UI diffs from `language::Buffer` diff bases loaded through the Git backend. Git blob loading previously converted bytes with `String::from_utf8(...).ok()`, so legacy-encoded blobs were treated as missing and the whole worktree file appeared newly added. This follows the same encoding path used for worktree buffers: - move shared byte decoding and encoding into `language` - keep Git blob, revision, and index APIs byte-oriented with `Vec<u8>` - decode diff bases and index contents in `GitStore`, where `language::Buffer`s are created - encode index writes using the open buffer’s encoding and BOM so partial staging does not rewrite the file as UTF-8 - keep worktree loading and saving on the same shared implementation Regression coverage includes Windows-1251 decoding/encoding, UTF-8/UTF-16 BOM preservation, raw Windows-1251 Git blob loading, and a `BufferDiffSnapshot` assertion that a one-line CP1251 edit produces one modified-line hunk instead of a full-file rewrite. This does not run Git `textconv` commands. It fixes the reported legacy-encoding case without executing repository-configured commands or modifying working files on disk. ## Testing - `cargo test -p language file_content::tests --locked` - `cargo test -p git repository::tests::test_load_revisions --locked` - `CARGO_INCREMENTAL=0 cargo test -p project git_store::tests::test_decode_git_text_windows_1251_one_line_change --locked` - `CARGO_INCREMENTAL=0 cargo test -p project --test integration test_restaging_hunk_after_optimistic_unstage --locked` - `CARGO_INCREMENTAL=0 cargo check -p project --tests --locked` - `CARGO_INCREMENTAL=0 cargo check -p git_ui --tests --locked` - `cargo fmt --all --check` - `git diff --check` ## Suggested .rules additions - N/A Release Notes: - Fixed Git panel and Project Diff rendering for legacy-encoded text files whose Git blobs are not valid UTF-8. --------- Co-authored-by: Cole Miller <cole@zed.dev>	2026-08-17 01:47:11 +00:00
Finn Evers	f543a7642d	editor: Match invisible character ranges directly (#62708) ... Local benchmark shows this speeds it up by at least 30% and is definitely more reasonable to have like this than compared to iterating over a list for every given char. Release Notes: - N/A	2026-08-16 13:40:29 +00:00
Полина	bc6095f2c0	editor: Fix buffer header context menu line height in multibuffers (#61923) ... ## Objective Right-clicking a buffer header in a multibuffer showed a context menu whose item spacing did not match other context menus. The menu is drawn via a deferred draw, which inherits the editor's text style stack, so its line height followed `buffer_line_height` instead of the default UI line height. This is the same root cause as #24504, which #25172 fixed for the editor's mouse context menu and completion popovers. The buffer header menu was a remaining call site. ## Solution `ContextMenu` now applies the default (`comfortable`) line height itself in `render`, next to its existing rem size and font family normalization, so menus render the same regardless of where they are opened from. This fixes the all workarounds and the need for them too: the workaround in `layout_mouse_context_menu` is removed, and the buffer header ends up needing no changes at all. The completions and code actions popovers keep their override in `element.rs`: they are not `ui::ContextMenu`s and compute their sizes with eager `window.line_height()` reads while being built, so styling on the elements they return cannot cover them. Migrating them could be a follow-up. ## Testing - `cargo check --workspace` passes, `./script/clippy` on the touched crates passes. - Manual: set `"buffer_line_height": "standard"` (or any extreme custom value to see it better), open a multibuffer (e.g. project search), right-click a buffer header, and compare the menu with another context menu (e.g. a tab's) — spacing matches. The editor's mouse context menu, which lost its own override, renders as before, and with default settings there is no visual change anywhere. - Tested on macOS, change is platform-independent styling. ## 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 (visual styling fix; menu text styles have no existing test coverage) - [x] Performance impact has been considered and is acceptable ## Showcase Regular context menu: <img width="425" height="164" alt="A context menu elsewhere in the app, showing normal item spacing" src="https://github.com/user-attachments/assets/1fc13981-b394-444f-883a-ce3ef462c386" /> Before: <img width="425" height="164" alt="Buffer header context menu before the fix, with tighter item spacing following the custom buffer_line_height" src="https://github.com/user-attachments/assets/9774076c-7e0c-41dd-b54f-53de58b24336" /> After: <img width="425" height="164" alt="Buffer header context menu after the fix, with item spacing matching other context menus" src="https://github.com/user-attachments/assets/ae76e37c-8e39-474c-8a5e-e229e69173fb" /> --- Release Notes: - Fixed the file header context menu in multibuffers not matching other context menus' spacing when a custom `buffer_line_height` is set. --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>	2026-08-16 11:41:17 +00:00
Kirill Bulatov	f0685e0a4f	Support blaming parent revisions (#62614) ... Closes https://github.com/zed-industries/zed/discussions/42583 Adds more tooltip entries and `editor::BlameRevision`, `editor::BlamePreviousRevision` actions to use. Started to highlight gutter blame entries that belong to currently annotated commit. https://github.com/user-attachments/assets/ba754e0b-6431-407c-8d79-2f8b0324fde1 Release Notes: - Supported blaming parent revisions	2026-08-14 20:24:13 +00:00
Bennet Bo Fenner	5fa874234f	editor: Treat blank rename as no-op (#62630) ... Confirming an inline rename after deleting the entire symbol name or entering only whitespace currently submits an invalid rename request to the language server. This can remove the symbol text instead of leaving the source unchanged. Treat empty and whitespace-only replacements as successful no-ops after dismissing the inline rename UI. Returning a completed task also consumes the confirmation action, preventing Enter from propagating back into the editor. Non-blank rename behavior remains unchanged. The regression test covers both empty and whitespace-only rename fields, verifying that no LSP rename request is sent and the original buffer remains intact. Release Notes: - editor: Fixed confirming a blank symbol LSP-rename modifying the source code	2026-08-14 13:53:21 +00:00
Kirill Bulatov	47825fe00a	Properly measure invisible character replacement (#62478) ... Another discovery during search-on-type work. Follow-up to https://github.com/zed-industries/zed/pull/19298 and https://github.com/zed-industries/zed/pull/19846 With the `"soft_wrap": "editor_width"`, I should have no text contents overflowing the editor width. Before (scrollbar shown incorrectly): <img width="2032" height="1162" alt="before" src="https://github.com/user-attachments/assets/8b89ba6d-f98b-4ea0-89f2-8a22e968c438" /> After: <img width="2032" height="1162" alt="after" src="https://github.com/user-attachments/assets/93f62c2b-4981-48ae-aebd-8b0021348787" /> Release Notes: - Fixed invisible symbol replacement width calculation	2026-08-14 09:35:59 +00:00
Som Tripathi	0ad5441b53	editor: Align selections by display position instead of byte column (#61997) ... # 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>	2026-08-14 00:20:27 +00:00
Michael Thomas	bc463bc205	Send correct line endings to language servers (#59941) ... # 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](1b6cde7032). 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>	2026-08-12 18:14:22 +00:00
Ibrahim Khan	770a977c68	editor: Keep the cursor before text inserted by on-type formatting (#61823) ... ## 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>	2026-08-12 18:14:00 +00:00
Xin Zhao	52894d3f48	Respect the filterText of LSP completion items during completion filtering (#62433) ... # Objective Closes #61646. For code completions, Zed currently fuzzy-matches against `CodeLabel::filter_text()`: d4010e91cc/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.	2026-08-12 18:13:41 +00:00
Toru Nayuki	a034d87024	project: Don't let a canceled caller leak a loading worktree forever (#61009) ... # 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>	2026-08-12 18:13:37 +00:00
Sava Dimitrijević	371a7d4ba2	editor: Honor lsp_results_location in the cmd-click references fallback (#61187) ... 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`.	2026-08-09 13:58:30 +00:00
Apoorva Verma	803467f37f	text_finder: Highlight the query as a regex when the regex filter is on (#61128) ... the buffer search and project search bars both already load the `regex` language and put it on their query buffer when the regex filter is on. the text finder never got that, so a regex you type in there is just plain text. did the same thing here. the only slightly annoying part was that the picker's head editor is `pub(crate)`, so text_finder couldn't get at it. added a small `query_editor()` accessor to `Picker` for that. `adjust_query_regex_language` mirrors the two existing ones. test asserts the query buffer's language is regex with the filter on, and gone once it's off. Closes #59945. Release Notes: - Improved the text finder by highlighting the query as a regex when the regex filter is on --------- Co-authored-by: Kirill Bulatov <kirill@zed.dev>	2026-08-08 14:03:54 +00:00
Piotr Osiewicz	c24358d96c	deps: Bump pathfinder_simd & fix upcoming rustc warnings (#62170) ... While building Zed with nightly rustc I've noticed it doesn't compile because of good old pathfinder_simd. It also emits a bunch of warnings about use of f64 literals where f32 is expected, so I've fixed them - it should make future upgrades more straightforward.	2026-08-07 10:16:57 +00:00
Ben Kunkle	101ca00a13	editor: Treat punctuation as separate word boundaries (#62224) ... # Objective Fixes FR-149 - Make word movement and selection predictable around punctuation. - Prior art: [#58882](https://github.com/zed-industries/zed/pull/58882), [#61916](https://github.com/zed-industries/zed/pull/61916), and their revert [#62213](https://github.com/zed-industries/zed/pull/62213). ## Solution - Treat words and punctuation runs as separate movement units in both directions. - This adds a stop between leading punctuation and its following word, such as `.▏foo`. ## Testing - Added table-driven coverage for reported examples, delimiters, operators, punctuation runs, and Unicode punctuation. - Tested editor movement, selection, and deletion behavior. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([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 word movement and selection stopping on the wrong side of punctuation.	2026-08-06 17:51:48 +00:00
Ben Kunkle	65a5c89a9e	language: Defer auto-indent until parsing catches up (#62024) ... # Objective Prevent auto-indent from using stale syntax when text changes during a background parse. ## Solution Keep auto-indent pending and parsing active until the current parse completes. ## 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: - Editor: Fixed auto-indent occasionally using stale syntax after rapid edits.	2026-08-05 16:55:10 +00:00
Joseph T. Lyons	4b407d0fe4	editor: Revert punctuation word movement changes (#62213) ... Reverted due to regressions in editor word navigation around punctuation: - https://github.com/zed-industries/zed/pull/58882#issuecomment-5138947209 - https://github.com/zed-industries/zed/pull/58882#issuecomment-5153627453 - https://github.com/zed-industries/zed/pull/62065#issuecomment-5178850523 Release Notes: - Reverted #61916 and #58882	2026-08-05 14:47:53 +00:00
Xin Zhao	2d9e6278e7	vim: Fix cursor placement after switching to Helix normal mode with a multi-key binding (#62080) ... # Objective Closes #41744 When a multi-key binding switches from Insert mode to Helix normal mode, subsequent editing actions can place the cursor incorrectly. While a printable multi-key binding is pending, Zed temporarily inserts the pending keys into the buffer. Once the binding is matched, Zed dispatches the associated action and then deletes the pending text. Because the buffer uses a CRDT, the deleted text remains as tombstoned fragments. The cursor can still resolve to the correct visible offset while its selection anchor remains associated with one of those fragments, affecting the ordering of subsequent edits. Among the explicit Vim mode-switch actions, `SwitchToHelixNormalMode` is the only one that preserves the existing selections: ce6f3af5f7/crates/vim/src/vim.rs (L713-L719) As a result, the tombstone-associated anchor is carried into Helix normal mode, where later actions such as `o` can place the cursor on the wrong side of the inserted newline. The affected path is narrow: a multi-key binding must invoke `SwitchToHelixNormalMode` from Insert mode. This creates pending text and then preserves the resulting selection anchors when entering Helix normal mode. There are two possible layers at which to address this. At the Editor layer, selections could be refreshed whenever pending text is removed so that they no longer reference deleted fragments. At the Vim layer, the Helix mode transition can explicitly guard against preserving those anchors. PR #50918 attempted the broader Editor-layer solution by refreshing selections after resolving a multi-key binding. However, as discussed in this review comment: https://github.com/zed-industries/zed/pull/50918#issuecomment-4411319469, the more appropriate scope for this reported issue is the Vim mode-switching layer. ## Solution Based on PR #50918 and its review feedback, this PR limits the fix to `SwitchToHelixNormalMode`. When that action is triggered by pending Insert-mode keystrokes, Vim refreshes the preserved selection anchors after the pending text is removed. This keeps the fix scoped to the affected Helix transition without changing other multi-key bindings. ## Testing Added a GPUI regression 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 incorrect cursor placement after using a multi-key binding to leave insert mode in Vim or Helix mode. --------- Co-authored-by: dino <dinojoaocosta@gmail.com>	2026-08-05 11:03:09 +00:00
Drew Ridley	bbd198f57b	editor: Resolve semantic token overlaps by configured server order (#61735) ... `RawSemanticTokens` says tokens later in the list override earlier ones on overlap, but there's no list to be later in — the tokens are stored in a `HashMap<LanguageServerId, _>` and the sort that flattens them keys only on `range.start`: 9dcc3c2909/crates/project/src/lsp_store/semantic_tokens.rs (L702-L709) 9dcc3c2909/crates/editor/src/semantic_tokens.rs (L312-L314) `sort_by` is stable, so two servers' tokens at the same position keep whatever order the map iteration gave them, and which one wins changes between sessions. You hit this any time two servers tokenize the same range. In my case a server that highlights an embedded query inside a string literal renders fine, then loses the range to svelte-language-server once that refreshes. Setting `languages.Svelte.language_servers` doesn't help, since that isn't what decides it. Breaking ties by `server_id` makes it deterministic. `SemanticTokenHighlight` already carries the id and `LanguageServerId` is `Ord`, so it's just the tiebreak. Worth noting the servers do arrive as an ordered `Vec` from `language_server_ids_for_buffer` and that order is dropped when they go into the `HashMap`. Sorting by id gets determinism but not that original order; if preserving it is what was intended I'm happy to submit a PR for that functionality instead. Release Notes: - Fixed semantic token highlighting being applied unpredictably when more than one language server provides tokens for the same range.	2026-08-04 14:05:46 +00:00
William Whittaker	c6e0868cb8	vim: Fix insert above auto-indentation (#52594) ... Fixes InsertLineAbove (Shift + O) auto-indent handling by deciding whether to trim the first character or the last character based on direction. Previously, inserting a line above would auto format the line the cursor was originally on and not the new line (instead of the correct behavior which is to do the opposite). No tests because I couldn't find any Vim-specific auto-indent tests and this only affects Vim mode. If I'm missing something there LMK and I'll take a closer look. Closes #52588. Release Notes: - Vim: Fixed auto-indentation for insert above action. --------- Co-authored-by: dino <dinojoaocosta@gmail.com>	2026-08-04 11:45:33 +00:00
Evan Vinciguerra	35cb7558a9	editor: Add configurable git gutter width setting (#61304) ... ## Summary Adds a `gutter.git_gutter_width` setting that lets users pin the width, in pixels, of the git diff hunk indicators in the editor gutter. Previously the width was always derived from the buffer font size (`floor(0.275 * line_height)`), which can render too thin or too thick depending on font family and display pixel density. This adds an optional override: ```json { "gutter": { "git_gutter_width": 6 } } ``` When the setting is unset (`null`, the default), the width continues to scale with the buffer font size, so existing behavior is unchanged. ## Motivation Requested in [discussion #27799](https://github.com/zed-industries/zed/discussions/27799). Beyond the width itself, participants noted the git hunk hit target is extremely narrow and hard to click. Because the hunk hitbox reuses the painted strip bounds, setting a wider `git_gutter_width` also widens the clickable area, addressing that complaint with the same setting. ## Changes - `settings_content`: new `git_gutter_width: Option<f32>` on `GutterContent`. - `editor`: mirror field on the resolved `Gutter`; `gutter_strip_width` now consults the setting, and the value flows through `diff_hunk_bounds` (including the deleted-hunk marker) and the gutter layout anchors for line numbers, folds, and expand toggles. - `settings` (VS Code import): pass through the new field. - Docs + `default.json`: document the new setting. ## Notes - `Eq` was dropped from `GutterContent`/`Gutter` because `f32` is not `Eq`; this matches the existing `EditorSettingsContent` convention for float-bearing settings. Release Notes: - Added a `gutter.git_gutter_width` setting to configure the width of git diff indicators in the editor gutter --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-08-03 01:46:00 +00:00
Kirill Bulatov	90d024b88a	Fix the display point out of range panic due to wrong coordinate space used (#62055) ... Closes ZED-AKV Closes ZED-ANB Follow-up to https://github.com/zed-industries/zed/pull/61153 The original PR mixed up the coordinate spaces, and the newly added methods used buffer rows (as the existing code did before that PR), but the new code uses `FoldMap` which expects a tab row instead of the buffer one. Release Notes: - Fixed a panic when selections are added by tab-expanded column	2026-08-01 21:34:47 +00:00
Mikayla Maki	5e1fd392f6	git: Add diff_base setting for showing changes since the default branch (#61501) ... # Objective Let git indicators — the editor gutter, file colors, and `git::Diff` — show all changes on the current branch relative to its merge base with the default branch, instead of only uncommitted changes. Supersedes #60398; thanks to @samuelcolvin for the original implementation and motivation. Closes FR-135 ## Solution - New `git.diff_base` setting (`"head"` | `"default_branch"`), applied live and toggleable per session from the editor controls menu ("Diff Against Default Branch"). - Statuses come from a real merge-base-to-worktree tree diff (`git diff --merge-base`), so local edits that revert branch changes correctly show as unchanged. - `GitStore` shares one `DiffBufferList` per repository with the Branch Diff view; `repo_snapshots` and `project_path_git_status` keep returning index/worktree truth, while display surfaces use separate `display_*` APIs. - `BufferDiff` now records what its base is (`DiffBaseKind`); hunks whose base isn't HEAD are read-only in the gutter — stage/restore buttons and keybindings are inert, so committed work can't be silently rewritten. - `git::Diff` follows the setting; new `git::DiffHead` always opens the HEAD diff; `git::BranchDiff` is renamed `git::DiffBranch` (deprecated alias kept). Tradeoffs / known limitations: - Hunk-level staging is unavailable while in `default_branch` mode (whole-file staging via the git panel still works). Staging just the uncommitted sub-ranges of a branch hunk is a follow-up. - Remote hosts running an older server ignore the new `GetTreeDiff.includes_worktree` proto field and degrade to committed-changes-only branch diffs. - Repositories with no resolvable default branch fall back to HEAD-relative behavior; a failed first resolution retries on the next branch-list change. ## Testing - Real-git-repo tests for the merge-base-to-worktree diff's edge cases: files recreated after index deletion, committed deletions recreated on disk, and symlinks. - GPUI tests for status semantics (a branch change reverted on disk shows clean), `git::Diff` routing, live setting changes, and read-only hunk enforcement (restore/stage leave buffer and index untouched). ## 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 a `git.diff_base` setting (`"head"` or `"default_branch"`) that makes the editor gutter, file colors, and diff view show all changes on the current branch since its merge base with the default branch, instead of only uncommitted changes. --------- Co-authored-by: Ben Kunkle <ben@zed.dev>	2026-07-31 19:57:13 +00:00
Tai Nguyen	f56ff65c92	editor: Stop opt-left on the right side of punctuation between words (#61916) ... Closes #61884 Release Notes: - Fixed Option+Left stopping to the left of punctuation between words Video URL: https://files.catbox.moe/8d5g2t.mp4	2026-07-31 15:19:16 +00:00
AidanV	5f180e06dc	editor: Add multiple_selections key context (#60018) ... # Objective - I would like to have the Vim command `z z` do different actions depending on if I have multiple selections. If I only have one selection I want `z z` to center my only selection (current behavior); however, if I have multiple selections I would like `z z` to run `editor::OpenSelectionsInMultibuffer`. This PR does not add this specific functionality (happy to be convinced otherwise), but it does let users add this type of functionality. ## Solution - Add a new key context field that is active only when there are multiple selections. ## Testing - Changes are quite small. A test on this would really be testing other parts of the code-base more than this change. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable ## Showcase https://github.com/user-attachments/assets/2559e218-d6fa-492a-949b-f4ab8b880f28 This allows us to add something like the following to the `keymap.json`: ```json { "context": "VimControl && !menu && multiple_selections", "bindings": { "z z": "editor::OpenSelectionsInMultibuffer", }, }, ``` which lets us change the functionality of a keystroke based on if there are multiple selections. This video has the following keystroke sequence: `z z` (Center the cursor normally) `5 g l` (Select the 5 next occurrences of the word under the cursor) `z z` (Open selections in multi-buffer) (Previously `z z` in this context would just center the last selection) https://github.com/user-attachments/assets/a0dc1813-5420-4cda-a1ec-99e6681680e7 --- Release Notes: - Added `multiple_selections` keystroke context Co-authored-by: Lukas Wirth <lukas@zed.dev>	2026-07-31 06:49:53 +00:00
Finn Eitreim	79cc17c216	gpui: Give divs (the option for) a better scrolling experience (#61797) ... # Objective Closes #56127 Right now there is an issue where in certain contexts, specifically GPUI div elements, horizontal scrolling w/ a trackpad works very poorly, even when trying to scroll sideways, vertical scrolling will happen. This happens with both a trackpad and scrollwheel. The showcase video also shows the broken behavior. ## Solution The way that scrolling works in the editor is really nice, scrolls are locked to the axis they started on but with enough force can change axis. so by taking the ongoing scroll handler from the editor and moving it up into GPUI, we can get that same functionality for GPUI. I somewhat "take over" the functionality of the existing `restrict_scroll_to_axis` property, because it seems like its purpose was basically trying to fix this problem already, just unsuccessfully. The alternative, and would make things overall nicer to look at, would be to tie this to `allow_concurrent_scroll`, but the effect radius tied to that option is way bigger, so im holding off on that atleast right now. ## Testing Theres a good number of scroll related tests generally, so I don't think i've perturbed any common existing behaviors. attach the functionality to `restrict_scroll_to_axis` really limits the surface. There are also some new tests for the ongoing_scroll behaviors. Tested on my mac w/ both trackpad and mouse. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable ## Showcase Video show casing all the behaviors: broken w/ trackpad working w/ trackpad broken w/ scroll working w/ scroll https://github.com/user-attachments/assets/1935cd2d-a255-4a77-81d5-daa9f72470a6 --- Release Notes: - markdown_preview: Fix horizontal scrolling inside certain elements	2026-07-30 16:30:13 +00:00
mTvare	200fb85c90	language: Fix incomplete bracket matches during error recovery (#61604) ... Closes #61410 ## Summary Tree-sitter bracket queries can become incomplete when recovering from syntax errors. The existing code handled incorrect matches by collecting the delimiters returned by the query and pairing them again in order. The query missed the innermost closing parenthesis. The repair therefore worked on an incomplete sequence, paired the innermost opening parenthesis with the next available close, and shifted every remaining pair outward. ## Solution This change records the syntax-node kinds used by each bracket pattern and, when a syntax layer contains errors, checks the concrete leaves inside those error nodes for delimiters missing from the query output. When the opening and closing kinds are different and the error range remains balanced, the missing delimiters are included in the existing reconstruction. ## Testing Reproduced the issue using the C snippet from #22679 and verified that each parenthesis is matched with its correctly nested partner. Also verified that unbalanced code does not cause the recovery logic to invent a missing bracket pair. ## How to Review The relevant changes are in `BufferSnapshot::fetch_bracket_ranges` in `crates/language/src/buffer.rs`. The important distinction is between the bracket-query output and the concrete syntax leaves inside an error node. Previously, the repair could only rearrange delimiters present in the query output. It can now detect when that output is incomplete, add the missing real delimiters, and run the existing reconstruction over the complete set. ## Self-Review Checklist * [x] I've reviewed my own diff for quality, security, and reliability * [x] Unsafe blocks, if any, have justifying comments * [x] The content is consistent with the [[UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) * [x] Tests cover the new/changed behavior * [x] Performance impact has been considered and is acceptable Release Notes: * Fixed incorrect bracket matching when syntax-error recovery omitted a delimiter. --------- Co-authored-by: Kirill Bulatov <kirill@zed.dev>	2026-07-30 08:36:14 +00:00
Kunall Banerjee	6109c2e6d8	grammars: Support linked editing of custom elements in JSX and TSX (#58578) ... JSX and TSX only treated the dot as a tag-name character during linked-editing, so renaming a tag to a custom element name such as `custom-el` stopped mirroring the closing tag at the dash. A follow-up to https://github.com/zed-industries/zed/pull/43179, really. Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [ ] Unsafe blocks (if any) have justifying comments - [ ] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [x] Tests cover the new/changed behavior - [ ] Performance impact has been considered and is acceptable Closes #58553. Release Notes: - Added support for linked-editing of custom elements in JSX/TSX --------- Co-authored-by: MrSubidubi <finn@zed.dev>	2026-07-29 21:23:53 +00:00
Julien Roncaglia	33f1112fc2	theme: Specify color format and pattern in schema (#49136) ... ## Purpose While developing a theme for Zed I remarked that the schema available doesn't mark colors in a way that Zed recognize to display the color annotations: ```json { "$schema": "https://zed.dev/schema/themes/v0.2.0.json" } ``` <img width="119" height="190" alt="Screenshot 2026-02-25 at 23 15 10" src="https://github.com/user-attachments/assets/3f1bb703-cb26-4630-9598-3a7cb8873c20" /> But Zed has support for it when colors are marked with `"format": "color"` in the schema: <img width="127" height="186" alt="Screenshot 2026-02-25 at 23 14 58" src="https://github.com/user-attachments/assets/1a9387a4-613a-4cf8-a3af-f6ac201bdf54" /> So I searched if the schema file was Open Source somewhere, discovered it was generated from the codebase and attempted the change. ## Implementation This is essentially done using a `ThemeColor` wrapper for the color strings that implements `JsonSchema` with a dedicated regex for validation and the color format specified. This ends up with a new `$defs` of `Color` being specified and used: ```json { "$defs": { "Color": { "type": "string", "format": "color", "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{4}|[0-9a-fA-F]{6}|[0-9a-fA-F]{8})$" } } } ``` ## Other - There is a small change I made for testing to the schema_generator that adds an `--output` / `-o` flag. When provided it writes the generated schema JSON to the specified file path instead of printing to stdout. This was done to made testing easier but I can remove it or split it to a separate PR (It's already a separate commit) - For this PR to do anything a new schema version will need to be published at something like `https://zed.dev/schema/themes/v0.3.0.json` and documentation needs to be updated to point to it. Before you mark this PR as ready for review, make sure that you have: - [x] Added a solid test coverage and/or screenshots from doing manual testing (Manual testing, couldn't find any existing good place to test it) - [x] Done a self-review taking into account security and performance aspects - [x] Aligned any UI changes with the [UI checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) Release Notes: - N/A --------- Co-authored-by: MrSubidubi <finn@zed.dev>	2026-07-29 20:59:24 +00:00
Kirill Bulatov	fa1d0362b4	Fix mouse multi cursor placement for wrapped lines (#61590) ... Closes https://github.com/zed-industries/zed/issues/25237 https://github.com/user-attachments/assets/0f1d54a0-c8f1-4b49-8327-73375a2e1f4e Release Notes: - Fixed mouse multi cursor placement for wrapped lines --------- Co-authored-by: Finn Evers <finn@zed.dev>	2026-07-28 12:49:43 +00:00
Ben Kunkle	7b030b5008	project: Fix panic when an inlay hint response outlives its buffer version (#61747) ... # Objective Fix a nightly crash where Zed aborts on a bounds-check panic in the inlay hint cache. `LspStore::inlay_hints` captures a `RowChunk` before awaiting the language server, then reads the hint cache with that chunk's id afterwards. If the buffer shrank meanwhile, `latest_lsp_data` has already rebuilt the cache with fewer chunks, so the stale id indexes out of bounds. Chunks are 50 rows, so the reported crash only needed a ~150-250 line deletion, not a drastic edit. Regressed in #61523. Nightly only; the regressing commit is in no release tag, so this never reached preview or stable. Fixes ZED-AGY Fixes FR-142 ## Solution - Return an empty result when the buffer version no longer matches, so a stale chunk id can never index the rebuilt cache. The stale *writes* were already guarded by this version check; only the read sat outside it. - An empty result is already treated as "not fetched", so the chunk is simply re-requested on the next refresh. ## Testing `test_inlay_hint_response_after_buffer_shrinks` reproduces the abort deterministically and passes with the fix. Note that it drives the race through a fake language server rather than a real one. ## 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	2026-07-27 21:04:36 +00:00
Tommy Han	edd906859c	Revert force hardmark settings for documentation hover (#61622) ... Closes https://github.com/zed-industries/zed/issues/60777 # Objective - Due to #59426, forcing docString softmark to hardmark, an regression has appeared. It causes all docString on different language to load newLine (`\n`) by default, instead of soft wrap. - By checking the issue, turns out we should not setting `soft_break_as_hard_break: true`, this will make the hover docString less - Details can refer to #60777 ## Solution - Revert settings by removing the line in `hover_popover.rs:742` ## Testing - About the testing result and comparsion, you can refer to #60777 - Updated test `test_hover_markdown_preserves_soft_breaks` to `test_hover_markdown_soft_breaks_reflow_per_commonmark` ## 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 an issue where hover documentation could have too many line breaks. --------- Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>	2026-07-27 12:43:36 +00:00
Jakub Konka	afd17238ed	editor: Check anchor validity for hovered links (#61686) ... Closes FR-112 Otherwise, if a multibuffer snapshot changed under the hood for example one of the paths changed, without doing an explicit validity check, we would panic during comparison instead. Release Notes: - Fixed panic when hovering links during an under-the-hood multibuffer changes.	2026-07-26 16:37:40 +00:00