2e2fb0a21811ce2dbaca5bb738b0be8f94de051e
39151
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Kirill Bulatov
|
7cf50a771f |
Add more context (#60913)
Started an old Zed version with old db entry which resulted in 0 agent panel working, only showing me there and in logs "project path not found". Fixed by removing the corresponding `db` subdirectory, but decided to make the log entries a bit more useful. Release Notes: - N/A |
||
|
Danilo Leal
|
a496bf0ff6 |
Add a bunch of stray design refinement throughout (#60937)
This PR is a collection of grab bag UI design refinements across the entire app. Most of them are minor icon fixes/standardizations, spacing, and sizing tweaks. The one change that ended up getting a bit bigger than I initially anticipated is the debugger panel tabs improvements; added a bunch of tweaks there to make it look slicker. A relevant change is a small one-line change to the GPUI div element where it wouldn't add drag-over styles to elements that aren't initially a hitbox target. Given I wanted to pull off the drop indicator you see on the video below, this turned out to be needed: https://github.com/user-attachments/assets/964b456a-eef0-42bb-a433-7dac54ab8ec8 --- Release Notes: - N/A |
||
|
Danilo Leal
|
0f58431f51 |
thread_view: Add a component for the terminal's tool call header (#60931)
This PR introduces a component for the terminal tool call's header. It was growing already pretty big in the terminal tool call render function in the thread view and hard to visualize in all of its use cases. I got motivated to do this because I wanted to make the UI for the case when it runs outside of the sandbox simpler, but it wasn't easy to make that show up in a true agent thread, and with it being a component, I can just use the component preview. Here's a quick screenshot of it, it shouldn't look too different, just a bit more polished: <img width="600" alt="Screenshot 2026-07-13 at 6 43@2x" src="https://github.com/user-attachments/assets/fb222e50-2003-4cf7-9039-7b211db3c86e" /> Release Notes: - N/A |
||
|
Lukas Wirth
|
f7cf09b367 |
language_model: Fix compilation on wasm (#60955)
Release Notes: - N/A or Added/Fixed/Improved ... |
||
|
byteoxo
|
4780220eeb |
Recognize deno.lock as JSON (#60679)
Reasons: Deno officially states that the deno.lock file is of JSON type. https://github.com/denoland/vscode_deno/blob/main/schemas/lockfile.schema.json Release Notes: - Added JSON language support for `deno.lock` files. |
||
|
Ruslan SemaginandDanilo Leal
|
97110fd5a1 |
Show tag names in git blame tooltips (#60757)
Fetch tag names for commits included in blame data and pass them through the blame rendering path. Render tag names as chips in the blame hover tooltip and expanded blame popover. Tag lookup is best-effort, so blame still renders if tag lookup fails. > Note: Tag names are currently only fetched for local repositories. For remote projects (SSH) and collab sessions, blame data travels over the `BlameBufferResponse` proto message, which doesn't carry tag names yet. ## Testing - `cargo test -p git test_parse_tag_names_for_lightweight_and_annotated_tags` - `cargo check -p git_ui` - `cargo check -p editor` - `cargo check -p project` Manual testing: - Opened `git: blame` on a file with a tagged commit. - Verified tag chips are shown in the blame hover tooltip and expanded popover. ## 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: <img width="1655" height="660" alt="before" src="https://github.com/user-attachments/assets/dbefd729-f8df-48a9-8249-83c93518fe76" /> After: <img width="1655" height="660" alt="after" src="https://github.com/user-attachments/assets/2c1097de-b268-45d9-9d13-0f3e06058603" /> --- Release Notes: - Git: Made tags visible in Git blame tooltips. --------- Co-authored-by: Danilo Leal <daniloleal09@gmail.com> |
||
|
Akshit JoshiandEric Holk
|
5471ee3f8b |
Fix CloseProject not switching to neighbor in multi-project workspace (#60524)
Fixes #54772 When "Workspace: close project" was used in a multi-project window, the handler pre-created an empty "get started" workspace and activated it before removing the old project group. This prevented `remove_project_group` from detecting that the active workspace was being removed, so the neighbor-fallback never ran — leaving the user on the empty workspace even though other projects were still open. The fix delegates entirely to `remove_project_group`, which already handles: - Computing a neighboring project group - Prompting for unsaved changes via `prepare_to_close` - Activating the neighbor (or creating an empty workspace if none remains) This matches the behavior of the sidebar "Remove Project" action, which uses the same `remove_project_group` path. Release Notes: - Fixed "Workspace: close project" action not switching to another project in multi-project workspace --------- Co-authored-by: Eric Holk <eric@zed.dev> |
||
|
Apoorva VermaandKirill Bulatov
|
56ab1c4825 |
project: Report formatter failures in the status bar again (#60839)
set a formatter that fails (`"formatter": {"external": {"command":
"false"}}`), save, and you get nothing. it just goes to the log, the
"Formatting failed" indicator never shows.
#51605 made the formatter loop log-and-continue instead of bailing (so
unrelated edits don't get reverted, #51490). downside was the pipeline
always returned Ok after that, so the failure flag the indicator reads
always got wiped. this brings back failures from formatters you actually
configured. auto ones stay quiet when they're not around, so no prettier
installed = still a no-op.
only explicit failures show up, bit narrower than before #51605. can
widen it to auto ones too if you want, one line.
Fixes #59988.
Release Notes:
- Fixed formatter failures not showing the "Formatting failed" status
bar indicator
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
|
||
|
Finn Eitreim
|
78c0f2522a |
editor: Fix incorrect inlay hint selection behavior (#60912)
# Objective Fixes #48141 The issue is that there are certain situations where an Inlay hint, specifically hints that appear to the left of whatever item they are referring to, e.g. function argument hints, will be selected incorrectly. https://github.com/user-attachments/assets/b6d60bad-6999-481b-a1c7-420d3ee113f8 As you can see in the video, in both a modal and non-modal editor, as soon as you include `(` (or the empty space between the first and second argument) the hint gets highlighted as well. ## Solution It is really important to note here that there is no issue with the actual selection semantics, inlay hints don't get truly selected in the sense that they don't count as buffer text and if you e.g. copy a selection with a hint in it it doesn't get copied. A second thing to note is that a fix that looks good for modal editing might not look good for regular editing, thats largely what sank the previous attempt to fix this issue (#51219). This video is from #51219, but earlier versions of my fix suffered from the exact same issue. https://github.com/user-attachments/assets/16452530-1918-47da-9fd4-87c285284959 The cursor behavior for an active selection in a non-modal editor and when there isn't a selection are different, and right now the behavior is wired for the non-selection case, the solution to this is to separate how things display with a selection from the other behavior. !I do not change the non-selection behavior in any way! Inlay hints at the boundary of a selection should be excluded, but hints inside of a selection should be part of the contiguous selection. We can reuse the `DisplayPointConverter` to do this. My original solution was to use `isomorphic_display_point_ranges_for_buffer_range`, which maps a buffer offset range into a `DisplayPoint` range that excludes Inlays, except it actually maps to potentially several ranges, all the buffer text *in between* inlay hints. By just taking the start of the first sub-range, and the end of the last, we get the correct range that we are looking for. The function I added, `contiguous_display_point_range_for_buffer_range` basically just does exactly that, and cut out all the extra work of creating a bunch of intermediate ranges if it was a large selection with lots of inlays. Then we can set the cursor head based on this range, this gives the correct behavior for non-vim mode cursors, the vim mode cursor is handled by other code after we set that anyway, so vim mode behavior is unchanged. These code changes are in `SelectionLayout::new` ```rust let buffer_snapshot = map.buffer_snapshot(); let point_selection = selection.map(|p| p.to_point(buffer_snapshot)); let display_selection = point_selection.map(|p| p.to_display_point(map)); let mut range = display_selection.range(); let mut head = display_selection.head(); if !line_mode { let offset_range = point_selection.start.to_offset(buffer_snapshot) ..point_selection.end.to_offset(buffer_snapshot); if let Some(contiguous_range) = map.contiguous_display_point_range_for_buffer_range(offset_range) { range = contiguous_range; // Keep the cursor attached to the highlight boundary; the // anchor-bias display position may sit on the far side of a // boundary inlay the highlight excludes. head = if selection.reversed { range.start } else { range.end }; } } ``` Heres the new behavior: https://github.com/user-attachments/assets/cbbd53d6-bbea-4c50-91b5-23eaccd5d9d7 ## Testing added `test_selection_layout_around_inlay`, that fails on main currently and passes with my changes. As far as manual testing the setup is pretty easy, this is generally pretty language agnostic and can be tested anywhere with function parameter hints. ## 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 rendering issues with selections over inlay hints. |
||
|
Baris Palaska
|
5d447d4223 |
gpui_web: Only prevent default for keyboard events the app handled (#60889)
# Objective The web platform called `event.preventDefault()` unconditionally before dispatching every keydown and keyup, destroying all browser defaults (reload, zoom, tab search, find, address bar) whether or not the app used the key. The dispatch result already carries the answer: `!propagate` means a keybinding matched or a handler consumed the keystroke in the current focus context. ## Solution Prevent the default only when the app consumed the keystroke, when the printable character was inserted into the input handler, or mid-IME composition. Unbound chords now fall through to the browser, and the behavior is focus-aware: a chord bound in an editor is consumed there but keeps its browser default when nothing that binds it is focused. ## Testing Tested locally. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - N/A |
||
|
Danilo Leal
|
90b3aa0b3b |
picker: Improve multi-select discoverability and rendering (#60919)
This PR reworks how multi-select mode is rendered in pickers (only used by the file finder and text finder). The "Multi Select" entry previously lived inside the footer's Actions menu, which was hard to discover and its toggle checkmark misaligned the menu's keybinding column. This PR changes to an icon button at the far-roght edge of the search editor, with a tooltip showing the keybinding to toggle it. Also made each list item use the actual Checkbox component instead of a bespoke re-implementation of it. And in doing so, added a few design improvements to the list item so that it received the checkbox while preserving proper styles for each interaction state, as well as displaying the keybinding to select the item or check the item. Here's a quick video, showing these changes off: https://github.com/user-attachments/assets/e142f7d1-87ba-4258-844b-953ed06237bd Release Notes: - Improved multi-select in the file finder and text finder: the toggle now lives in the search bar with a `cmd-shift-s` keybinding, and selection checkboxes render inside list items. |
||
|
Dario Griffo
|
bd72919555 |
docs: Update community Debian mirror domain to deb.griffo.io (#60909)
The community-maintained Debian repository linked in the Linux install docs moved from `debian.griffo.io` to `deb.griffo.io` to comply with the [Debian trademark policy](https://www.debian.org/trademark) (Debian trademarks may not be used in domain names). Same repository, packages, and signing key; the old domain serves permanent redirects, so existing links keep working — this just points the docs at the canonical URL. I maintain the repository in question. Release Notes: - N/A |
||
|
Kirill Bulatov
|
4884a7b46e |
Fix CLI split diff lhs not getting a language registered (#60914)
Closes https://github.com/zed-industries/zed/issues/60751 Release Notes: - Fixed split file diff missing syntax highlighting |
||
|
Kunall Banerjee
|
c399451ca0 |
settings_ui: Open ACP docs from Settings UI correctly (#60881)
## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [ ] Unsafe blocks (if any) have justifying comments - [ ] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [ ] Tests cover the new/changed behavior - [ ] Performance impact has been considered and is acceptable Closes #60822. --- Release Notes: - Fixed broken handler for opening ACP documentation from the Settings UI |
||
|
Cameron Mcloughlin
|
2268045a11 |
a11y: Landmarks and menu improvements (#60397)
Fixes menu a11y, and adds landmarks with `F6`-navigation. Also fixes a GPUI bug, and adds debug actions for dumping a11y tree info. Since `F6` was already in use by the pause debugger keybind, also tightens up the debugger keybind context so they require an active debugger session. When there is one active, `F6` stays as pause debugger. `ctrl-F6` always works to go to the next landmark. Also adds an "accessible mode" setting. Currently, this only controls whether we show all menus all the time, but I suspect it will expand significantly in the future. Also adds `.aria_keyshortcuts()` API, but it's not wired up within accesskit adapters, so is not yet reported to screen readers. --- Release Notes: - N/A or Added/Fixed/Improved ... |
||
|
Smit Barmase
|
a21e87c077 |
git_ui: Fix remote branches missing from branch diff base picker (#60765)
The branch picker collapses remote branches that are tracked by a local branch (e.g. `origin/main` when local `main` tracks it). That makes sense for checkout, where the remote ref is redundant, but it was also applied to the branch diff base picker, where `main` and `origin/main` can point to different commits. As a result, once you switched the diff base from `origin/main` to `main`, there was no way to switch back. The tracked-remote collapsing is now only applied in checkout mode (no changed here). The select (diff base) picker lists both local branches and their remote upstreams. Release Notes: - Fixed remote branches (e.g. `origin/main`) not appearing in the branch diff base picker, making it impossible to switch back after changing the base to another branch. |
||
|
Richard Feldman
|
96ce8f2a05 |
gpui_macos: Replace per-window CVDisplayLinks with a per-display registry (#60696)
Fixes ZED-7XR CVDisplayLink has no safe teardown: `CVDisplayLinkStop` only flags the io thread to exit "soon" and returns, `CVDisplayLinkRelease` frees the link immediately, and there is no way to learn when a final output callback has finished. This produced two distinct use-after-free crash classes on the display-link thread: the io thread reading the freed link's internals (`CVHWTime::reset`, worked around by leaking the link in #32116), and a straggler output callback dereferencing the freed dispatch source through its context pointer (`dispatch_source_merge_data`, ZED-7XR). Because we tore down a `DisplayLink` on every resize tick, window activation, and occlusion change, the existing workaround also leaked a stopped CVDisplayLink per teardown, unboundedly. This replaces per-window links with a static registry holding one immortal `CVDisplayLink` per display. Windows subscribe to their display's link with the dispatch source that paces their frames; the output callback's context is a display id rather than a pointer, so the only memory it ever dereferences is the registry itself, under its lock. Links start and stop at subscriber-count edges (so multiple windows on one display can't interleave starts/stops incorrectly), and a window's dispatch source lives for the life of the window, is removed from the registry on close, and is then genuinely released. Both crash classes become unreachable — the link because it is never released, the source because a straggler callback either finds it live in the registry or doesn't find it at all — and there are no leaks and no `mem::forget`. Since we never hold the registry lock across CoreVideo calls, no lock cycle through CVDisplayLink's undocumented internal locks is possible; the module doc comment spells out the invariants. This supersedes #60481, which fixed ZED-7XR by leaking the dispatch source on teardown. Release Notes: - Fixed a rare crash on macOS when closing, resizing, or switching between windows, and eliminated a memory leak in display-link teardown |
||
|
Baris Palaska
|
084b5d21f6 |
gpui_web: Implement clipboard write and paste (#60890)
# Objective write_to_clipboard was a no-op and read_from_clipboard returned None. ## Solution Writes go through the browser's asynchronous Clipboard API, fire-and-forget, invoked synchronously inside the user's input event so the user-activation requirement holds. Reads cannot be implemented the same way: the async clipboard read API cannot fit read_from_clipboard's synchronous signature. Paste is instead delivered by a DOM paste listener on the hidden input, whose ClipboardEvent exposes clipboardData synchronously; the text feeds the active input handler. This covers keyboard-, menu-bar- and context-menu-initiated paste. Note the keyboard path requires the paste chord's keydown to reach the browser unconsumed (apps should not bind cmd/ctrl-v on web). ## Testing Tested locally ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - N/A |
||
|
Ahmed GhaitandChris Biscardi
|
8906914149 |
agent: Show MCP tool primary argument in tool-call header (#54604)
## Problem Built-in tools like `Fetch` render their primary argument next to the tool name in the collapsed tool-call header (e.g. `Fetch https://example.com`). MCP tools don't — they always show `Run MCP tool <name>` and the argument is hidden inside the expandable "Raw Input" JSON block. For Playwright, fetch, search, or any MCP tool where one argument carries all the context, this makes every call opaque. You have to click to expand just to see which URL is being opened or which file is being read. Before: ``` ⊙ mcp__playwright__open_url_in_browser [click to expand] Raw Input: { "url": "https://linkedin.com/in/neuodev" } ``` After: ``` ⊙ Run MCP tool `mcp__playwright__open_url_in_browser` https://linkedin.com/in/neuodev ``` ## Root cause `ContextServerTool::initial_title` at `crates/agent/src/tools/context_server_registry.rs` discards the input: ```rust fn initial_title(&self, _input: serde_json::Value, _cx: &mut App) -> SharedString { format!("Run MCP tool `{}`", self.tool.name).into() } ``` Built-in tools read the input (`fetch_tool.rs`: `format!("Fetch {}", MarkdownEscaped(&input.url))`) but the generic MCP path never did. ## Change When the MCP tool's input is a JSON object with exactly one string-valued field, inline that value next to the tool name. All other shapes (multi-field objects, non-string values, null/empty input) fall back to the existing `Run MCP tool <name>` label, so behavior is unchanged for them. - Value is truncated at 120 chars with `…` on overflow (char-safe, not byte-safe — "café" won't panic). - Value is run through `MarkdownEscaped` so markdown metacharacters render literally. - Single-string heuristic was chosen because the MCP spec has no standard field for a display template, and the common case (`url`, `path`, `query`, `selector`, `name`) is covered. I considered honoring `Tool.annotations.title` or `_meta["zed/title"]` as a template — happy to follow up with that if the team prefers an opt-in mechanism, but wanted to start with something that works out of the box for every existing MCP server. ## Tests Added 10 unit tests in the existing `mod tests` block covering: happy path, no args, null input, multi-field fallback, non-string fallback, truncation, markdown escaping, multibyte chars, and empty-string preservation. `cargo check -p agent --tests` passes locally. I couldn't run the full test binary on my machine because `wasmtime-c-api-impl` (a transitive test-dep) needs `cmake`, but the new code is pure string-manipulation with no wasm/runtime touch — CI should cover. ## Scope One file, +127/-3. No behavior change for any tool shape other than single-string-input MCP tools. ## Per CONTRIBUTING.md Happy to convert to a discussion first if the team prefers — didn't see a tracking issue for this. Also filed under CLA (signed). Release Notes: - Show MCP tool primary argument in tool header if space allows --------- Co-authored-by: Chris Biscardi <chris@christopherbiscardi.com> |
||
|
Danilo Leal
|
6b2857feab |
Revert "settings_ui: Shrink constraint on minimum window width (#60786)" (#60903)
Allowing the settings UI to shrink smaller than that size can easily cause UI states where the whole window becomes unusable. The previously defined 900px size was defined so that those states did not happen. I appreciate how having such minimum size can be a bit of a hassle when the settings window is used with window managers, but given it's such a transient window (i.e., one which you won't always have open all the time) I think it's better to stay on the trade-off side of safety here. As a quick example, it doesn't make sense to me to allow the UI to reach this state: <img width="300" alt="Screenshot 2026-07-13 at 9 26@2x" src="https://github.com/user-attachments/assets/f2aebe21-293b-468f-b03e-37cd7305a9c5" /> --- Release Notes: - N/A |
||
|
Karsten
|
8e06c323ae |
Drop the unused avif feature from the image dependency (#60897)
# Objective Every build of zed (and of every downstream gpui consumer) currently compiles rav1e, a full AV1 video encoder, because `image`'s default `avif` feature is enabled. That feature only provides `AvifEncoder`; AVIF *decoding* requires the separate, non-default `avif-native` feature (dav1d). So AVIF files do not decode anywhere in zed today, nothing encodes AVIF (`AvifEncoder` has zero references in the repo), and rav1e plus its support crates are dead weight in every clean build. ## Solution Pin the workspace `image` dependency to its default feature set minus `avif`. No behavior changes: AVIF files fail to decode exactly as before, and `ImageFormat::Avif` still exists (the enum is not feature-gated), so the `image_viewer` match arm compiles unchanged. The `"avif"` entry in gpui's supported-extension list is deliberately left untouched to keep the diff minimal; loading such files fails identically before and after. ## Testing - `cargo metadata` node diff (before vs after, all 1832 resolved packages): the only change in the entire graph is `image` losing `avif`/`default`/`default-formats`. - `cargo tree -i rav1e` on the Linux host, plus `--target aarch64-apple-darwin` and `--target x86_64-pc-windows-msvc`: no reverse dependencies on any platform. - `rg -i avif crates/` finds only string labels (an extension list in `gpui`, a format name in `image_viewer`, an icon mapping in `theme`); `AvifEncoder` is never referenced. - `cargo check -p gpui` passes. - Isolated probe crate depending on image 0.25.10 alone (cold builds, Linux, 16 threads), default vs default-minus-avif: release drops from 191 to 122 CPU-seconds and 282 to 191 MB of `target/`; debug drops from 75 to 42 CPU-seconds and 549 to 342 MB. ## 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: manifest-only change) - [x] The content adheres to Zed's UI standards (n/a: no UI change) - [x] Tests cover the new/changed behavior (no behavior change; CI covers compilation) - [x] Performance impact has been considered and is acceptable (build-time improvement only) --- Release Notes: - N/A |
||
|
|
94b6d377ba |
pickers: Add multi-select support (#59931)
Users can now Cmd+click multiple files in the file picker and press Enter to open them all at once. Tab can also be used to select items without clicking, advancing the cursor automatically. # Objective Currently, when opening the file picker (Cmd+P), users can only open one file at a time. This adds multi-select support so users can select multiple files and open them all at once. Fixes #59818 ## Solution Added a `selected_indices` set to `Picker` to track which items the user has toggled into a multi-selection. Regular clicks still open a file immediately (unchanged behavior). Cmd+clicking adds a file to the selection without opening it, and pressing Enter opens all selected files at once. A `confirm_multi` method was added to the delegate trait so individual delegates (like the file finder) can handle opening multiple files with a safe fallback for delegates that don't support it. Multi-selection is cleared when the picker is dismissed or the search query changes. Selected items show a background highlight and a focused left border so the user always knows what's selected. ## How to use it 1. Open the file or test picker. 2. Search and either Cmd+click or tab it to add it to the selection (the file will not open yet). 3. Repeat for any other files you want to open. 4. To deselect a file, Cmd+click it again. 5. Alternatively, hover over an item and press Tab to select it with the keyboard, the cursor automatically moves to the next item so you can keep selecting quickly. 6. Once you have all the files you want, press Enter to open them all at once. ## Testing Tested manually on macOS. - **Single select:** Clicking on a file opens it directly, which is the existing behavior and remains unchanged. - **Multi-select via Cmd+Click:** Holding Cmd and clicking multiple items adds them to the selection. Cmd+clicking an already-selected item deselects it. Pressing Enter opens all selected files at once. - **Multi-select via Tab:** Hovering over an item and pressing Tab selects it without clicking or opening it, allowing keyboard-driven multi-selection. ## Showcase **Single select:** <img width="1512" height="982" alt="Screenshot 2026-06-25 at 6 45 33 PM" src="https://github.com/user-attachments/assets/8f9d4408-0688-4619-807a-affd6dc66f21" /> Opened single file <img width="1512" height="982" alt="Screenshot 2026-06-25 at 6 45 38 PM" src="https://github.com/user-attachments/assets/34ffacfd-b8ed-4898-beaa-bd5e47ebf682" /> - **Multi-select:** - Selecting multiple files <img width="1512" height="982" alt="Screenshot 2026-06-25 at 6 49 22 PM" src="https://github.com/user-attachments/assets/a7562fe8-9bd2-40ba-8bb4-12909ccefed7" /> Opened multiple files <img width="1512" height="982" alt="Screenshot 2026-06-25 at 6 49 42 PM" src="https://github.com/user-attachments/assets/c0c9e24c-86b7-45bf-898d-05068d5d7e3a" /> ## Release Notes: - Added multi-select to the file and text picker: Cmd+click or tab to select multiple files, then open them all at once. --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: Yara <git@yara.blue> |
||
|
Dino
|
d8ecc302c6 |
fs: Update trash crate version (#60899)
# Objective Fix errors in Windows when trashing files from the Git Panel. Closes #60716. ## Solution The solution and discussion is available at https://github.com/zed-industries/trash-rs/pull/3 , seeing as the fix was fully done on the `trash` crate. Original discussion of this issue can be found at https://github.com/zed-industries/zed/pull/59595 . ## Testing Testing was performed manually on a Windows machine by updating Zed's `fs` crate dependencies to point at the updated code and then building from source and testing out the same exact path, namely: 1. Create a new untracked file 2. Trash the file from the Git Panel's context menu 3. Confirm that, after confirming that you wish to trash the file, the file is trash and no error is shown Since this whole trash-tracking logic was implemented in the context of the project panel's undo system, I also confirmed that the changes in the crate's code didn't affect trashing and restoring on Windows. ## Self-Review Checklist: N/A ## Showcase <details> <summary>Before</summary> https://github.com/user-attachments/assets/120ab3ec-d631-4243-a21e-c510c27ed518 </details> <details> <summary>After</summary> https://github.com/user-attachments/assets/7ff1e373-b56d-431f-aad5-d4c5bb301e02 </details> --- Release Notes: - Fixed issue when trashing untracked files in Git Panel on Windows |
||
|
Vlad Ionescu
|
ad5763eba4 |
opencode: Model updates (GPT 5.6 + Grok 4.5) (#60852)
# Objective Adding newly-released OpenCode models. ## Solution **OpenCode Go**: - no changes **OpenCode Zen**: - added GPT 5.6 Luna, GPT 5.6 Terra, GPT 5.6 Sol using raw data from Models.dev repo (https://github.com/anomalyco/models.dev/tree/66dcd837fe3d7ad7e614e0a57065c5545c3c7a75/providers/opencode/models and https://github.com/anomalyco/models.dev/tree/66dcd837fe3d7ad7e614e0a57065c5545c3c7a75/models/openai) - added Grok 4.5 using raw data from Models.dev repo (https://github.com/anomalyco/models.dev/blob/66dcd837fe3d7ad7e614e0a57065c5545c3c7a75/providers/opencode/models/grok-4.5.toml and https://github.com/anomalyco/models.dev/blob/66dcd837fe3d7ad7e614e0a57065c5545c3c7a75/models/xai/grok-4.5.toml) **OpenCode Free**: - as per https://github.com/zed-industries/zed/issues/56869#issuecomment-4466637648, no changes as it's unclear what models are long-term free models ## Testing **Not tested at all**, since I don't have an OpenCode Zen subscription (since I am in the EU, I think I am also blocked from using Grok?). ## 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 N/A --- Release Notes: - Agent: OpenCode Zen model updates (added GPT 5.6 Luna, GPT 5.6 Terra, GPT 5.6 Sol, and Grok 4.5) |
||
|
|
d7c922c4a3 |
agent: Treat context window overflows as prompt-too-large errors (#60525)
Map OpenAI's context_length_exceeded errors (both the in-stream error events sent by the Responses API / ChatGPT Codex backend and HTTP 400 responses carrying the code) to LanguageModelCompletionError::PromptTooLarge. This stops pointless retries and surfaces the dedicated token-limit UI instead of a raw error string. Also record a synthetic request token usage when a completion fails with PromptTooLarge, so the context indicator reports Exceeded rather than the stale usage of the last successful request, and the next prompt qualifies for auto-compaction. Ought to help a bit with https://github.com/zed-industries/zed/issues/59600 Release Notes: - N/A or Added/Fixed/Improved ... --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com> |
||
|
Lukas Wirthandzed-zippy[bot]
|
905e955a70 |
gpui: Implement window attention (#58779)
Release Notes: - On agent notifications, the corresponding zed window will now mark itself for OS level attention --------- Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com> |
||
|
Apoorva VermaandKirill Bulatov
|
1c5b2b815b |
Use buffer line numbers when copying file locations (#60781)
# Objective Fixes #54250 `editor: copy file location` copies the row you're on in the multi-buffer, not the row in the actual file. In a git diff view with collapsed lines it copies the wrong line number. ## Solution It read the rows straight off the selection, which is in multi-buffer coordinates. `ClipboardSelection::for_buffer` already handles this with `range_to_buffer_range`, so I used the same thing. Path and line now come from the same buffer. `range_to_buffer_range` returns nothing when the selection ends in a different buffer than it starts in, which you can do in a git diff view. Rather than copy nothing, it falls back to the cursor's buffer. ## Testing Three tests: a multi-buffer excerpt, a selection dragged across two files, and a plain single-file editor. The multi-buffer ones fail on main; the singleton one passes either way, so normal editors are unaffected. ## 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 `editor: copy file location` copying the wrong line number in multibuffers ([#54250](https://github.com/zed-industries/zed/issues/54250)). --------- Co-authored-by: Kirill Bulatov <kirill@zed.dev> |
||
|
HuaGu-Dragon
|
a12ed0fbaf |
vim: Remap cursor position with display_point (#60755)
# Objective - Fixes #53650 - Possibly also fixes #57956 (needs confirmation) ## Solution - Replace the direct `DisplayPoint::new(row, col)` construction with a proper buffer-point-to-display-point - This goes through the full inlay → fold → tab → wrap → block pipeline and correctly accounts for any inlay hints on the target line. ## Testing - Added a regression test for multi-cursors with inlay hints in helix mode ## 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 `Shift+C cursor` position with inlay hints in helix mode |
||
|
Richard Feldman
|
89e8a4b9ec |
gpui_windows: Harden DirectWrite and DirectX text rendering (#60124)
This hardens the Windows text rendering path in gpui_windows against undefined behavior and out-of-bounds access. DirectWrite hands back glyph-run arrays (glyph indices, advances, offsets) and cluster maps as raw pointers that may be null; these are now interpreted through a shared `slice_from_nullable` helper that treats a null pointer with zero length as an empty slice and returns `E_INVALIDARG` when a null pointer arrives with a nonzero length, instead of constructing a slice from a null pointer. It also fixes a provenance bug: the renderer context passed to `IDWriteTextLayout::Draw` was derived via `&raw const` from a non-mut binding, but the `DrawGlyphRun` callback recovers that pointer and writes through it, which is undefined behavior under Stacked/Tree Borrows; the binding is now `mut` and the pointer is derived from `&raw mut` so its provenance matches the write (codegen is unchanged). On the DirectX side, the atlas upload is now bounded by the source slice length so a mismatched destination region cannot read past the end of the source, and the color-glyph staging texture is unmapped after readback so the mapping is no longer leaked and the resource pinned. The color-glyph rasterizer drives the shared, non-thread-safe D3D11 immediate context that `DirectXRenderer` and `DirectXAtlas` also use, so it must stay on the main UI thread — which it always is today; a comment documents that invariant. Since gpui_windows is a Windows-only crate, it cannot be compiled on non-Windows hosts, so Windows CI is the compile gate for these changes. Release Notes: - N/A |
||
|
Khôi TranandSmit Barmase
|
715557fe51 |
editor: Add support for pasting images in Markdown (#58588)
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 #18112 Release Notes: - Added support for pasting images from clipboard into Markdown files --------- Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com> |
||
|
Apoorva Verma
|
aeeacf5439 |
Indent statements under C/C++ case labels (#60758)
# Objective Fixes #60261 Nothing under a `case` gets indented in C or C++, and the next `case` doesn't come back out. It stays flat until you hit `editor: format`. ## Solution The indent queries had no rule for case labels. Added the same pair `cpp/indents.scm` uses for `access_specifier`: open an indent range at the label, close it at the switch's `}`, outdent on the next label. The part that got me: `@start` uses the *end* of the node you capture. Fine for `access_specifier`, which is just `public:`. But a `case_statement` swallows the statements under it, so capturing the node starts the range after the last one. Capture the `:` instead. `default:` is a `case_statement` too, so it comes along free. Only affects what happens after a label, so existing `case` alignment doesn't move. ## Testing `test_c_autoindent_switch_case` and `test_cpp_autoindent_switch_case` cover a plain case, fall-through labels and `default`. Both fail on main. The `access_specifier` tests still pass. Not mine, but worth knowing: `typescript::tests::test_outline` and `test_generator_function_outline` are flaky on main, failing about half my full `cargo test -p languages --lib` runs with or without 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 Release Notes: - Fixed statements under a `case` label not being indented in C and C++ ([#60261](https://github.com/zed-industries/zed/issues/60261)). |
||
|
Remco Smits
|
23bb2fc135 |
macos: Fix window move controls are disabled (#60620)
Closes https://github.com/zed-industries/zed/issues/60595 cc Anthony-Eid since you did an initial pass on this. # Objective Currenly on macOs there is no way right now after the following regression to use window management short keys to move them around. This worked before, but was regressed initially in https://github.com/zed-industries/zed/pull/59836 that tried fixing a macos 27 clicking delay issue on the titlebar. That accidentally set the `native_window.setMovable_(is_movable as BOOL)` to false. Because of this mocos detects this and disables the window managements actions because it thinks the window can/should not be able to move. ## Solution The macOS 27 click delay actually comes from AppKit's native titlebar dragging, not from `NSWindow.isMovable`. The problem is that `is_movable` is also what enables the Window menu's tiling options, and #59836 used it to turn off dragging, which disabled the tiling menu as a side effect. To fix this, I restored `is_movable` to its real meaning so the tiling menu works again, and added a separate `WindowOptions::app_owns_titlebar_drag` flag for windows that draw their own titlebar and handle dragging via `Window::start_window_move`. On macOS this tells AppKit to stop owning titlebar drags (removing the click delay) without affecting `is_movable`. Zed's main window now sets both `is_movable: true` and `app_owns_titlebar_drag: true`, so the tiling menu stays enabled, the click delay is gone. I also added a `window_movable` gpui example to make this behavior easy to test manually. ## Testing I added a gpui test example that helps testing this bug. You can run the newly added gpui example with 4 different window configurations that should confirm that this change is the right one for all of the window types that we have. ## 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 **After** (note this now shows the window managements entries as they were greyed out.) https://github.com/user-attachments/assets/192cc0e1-15d8-486f-b788-a92bb51fb7d1 **GPUI** (test examples with different window configurations.) https://github.com/user-attachments/assets/c9e0f4d3-606b-4cd7-b4d8-a5bb16508164 --- Release Notes: - Fix macos window management controlls were grayed out/not working |
||
|
feeiyu
|
5d8459eed6 |
Improve JS/TS/TSX parameter highlighting for destructuring (#60767)
# Objective Fixes #51967 Destructured JS/TS/TSX parameters with defaults were not highlighted consistently as parameters when using themes that distinguish arguments from variables/properties, such as Catppuccin. For example, in: ```js function a({ argument = true }) {} ``` `argument` was parsed under a default assignment pattern and did not receive the same `@variable.parameter` capture as a destructured parameter without a default. This also affected array binding patterns with defaults, such as: ```js function b([argument = true]) {} ``` ## Solution Updated the JS/TS/TSX highlight queries to capture destructured parameters with default values as `@variable.parameter`. This covers both: - Object binding patterns with defaults, such as `{ argument = true }` - Array binding patterns with defaults, such as `[argument = true]` As a result, destructured parameters are highlighted consistently whether or not they provide a default value. ## Testing - Verified the highlight query changes for JavaScript/TypeScript destructured parameters with defaults. - Tested examples include: ```js function a({ argument }) {} function a({ argument = true }) {} function a({ argument = true }?) {} //optional function b([argument]) {} function b([argument = true]) {} function b([argument = true]?) {} // optional ``` - These cases should be easiest to visually confirm with a theme that distinguishes parameters from variables/properties, such as Catppuccin. ## 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 Before this change, <img width="1600" height="332" alt="图片" src="https://github.com/user-attachments/assets/fbacb22b-f0e4-490d-8f94-6059e66d3ae0" /> After this change: <img width="1599" height="353" alt="图片" src="https://github.com/user-attachments/assets/3eae692b-391e-4c53-9925-1ca2f5774038" /> Release Notes: - Fixed inconsistent syntax highlighting for JS/TS/TSX destructured parameters with default values. |
||
|
Vitaly Slobodin
|
55242071f1 |
search: Fix ignored file search in nested Git directories (#60772)
# Objective - Fix ignored file search in nested Git directories (even just empty `.git` directories, not real git repositories) - Fixes #52328 ## Solution Keep parent ignore rules when rebuilding a nested repository's ignore stack. This hides root-ignored files again after excluded-file search is turned off, without breaking global ignore handling. For example: ```ascii project/ ├── .git/ ├── .gitignore # log/ ├── app/ │ └── a.txt # hello └── log/ ├── .git/ # nested repository marker └── b.txt # hello ``` Both `a.txt` and `b.txt` have string `hello`. Initially, searching for `hello` returns only `a.txt`. Enabling `Also search files ignored by configuration` rescans `log/` and returns both files. Before this change, disabling the option still returned both files because the rescan dropped the parent `.gitignore` and marked `b.txt` as included. ## Testing - Did you test these changes? If so, how? To test changes in this pull request create a simple project with the following dir structure: ``` .git .gitignore a/a.txt b/b.txt b/.git # this is an empty directory ``` Add `b` folder as an ignore entry to the `.gitignore` file: `b/` - 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? Use the test scenario above - If relevant, what platforms did you test these changes on, and are there any important ones you can't test? 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 ## Showcase By using the structure above here is how it works before changes here: https://github.com/user-attachments/assets/2028123e-388e-4390-b131-ddf4642ab5f3 Notice that `hello` string from file `b.txt` is listed in search results regardless of the option `Include excluded files` And here is after: https://github.com/user-attachments/assets/99c627a2-e16a-4fdd-979b-2e0bacbd827d Notice that `hello` string from file `b.txt` is **not** listed in search results when the option `Include excluded files` is disabled. Release Notes: - Fixed ignored file search in nested Git directories |
||
|
Vitaly Slobodin
|
8c4550cb95 |
node_runtime: Fix npm v12 output deserialization (#60798)
# Objective - Fix npm v12 output deserialization - Fixes #60705 ## Solution Initially I was thinking about checking the `npm` version and then parsing its output accordingly but that would include a call to `npm --version`. Zed's mojo is to be blazingly fast so just checking the structure of the output should be enough: 1. `npm info --json` in v12 produces an array with 1 object: `[ { "name": "something" } ]` 2. `npm info --json` in v11 and older produces an object: `{ "name": "something" }` So the trick is to check the output: if it's an array, we have npm v12, otherwise npm v11. ## Testing - Did you test these changes? If so, how? 1. Ensure you have `npm` v12 installed. 2. Install a Node.js based language server, for example, `markdownlint` or `oxfmt` 3. Open a project and trigger start of a language server - 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? Use steps above - If relevant, what platforms did you test these changes on, and are there any important ones you can't test? I've tested this on macOS and Linux. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] 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 N/A --- Release Notes: - Fixed npm v12 output deserialization |
||
|
Nils Petersohn
|
5b7b970d08 |
feature: toggle markdown preview and source (#60867)
Toggle Markdown Preview with the Existing Preview Shortcut ## Context Markdown files already expose actions for opening a rendered preview in the current pane or to the side. The current-pane preview action focuses the preview, but there was no matching keyboard path from the preview back to the source editor. Users expect the existing preview shortcut to behave like a mode toggle: press it from the editor to preview, then press it again from the preview to return to editing. The existing preview view keeps a handle to its source editor, so the preview can return focus to that editor without adding a broader workspace-level toggle. ## Feature Add a markdown-preview-scoped action, `markdown::CloseAndReturnToEditor`, and bind the existing preview shortcut to complementary actions: - In a markdown editor, `ctrl-shift-v` on Linux and Windows, or `cmd-shift-v` on macOS, dispatches `markdown::OpenPreview`. - In a markdown preview, the same platform shortcut dispatches `markdown::CloseAndReturnToEditor`. The close action first activates and focuses the source editor. If the source editor entity is no longer open in any pane, the action adds it back to the active pane before closing the preview. The preview is closed with `SaveIntent::Skip` because the preview is not the owner of source-buffer changes. Existing markdown preview shortcuts remain available. ## Alternatives - Bind `escape` to close the preview. This is easy to discover, but it does not provide a symmetric editor/preview toggle and can overlap with transient UI such as search. - Add a new dedicated toggle chord, such as `ctrl-alt-v` / `cmd-alt-v`. This avoids changing the preview shortcut's meaning in the preview context, but it makes users learn a second shortcut for the same preview/edit workflow. - Teach `markdown::OpenPreview` to toggle based on the active item. That would mix editor-scoped preview creation with preview-scoped close behavior and make the action depend on more workspace state. ## Consequences - The toggle behavior is implemented by context-specific keybindings rather than one action that changes meaning globally. - Returning to edit mode works even when the original editor tab has been closed while the preview remains open. - The preview close path has focused GPUI tests because it relies on pane activation, focus restoration, and asynchronous item closing. Release Notes: - Add a markdown action to close the current preview and focus the related source file |
||
|
Finn Eitreim
|
c343997ca8 |
settings_ui: Shrink constraint on minimum window width (#60786)
# Objective Right now the minimum width of the settings window is 900px, this makes it so that when I open it with my window manager (aerospace), it goes off the screen on the right side. https://github.com/user-attachments/assets/e47c1f13-0b5c-49e1-9a1e-4d3b494eca8d ## Solution There is a comment, that says: ``` // Don't make the settings window thinner than this, // otherwise, it gets unusable. Users with smaller res monitors // can customize the height, but not the width. width: px(900.0), height: px(240.0), ``` the comment and limit was added in #44505, which added the edit prediction provider ui. Now in the past, in #51878 I fixed a bug with the way that the edit prediction provider and some of the other sub menu type pages in the settings menu displayed. There isn't really any record of what specifically made the window unusable below 900px besides the issue that I fixed in #51878. ## Testing I tested it by just sort of poking around the different settings pages, especially the ones I fixed in #51878, and every thing seems totally fine to me. That said I haven't exhaustively checked every page and if there was any more information on what that comment was referring to that would be awesome. ## 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 How it looks after the change: https://github.com/user-attachments/assets/9258f51f-5da5-4f4c-997d-7f09a3448e4b --- Release Notes: - settings_ui: Allowed window widths below 900px |
||
|
Apoorva Verma
|
869d6eae22 |
language: Autoclose nested brackets in plain text (#60841)
in a plain text file, cursor before a closing bracket, type an opening one and nothing autocloses. `anything|)` + `[` gives `anything[|)` not `anything[]|)`. fine in js/css/py. autoclose checks the language's `autoclose_before` set. every language sets one, plain text didn't, so a closing bracket ahead of the cursor killed it. gave it `)]}`. went `)]}` not the usual `;:.,=}])>` since plain text only has brackets. `.typ` (Typst) is a separate extension, needs the same fix there. Fixes #60560. Release Notes: - Fixed nested brackets not auto-closing in plain text files |
||
|
feeiyu
|
8c29f9e2ec |
Fix double-click text selection and tab bar flicker in Markdown preview (#60817)
# Objective Fixes #60812 Previously, double-clicking in the preview updated the source editor selection/cursor position, moved focus to the source editor, and stopped the event from propagating. This prevented normal text selection in the preview. When the source editor was in the same pane but not the active tab, focus was then restored back to the preview, causing the tab/tab bar to flicker. ## Solution Update the source editor selection/cursor position on single-click instead of double-click, while keeping focus in the Markdown preview. This leaves double-click behavior available for normal text selection in the preview. - This approach keeps Markdown preview interactions consistent with common text behavior: double-clicking text should select the word/text under the cursor.. - The source editor selection/cursor position is still updated on single-click so the preview can continue to keep the source editor in sync with the location the user is inspecting. ## Testing Manually tested the Markdown preview click behavior. I also tried adding a regression test using `simulate_event` to simulate mouse events, but I could not find a reliable API for locating the rendered text position inside the Markdown preview. Because of that, this was validated manually. Manual test steps: 1. Open a Markdown file. 2. Open the Markdown preview for that file. 3. Keep the source editor and Markdown preview as separate tabs in the same pane. 4. Activate the Markdown preview tab. 5. Single-click text in the Markdown preview. - Confirm the source editor selection/cursor position is updated. - Confirm focus remains in the Markdown preview. - Confirm the tab bar does not flicker. 6. Double-click text in the Markdown preview. - Confirm the text in the preview is selected. - Confirm focus remains in the Markdown preview. - Confirm the tab bar does not flicker. ## 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 after change: [录屏 2026-07-11 23-44-16.webm](https://github.com/user-attachments/assets/616d1ed3-5802-402f-8499-4864b149c550) --- Release Notes: - Fixed double-click text selection and tab bar flicker in Markdown preview. |
||
|
Sathwik Chirivelli
|
94597a97cb |
git_ui: Add branch picker filter menu (#60857)
# Objective Make branch filtering consistent and more flexible across the title bar and Git panel branch pickers. ## Solution - Replace the remote-only filter toggle with a dropdown for all, local, and remote branches. - Preserve the selected filter across branch picker instances. - Add a ListFilter icon and active-filter indicator. - Prevent nested filter-menu interactions from dismissing the parent picker. - Cycle through all, local, and remote filters with the existing keyboard shortcut. ## Testing - Ran `cargo check -p git_ui --tests --no-default-features`. - Verified formatting with `cargo fmt -p git_ui`. - Manually checked the filter dropdown from the title bar and Git panel. ## 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 - Filters: All, Local, Remote - "Cmd + Shift + I" to cycle over the filters <details> <summary>New Branch Picker Filter Dropdown</summary> <img width="1624" height="1030" alt="Screenshot 2026-07-12 at 3 53 30 PM" src="https://github.com/user-attachments/assets/1323d9c9-f4b9-41ee-ba93-841299872c02" /> <img width="1624" height="1030" alt="Screenshot 2026-07-12 at 3 54 35 PM" src="https://github.com/user-attachments/assets/839345ff-de3b-48f0-b4e7-0f8d27e94204" /> </details> Release Notes: - Improved branch filtering with local, remote, and all-branch options in the branch picker. |
||
|
Pavel Olizko
|
22116632f7 |
git_ui: Sanitize file names before rendering (#60862)
# Objective `GitPanel::entry_label` builds file-name labels directly from `git status` output without calling `.single_line()`. A raw newline in a file name splits its row across multiple visual lines in the Changes panel. ## Solution - Add the missing `.single_line()` call in `entry_label`, matching the behavior in `project_panel.rs`. ## Testing - Created a git repo with an untracked file whose name contains a literal newline byte and confirmed the Changes panel now renders it on one line, collapsing the newline to `⏎` like the project panel already does. ## 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 - [ ] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable # Showcase Before: <img width="441" height="216" alt="image" src="https://github.com/user-attachments/assets/921e5aad-01f9-49fd-89b1-f7270e2d203c" /> After: <img width="447" height="206" alt="image" src="https://github.com/user-attachments/assets/1c09af36-ccf1-434a-be20-0ea2c5d232d5" /> Release Notes: - Fixed file names containing newlines rendering across multiple lines in the Git Panel. |
||
|
Eagl61
|
ca0b3c92d7 |
git: Show submodule changes in commit diffs (#60479)
## Objective Fix Git Graph showing `0 Changed Files` for commits that modify submodules. This happened because submodule entries are gitlinks rather than regular blobs, so the existing commit diff loading path could not resolve them correctly. I ran into this issue previously, and it was confusing because the commit clearly contained changes, but the UI did not reflect them. If a commit included many file changes plus a submodule update, the submodule change was effectively hidden and the UI could still show `0 Changed Files` for that entry. Since submodules are not used in every repository, the bug is easy to miss and may go unnoticed for a long time. ## Solution - Switched commit diff loading to use Git's raw diff output so submodule entries are represented explicitly. - Added parsing for gitlink entries alongside regular file changes. - Render submodule changes as `Subproject commit <oid>` so they show up in commit diffs instead of being dropped. ## Testing - Added a repository test covering commit diffs that include submodule changes. - Ran the `git` crate test suite. - Ran formatting and lint checks. - Verified the Git UI crate still builds. - Ran and tested it locally on MacOS. Reviewer notes: - The change is limited to commit diff loading and should not affect normal blob diffs. - Submodule changes now appear as explicit entries instead of being counted as zero files. ## 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: <img width="200" alt="Screenshot 2026-07-06 at 19 22 57" src="https://github.com/user-attachments/assets/16efc348-5909-4cb0-8589-b0662923df56" /> After: <img width="200" alt="Screenshot 2026-07-06 at 20 20 11" src="https://github.com/user-attachments/assets/3201b264-6e61-45de-a9fc-c585f3b54e09" /> <img width="200" alt="Screenshot 2026-07-06 at 20 37 57" src="https://github.com/user-attachments/assets/182ed4e1-9e90-4e33-9136-7626aba31153" /> --- Release Notes: - Fixed Git Graph showing `0 Changed Files` for commits that update submodules. |
||
|
Yifeng Xuandpeakxy
|
08359123ac |
Fix “Open file in project" option in the right-click menu not working (#60807)
# Objective Fix file header context menu actions in multi-file Git history diffs. Previously, `Open File in Project` worked for the first file but did nothing for subsequent files. Fixes #60790 ## Solution Include the buffer ID in each file header context menu's GPUI element ID. This prevents multiple file headers in split diff views from sharing the same menu state. ## Testing - Ran `cargo check -p editor --lib`. - Ran `cargo fmt --package editor -- --check`. - Reviewers can test by opening a multi-file commit from Git Panel → History in split diff mode, then using `Open File in Project` on the second and subsequent file headers. https://github.com/user-attachments/assets/46fa4e15-60ac-4ae3-9a73-a89c7f107cb0 ## 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 opening project files from context menus in multi-file Git history diffs. Co-authored-by: peakxy <2465549609@qq.com> |
||
|
Pranav NedungadiandChristopher Biscardi
|
60099a06df |
git_ui: Add restore buttons to unstaged diff view (#60639)
The unstaged diff view introduced in the partially staged changes commit only had a Stage button but no Restore option. This adds: - A per-hunk Restore button in the inline hunk controls (disabled for new files) - A Restore button in the toolbar for selected hunks - A Restore All button in the toolbar to discard all unstaged changes - A restore method override on UnstagedDiffDelegate for the Restore action Release Notes: - Added restore buttons to the unstaged diff view for discarding unstaged changes. # Objective New unstaged and staged diffs were added in #46541 . However for unstaged changes, only option available is to stage a change. It would also be a common use case to restore the changes. (Like how it is done in uncommitted changes). ## Solution - A per-hunk Restore button in the inline hunk controls (disabled for new files) - A Restore button in the toolbar for selected hunks - A Restore All button in the toolbar to discard all unstaged changes - A restore method override on UnstagedDiffDelegate for the Restore action ## Testing Tested in locally and ensured both features work ## Self-Review Checklist: - [ ] I've reviewed my own diff for quality, security, and reliability - [ ] Unsafe blocks (if any) have justifying comments - [ ] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [ ] Tests cover the new/changed behavior - [ ] Performance impact has been considered and is acceptable ## Showcase <img width="1141" height="635" alt="Screenshot 2026-07-09 at 9 00 47 AM" src="https://github.com/user-attachments/assets/b1d3f091-9f1d-49c6-87e6-9efad25e62dd" /> ## Note I am still learning rust bit by bit. Please let me know if something is massively wrong. This is assisted by AI but reviewed by me with best of my knowledge. --- Release Notes: - Added restore buttons to the unstaged diff view for discarding unstaged changes. --------- Signed-off-by: Pranav <pranav10121@gmail.com> Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com> |
||
|
Mikayla Makiandzed-zippy[bot]
|
49ad06c1b4 |
gpui: Add container_query element (#60774)
Adds a `container_query` element to GPUI, in the spirit of CSS container
queries: the element's own size is determined solely by its style and
the space offered by its parent, and once that size is known the
provided closure is called with the measured size to build the contents.
```rust
container_query(|size, _window, _cx| {
if size.width < px(240.) {
div().child("Narrow layout")
} else {
div().child("Wide layout")
}
});
```
Implementation notes:
- Defaults to filling its parent (`size_full()` semantics), overridable
via `Styled` since contents can't influence the container's size (the
same constraint CSS container queries impose).
- Reworks the `grid_layout` example (the Holy Grail layout) to
demonstrate it: the three-column grid collapses to a stacked column when
the window is narrower than 400px, and the header shows the live
measured width.
Release Notes:
- N/A
---------
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
|
||
|
Mikayla Makiandzed-zippy[bot]
|
b0da438545 |
gpui: Fill auto-sized window roots to the viewport (#60739)
Window roots whose size is `auto` now stretch to fill the window, the way the root element on the web fills the initial containing block. Previously a window root with no explicit size shrink-wrapped its content (flex/grid roots collapsed to content size in both axes), which is why every root view needed `size_full()`. Mechanically: `draw_roots` requests layout for the window root (and prompt roots), then `TaffyLayoutEngine::stretch_auto_size_to_fill` rewrites any `auto` dimension on the root node to the viewport size before layout runs. Explicitly styled root dimensions are preserved, and tooltips, drags, and anchored/deferred draws keep their shrink-wrap semantics. Includes regression tests covering both the auto-fill and explicit-size cases (the auto case collapses to 0×0 without the fix). Release Notes: - N/A --------- Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com> |
||
|
Mikayla Maki
|
9c3273201c |
gpui: Add mobile/touch API surface (#60496)
TODO: - [ ] Remove slop comments - [ ] Review APIs in detail # Objective - This PR aims to add official mobile API surfaces to GPUI ## Solution - This PR cross references several internal experiments to come up with a general cross-platform abstraction for core input mechanisms, but defers actual implementations to later. These are intended to be a common base to build off of. ## Testing - Yes, as mentioned above with external experiments ## 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: - N/A |
||
|
Bing WangandNathan Sobo
|
df37766060 |
terminal: Fix terminal jitter on resize (#56715)
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 #55934 Release Notes: - Fixed terminal jitter when resizing vertically with content that doesn't fill the available height. --------- Co-authored-by: Nathan Sobo <nathan@zed.dev> |
||
|
Sathwik ChirivelliandChristopher Biscardi
|
65e1c5af25 |
git_panel: Add group by staging view option (#59884)
# Objective - Add a view option for group by staging. ## Solution - Add a new option for group_by under git_panel view options, with 2 sections "Staged" and "Unstaged", with buttons (+/-) to stage and unstage ## Testing - cargo check -p git_ui ## 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="1679" height="1140" alt="Screenshot 2026-06-25 at 2 09 44 PM" src="https://github.com/user-attachments/assets/1b605cad-7792-4823-983c-ada41be25504" /> --- Release Notes: - Added group by staging view option --------- Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com> |
||
|
Eli Stark
|
bc99075373 |
Guard OpenCode bell plugin in ACP mode (#60507)
## Summary - Add an ACP-mode guard to the documented OpenCode bell plugin snippet - Preserve terminal bell notifications for Terminal Threads while avoiding writes to stdout when OpenCode is used as an ACP External Agent ## Rationale The OpenCode bell plugin writes BEL to stdout for Terminal Thread notifications. When the plugin is installed globally and OpenCode runs in ACP mode, stdout is the JSON-RPC transport. OpenCode sets `OPENCODE_CLIENT=acp` in this mode, so the guard prevents BEL bytes from corrupting ACP JSON-RPC messages, including usage updates and permission flows. Release Notes: - N/A |