255880598d46c5cc299b9d762dbc4e619002af03
39612
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Neel
|
255880598d |
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> |
||
|
Josh Ellithorpe
|
0b5de324a4 |
gpui_linux: Clear X11 urgency hint when the window becomes active (#61619)
# Objective
On X11, GPUI raises the ICCCM `WM_HINTS` urgency flag to ask for
attention, but
it never clears it. The window stays urgent for the rest of its life.
`request_attention` was the only thing touching the bit. There was no
code
anywhere to clear it.
Docks and taskbars latch on the rising edge, so they show the attention
state
once and then sit there with a permanent urgent indicator, no further
notifications.
## Solution
Clear the flag when the window becomes active.
The read/modify/write moves out of `request_attention` into a helper,
`set_wm_hints_urgency(xcb, x_window, urgent)`. The raise and clear sites
are on
different self types (`X11Window` vs `X11WindowStatePtr`), so it takes
the
connection and window id.
The clear goes in `set_wm_properties`, where `state.active` gets set
from
`_NET_WM_STATE_FOCUSED`. That's the same field `request_attention`
already checks
in its `if self.is_active() { return; }` guard.
Two implementation notes:
* The clear is edge triggered (`state.active && !was_active`).
`set_wm_properties` recomputes everything on every `_NET_WM_STATE`
change, so a
level triggered check would do a blocking `WmHints::get` round trip on
every
maximize, fullscreen, hide and workspace switch while focused. Edge
triggering
is safe here because `request_attention` early returns when active, so
urgency
only ever gets raised while inactive, and the false to true transition
always
follows a raise.
* Clearing reads the hints first and skips the write if the bit isn't
set.
Otherwise focusing a window that never asked for attention would create
a
`WM_HINTS` property just to say "not urgent".
The raise path behaves exactly as before. The skip can't fire when
`urgent` is
true, so repeat raises still write every time.
Focusing clears the flag even if a second thread is still waiting.
That's already
how it works, since `request_attention` early returns when the window is
active.
## Testing
Tested on X11, Cinnamon with Muffin.
On an unpatched build the window had `_NET_WM_STATE_FOCUSED` and the
urgency bit
set at the same time.
W=$(xdotool search --class "dev.zed.Zed" | head -1)
xprop -id $W WM_HINTS
xprop -spy -id $W WM_HINTS
1. Fresh window says `WM_HINTS: not found`, and still does after
focusing it.
2. With focus on another window, the urgency bit shows up when attention
is
requested. `request_attention` early returns when active, so the window
has to
be unfocused for this to fire.
3. Focusing Zed clears the bit.
4. Repeating 2 and 3 re-arms it every cycle, not just once.
5. No `WM_HINTS` writes during normal use (resize, maximize, workspace
switch).
No automated test. It's an X11 round trip on a real window and there's
no X11
test harness in the tree.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments (none added)
- [x] The content adheres to Zed's UI standards (no UI change)
- [x] Tests cover the new/changed behavior (see Testing)
- [x] Performance impact has been considered and is acceptable
Note this was manually tested, there wasn't a good way to test it
through the current harness.
---
Release Notes:
- Fixed the X11 urgency hint never being cleared, which left Zed showing
a permanent attention indicator in taskbars and docks after the first
notification
|
||
|
Ali
|
b25370b285 |
worktree: Yield during large file decoding (#62831)
# Objective Closing a project while a large local text file is loading can be delayed because file-reading and UTF-8 streaming loops have no await points. Partially addresses #27283. ## Solution Yield between 1 MiB blocks while: - streaming UTF-8 files into a Rope - reading files handled by the fallback decoder, including BOM, UTF-16, and other non-UTF-8 encodings Release Notes: - Improved responsiveness when closing projects that are loading large text files. |
||
|
Xiaobo Liu
|
cdf77380fe |
zed: Support IPv6 hosts in SCP-style SSH URLs (#62157)
# Objective - Support opening remote paths from SCP-style SSH URLs that use bracketed IPv6 hosts, such as `ssh://[2600::]:~/foo`. ## Solution - Validate SSH hosts with `url::Host::parse`, which supports bracketed IPv6 addresses while continuing to reject malformed or ambiguous hosts. - Add test coverage for IPv6 URLs with usernames, home-relative paths, absolute paths, and explicit ports. - Add rejection tests for unbracketed IPv6 addresses and ambiguous port-plus-SCP-path syntax. ## Testing - Ran `cargo fmt --all -- --check`. - Ran `cargo test -p zed test_parse_ssh_urls -- --nocapture`. - Ran `cargo test -p zed test_reject_ssh_urls -- --nocapture`. - All targeted tests passed on macOS. No additional platform-specific testing is expected to be necessary because the change only affects URL parsing. Release Notes: - Fixed opening remote paths from SCP-style SSH URLs with IPv6 hosts. Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com> |
||
|
Andrej730andKunall Banerjee
|
e7a151de09 |
keymaps: Sync debugger bindings across platforms to match VS Code (#58729)
I was trying out zed after VS Code and I've stumbled upon inconsistency with debugging hotkeys. In VS Code it's f10/f11, in zed it was much more awkward f7/ctrl-f11. Investigating, I've found that I can't just override f11, because it's used by `zed::ToggleFullScreen` global hotkey and global hotkey always beats `Workspace && debugger_stopped`. Furthermore, I've found f11 hotkey is available, but only on Mac. And on Windows there was no `StepInto` hotkey at all. So configs were unsynced in that regard. Code changes: - To make f11 overridable, I've moved it to `Workspace` context - it's still pretty global, but now it's overridable. Though `Workspace && debugger_stopped` have the same depth as `Workspace`, it will take priority, because it's registered later in .json. - StepInto - added f11 hotkey for all platforms (was missing on linux and windows), kept older ctrl-f11 too as some users might be used to it. A note that on Mac F11 was added previously as `Workspace && debugger_running` - which practically means the hotkey wasn't available. `debugger_running` means debugger is running in background, user needs step commands when `debugger_stopped`- when they're actually stepping through the code. - StepOver - added f10 hotkey for all platforms (was missing on linux and mac). Kept old f7 hotkey on linux and mac, didn't added it on windows as it wasn't present before. - StepOut - it was consistently shift-f11 on all platforms already, just moved it from global context for consistency. - Removed StepOver, StepInto, StepOut from debugger_session context and kept it only in `debugger_stopped`, as this is when they're actually useful, similar to how we have `debugger::Continue"` there which also makes sense only when debugger is stopped. I've separated changes by commits, so it would be easier to review them. PS Global hotkeys overriding specific ones seems a bit odd by itself - it seems global more specific hotkeys should always have a priority, so maybe it's something to look into too. Another thing that `default-xxx.json` share a lot of hotkeys, so maintaining them separately may have other things going out of sync too. Closes #58899. ---- Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [ ] Tests cover the new/changed behavior - keymaps are not tested - [x] Performance impact has been considered and is acceptable Release Notes: - Improved debugger step keybindings across platforms to match VS Code defaults while preserving fullscreen outside paused sessions --------- Co-authored-by: Kunall Banerjee <hey@kimchiii.space> |
||
|
Finn Evers
|
942416d366 |
ci: Acquire ts_query_ls using the gh CLI instead (#62900)
Release Notes: - N/A |
||
|
Gary GuoandKirill Bulatov
|
d93155db61 |
terminal: Fix support for alt-f5 and add support for ctrl-alt-key (#62891)
# Objective - Fix support for alt-f5 in terminal and add support for ctrl-alt-key ## Solution - Fix `crates/terminal/src/mappings/keys.rs`. ## Testing - Did you test these changes? If so, how? Added a unit test, and test the built zed with fish_key_reader to check that the keys are indeed recognized. - 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? Fish has fish_key_reader which can check the keys that it recognizes. Not sure about other shells. `cat | xxd` can be used to confirm the exact received key codes. - If relevant, what platforms did you test these changes on, and are there any important ones you can't test? Tested on Linux only. ## 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: - In terminal, "alt-f5" keystroke support is fixed and "ctrl-alt-key" support is added for letter keys. --------- Signed-off-by: Gary Guo <gary@garyguo.net> Co-authored-by: Kirill Bulatov <kirill@zed.dev> |
||
|
Torbjørn LiumandFinn Evers
|
611301feb3 |
Add Python runnable for __name__ in ("__main__",) pattern (#58911)
The gutter run button for Python's main guard only appears for `if
__name__ == "__main__":` but not for the alternative membership test
pattern `if __name__ in ("__main__", "__builtin__", "builtins"):`.
This adds a second Tree-sitter query in `runnables.scm` that matches the
`in` variant. It emits the same `python-module-main-method` tag, so both
patterns get the same gutter icon and task 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 (No dedicated tests for the
Python runnables queries exist. The build passes cleanly)
- [x] Performance impact has been considered and is acceptable
Closes #58909
Release Notes:
- Fixed Python run button not appearing in the gutter for `if __name__
in ("__main__", ...)` style main guards.
Co-authored-by: Finn Evers <finn@zed.dev>
|
||
|
Nikita Demin
|
459fe185a4 |
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. |
||
|
Enzo GAZZOLIandKirill Bulatov
|
1155a5becd |
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> |
||
|
Nguyen Anh Tu (Elior)andKirill Bulatov
|
9bafb64cb5 |
Add debugger.scm for C and C++ to enable inline values (#46705)
Closes #46522 Release Notes: - Added inline values support for C and C++ when debugging with CodeLLDB or GDB --------- Co-authored-by: Kirill Bulatov <kirill@zed.dev> |
||
|
Anthony Eid
|
b559ad4f26 |
gpui: Journal foreground work between frames and report hang incidents (#62779)
Zed's hang telemetry could say a hang happened, but not what the app was doing. This PR adds a foreground journal to gpui (behind the `profiler` feature): the main thread records task polls, action handlers, input dispatches, window draws, and frame presentations into a fixed-size ring, and boundary entries — a newly drawn frame's presentation, or the foreground going idle — partition that stream into activity intervals. Recording is designed to be cheap enough to ship enabled: sub-threshold task polls fold into a counter instead of individual entries, and the ring is drained in bounded chunks off the main thread. A `HangDetector` drains the journal and reports an incident for any interval containing a single event at or above the hang threshold (100ms in release), or whose cumulative foreground spend reaches a frame budget (8ms in release) — catching both one long stall and many small pieces of work that together drop a frame. Incidents serialize with phase (startup/steady), stall and active durations, busy fraction, dirty-to-present time, and up to 8 contributors in start order with nesting depth: task polls carry their spawn location, actions their names, inputs their kind. Zed batches the top 10 incidents by stall per 30 minutes plus a total incident count into a "Hang Incidents" telemetry event, flushes the remainder on quit, and drops the old per-location "Hang Report" histograms this replaces. Release Notes: - N/A |
||
|
Agus Zubiaga
|
7c46498fe8 |
gpui: Add split and paint APIs on LineLayout (#60831)
`ShapedLine` is nearly 3KB by value because it inlines a `SmallVec<[DecorationRun; 32]>`. A consumer that builds wrapped lines out of many small uniformly styled fragments only needs the shaped glyphs plus a single decoration run it can track itself, but it ends up moving and reallocating that mostly dead capacity constantly because splitting and painting are only reachable through `ShapedLine`. This moves the glyph-partitioning half of `ShapedLine::split_at` down to a new `LineLayout::split_at`, and adds `LineLayout::paint`/`paint_background` methods that take explicit decoration runs. Together with the already-public `layout_line`, callers can now hold a bare `Arc<LineLayout>` and their own decorations. `ShapedLine::split_at` delegates to the new method and behaves the same. ## 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: - N/A |
||
|
CathalandKirill Bulatov
|
aa14836bb4 |
bash: Hook up workspace configuration for bash-language-server (#57487)
Allows configuring the Bash LSP.
Tested with the following config:
```json
"bash-language-server": {
"binary": {
"path": "bash-language-server",
"arguments": ["start"]
},
"settings": {
"bashIde": {
"shfmt": {
"binaryNextLine": true,
"caseIndent": true,
"spaceRedirects": true,
"simplifyCode": true
}
}
}
}
```
Config options [defined
here](https://github.com/bash-lsp/bash-language-server/blob/main/server/src/config.ts),
all prefixed with `bashIde`.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Added support for configuring the Bash LSP adapter.
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
|
||
|
迷渡andMrSubidubi
|
373c652df7 |
explorer_command_injector: Fix localized Windows context menu title (#60634)
Closes #55728 ## Summary The Windows installer writes the localized Windows 11 Explorer context menu title to `HKCU\Software\Classes\{RegValueName}ContextMenu`, where the release channels use `Zed`, `ZedPreview`, and `ZedNightly` as the registry value names. `explorer_command_injector.dll` was reading from `ZedEditor*ContextMenu` instead, so the registry lookup failed and Explorer always received the hardcoded `Open with Zed` fallback. This aligns the DLL registry paths with the installer-written keys for stable, preview, and nightly. ## Tests - `cargo check --package explorer_command_injector --no-default-features --features stable` - `cargo check --package explorer_command_injector --no-default-features --features preview` - `cargo check --package explorer_command_injector` - `cargo check --package explorer_command_injector --all-features` - `cargo fmt --check --package explorer_command_injector` - `git diff --check` Release Notes: - Fixed localized Windows Explorer context menu titles falling back to English. --------- Co-authored-by: MrSubidubi <finn@zed.dev> |
||
|
Finn Evers
|
e7b4a54c53 |
language_core: Represent supported queries using an enum (#62707)
Refactors our query loading to instead have an enum of supported queries and load the query files themselves in parallel, where possible. We will use this to warn extension authors when unsupported queries are present, as we no longer want to ship those as part of the extension. It also now enforces one file per supported query - only one extension currently utilizes this feature and was undocumented previously, so I decided in favor of removing it here, since this will help with enforcing extensions to just ship query files we actually support in the future. The extension has also been migrated so that it does not break with this effort Side-effect of this change is that we now load both embedded and external languages up to at least 10%/5% faster, since the files are now read in parallel as opposed to sequentially one by one. Release Notes: - N/A |
||
|
|
a89202a036 |
docs: Fix WSL action name in remote development guide (#61073)
# Objective Fixes #60922 The remote development documentation references action names as hardcoded strings (`projects: open in wsl`, `projects: open wsl`). These can drift out of sync with the actual action definitions in code and don't benefit from the docs preprocessor's auto-rendering. ## Solution Replaced hardcoded action name strings with the `{#action ...}` preprocessor template syntax in `docs/src/remote-development.md`: - `{#action projects::OpenFolderInWsl}` for "Opening a local folder in WSL" - `{#action projects::OpenWsl}` for "Opening a folder already in WSL" This ensures the docs auto-resolve the human-readable action name from the code definition, preventing future drift. ## Testing - Verified the `{#action ...}` syntax is documented in `docs/README.md:78-82` and implemented in `crates/docs_preprocessor/src/main.rs`. - Reviewed the action definitions in `crates/zed_actions/src/lib.rs:843` (`OpenFolderInWsl`) and `lib.rs:852` (`OpenWsl`) to confirm correct namespace and struct names. - No code changes, docs only — no build or test required. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable ## Showcase N/A — documentation-only change. --- Release Notes: - N/A --------- Co-authored-by: MrSubidubi <finn@zed.dev> Co-authored-by: Finn Evers <finn.evers@outlook.de> |
||
|
zed-zippy[bot]
|
981470b1c5 |
Bump Zed to v1.18.0 (#62882)
Release Notes: - N/A Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com> |
||
|
Xin Zhao
|
45997391ba |
python: Support nested analysis settings for Pyright and basedpyright (#62673)
# Objective Closes #62624 Recently, Pyright and BasedPyright changed how they retrieve analysis settings through `workspace/configuration` in microsoft/pyright#11480 and DetachHead/basedpyright#1847, respectively. Older versions requested the dotted `python.analysis` and `basedpyright.analysis` sections directly. Recent versions instead request the parent `python` or `basedpyright` section and read its nested `analysis` object. Because Zed stores many existing configurations under the dotted top-level keys, those settings are not included in its responses to the new parent-section requests and are therefore silently ignored. Zed's documentation and many users' settings still use configurations like this: https://github.com/zed-industries/zed/blob/4155155572601034cec5e5cfa9805bf88957553c/docs/src/languages/python.md?plain=1#L131-L148 all the configrations in `basedpyright.analysis` won't work now. ## Solution To maintain compatibility with both old and new servers, we need to support both configuration formats. This PR introduces `normalize_pyright_analysis_configuration`, which copies the analysis settings into both the dotted and nested formats. This ensures that the settings are available regardless of which format the language server requests. The documentation, however, has been updated to use the nested structure. ## Testing New unit tests have been added, and the changes have also been built and 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: - Fixed some Pyright and BasedPyright settings not being applied properly. |
||
|
Ibrahim Khan
|
d5da3168c0 |
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 |
||
|
HuaGu-Dragon
|
68bd0faf7e |
file_finder: Fix auto-jump to wrong file on hover via new set_hovered_index hook (#61716)
# Objective - Fixes #54158 ## Solution - The root cause is in `FileFinderDelegate::set_selected_index`: it always sets `has_changed_selected_index = true`, regardless of whether the selection change was triggered by keyboard navigation or mouse hover. - Fix: Added a separate `set_hovered_index` hook to the `PickerDelegate` trait with a default implementation that delegates to `set_selected_index`. The hover handler in Picker now calls `set_hovered_index` instead of `set_selected_index`. FileFinderDelegate overrides `set_hovered_index` to update `selected_index` without setting `has_changed_selected_index`, so hover-triggered selection changes no longer interfere with the `Cmd+P` auto-confirm logic. ## Testing - Added `test_hover_does_not_set_has_changed_selected_index` in `file_finder_tests.rs` ## 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 file finder auto-jumping to the wrong file when the mouse hovered over a different entry after pressing `Cmd+P` |
||
|
Dino
|
7f6677e795 |
git_ui: Improve discard tracked changes context menu option (#62872)
# Objective Ensure that the "Discard Tracked Changes" option shown in the context menu that can be opened in the Git Panel's "Changes" tab is only displayed when it can actually be used. Currently, it is also shown when the "Unstaged" section has tracked files, even though clicking will not actually do anything. Besides fixing that, the changes in this Pull Request also update how the "Discard Tracked Changes" action works when picked from a subfolder, with only changes in that subfolder being discarded. Closes #62535 ## Solution - Update `git_ui::git_panel::git_panel_context_menu` to now accept a `has_staged_tracked_changes` boolean, in order to be able to differentiate between the panel having tracked changes, be it unstaged or staged, and specifically staged tracked changes, as we only want the "Discard Tracked Changes" to be enabled and affect staged changes. - Add `git_ui::git_panel::GitPanel::directory_context_descendants` in order to be able to obtain the list of entries under the directory where the context menu was deployed, if any. - Update `git_ui::git_panel::GitPanel::restored_tracked_files` to leverage the new `directory_context_descendants` method, ensuring that only the entries under the context menu's directory are restored, instead of all staged tracked files ## Testing Tested both manually, as shown in the "Showcase" section, as well as introduced a new test for these changes – `git_ui::git_panel::tests::test_directory_discard_tracked_changes`. ## 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) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable ## Showcase <details> <summary>Before</summary> https://github.com/user-attachments/assets/24bbb23c-78fb-4fe3-82da-d8bcaec0d79c </details> <details> <summary>After</summary> https://github.com/user-attachments/assets/70db9189-9122-4ee4-b03f-648935c4f0a4 </details> --- Release Notes: - Fixed the "Discard Tracked Changes" option being enabled for files in the "Unstaged" section in the Git Panel - Updated the "Discard Tracked Changes" option to only affects files in the directory where the context menu was deployed |
||
|
Smit Barmase
|
12c7b62b90 |
gpui_macos: Fix fullscreen behavior on non-macOS and after restart (#62819)
Follow-up to #60020. - Fixes simple fullscreen preventing fullscreen from working on Linux and Windows (since I use shared dotfiles). - Fixes quitting Zed in simple fullscreen not correctly restoring the previous window bounds, causing it to reopen maximized. We are not handling opening it back in simple fullscreen yet. Release Notes: - N/A |
||
|
Kevin BravoandTom Houlé
|
d7f85eed4e |
Preserve --user-data-dir across restarts (#62022)
# Objective Fixes #57701. When Zed is launched with `--user-data-dir`, a Zed-initiated restart—such as `workspace: clear trusted worktrees` or Restart to Update—can relaunch Zed without that argument. The restarted process then uses the default data directory instead of the directory selected by the user. ## Solution - Store the resolved custom data directory as GPUI restart arguments alongside the existing optional restart executable path. - Forward those arguments when relaunching on Linux, macOS, and Windows. - Preserve argument boundaries and native `OsString` values, including paths containing spaces. - On Windows updates, carry the arguments through `auto_update_helper.exe` when it launches the updated `Zed.exe`. Normal launches without `--user-data-dir` continue to restart without additional arguments. This does not attempt to preserve unrelated CLI arguments or general launch state. ## Testing - `cargo fmt --all -- --check` - `cargo test -p gpui` - `cargo test -p auto_update --features workspace/test-support` - `cargo check -p auto_update_helper --tests --target x86_64-pc-windows-msvc` - `./script/clippy -p gpui -p gpui_macos -p auto_update -p zed` - `./script/clippy -p auto_update_helper --target x86_64-pc-windows-msvc` The regression tests cover simultaneous restart executable and argument forwarding, Windows paths containing spaces and trailing backslashes, updater-helper argument parsing, and the final `Zed.exe` command. Compilation and unit tests were run on macOS. Linux and Windows runtime behavior was reviewed but not run locally. A full `gpui_windows` cross-target check was attempted, but its `psm` dependency requires the MSVC `lib.exe` tool, which is not available on this macOS host; the standalone Windows updater helper and its tests compile successfully for the Windows target. ## 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 (no UI changes) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - Fixed Zed forgetting an explicitly passed `--user-data-dir` argument after restarting (e.g. clicking "Restart to Update") --------- Co-authored-by: Tom Houlé <tom@tomhoule.com> |
||
|
Remco SmitsandKirill Bulatov
|
2dd39da2b0 |
cloud_api_client: Move spawn native websocket to the background (#62874)
# Objective While working on something else, I noticed that I sometimes get this warning about a foreground hang: ``` 2026-08-19T11:25:45+02:00 INFO [zed::reliability::hang_detection::logging] New foreground hang detected: Tasks(s) that ran too long 215.24375ms - crates/cloud_api_client/src/websocket/native.rs:34:23 ``` That I believe can just be safely moved to the background, unless I'm missing something here. ## Solution Spawn the websocket task on the background instead of on the foreground, so that we can't hang the foreground thread anymore for **~200ms**. ## Testing I have tested that I can still connect to the websocket, not sure what else to test. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [ ] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - N/A --------- Co-authored-by: Kirill Bulatov <mail4score@gmail.com> |
||
|
Warya Wayneandzed-zippy[bot]
|
562346c380 |
Markdown preview visible find matches (#62280)
# Objective Search in the markdown preview matches against the raw markdown source, including text that never renders. Searching a README for a common word reports more matches than are visible: the count says 2 when only 1 is on screen, and navigating to the phantom match appears to do nothing. Badge-heavy READMEs make this worse, since every badge URL contributes searchable words (`github`, `build`, `main`, `svg`) that the reader never sees. ## Solution Track which source ranges produce no on-screen text and filter matches against them: - Link destinations (`[label](url)`, where only `label` renders) - Images, including alt text and destination, since an image renders as an image - Link reference definitions, which `pulldown-cmark` consumes and never emits events for Ranges are returned sorted and disjoint so the preview can binary search them. Search results also derive from the parsed markdown, which lags the source during a background parse, so `MatchesInvalidated` now fires once the parse lands. ## Testing `cargo test -p markdown -p markdown_preview`. Eight new tests cover link destinations, reference definitions, standalone images, linked images, images between link text, parse-in-flight, and match-order independence. Note: `follow_preview_serialized_path_updates_when_followed_editor_changes` fails on `main` independently of this change (sqlite `FOREIGN KEY constraint failed` in `save_preview`, passes in isolation). ## 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) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable ## Showcase Markdown preview search on the same document, installed Zed versus this branch: Before: <img width="1090" height="1235" alt="warya_wayne_zed_fix_miscounted_search_in_Markdown_preview_current" src="https://github.com/user-attachments/assets/d2e59e12-b43e-4fea-ac9c-12631845653b" /> After: <img width="1090" height="1235" alt="warya_wayne_zed_fix_miscounted_search_in_Markdown_preview_new" src="https://github.com/user-attachments/assets/9f681fa4-f141-41c9-af9f-675cf3a2f0bd" /> --- Release Notes: - Fixed markdown preview search matching text that isn't rendered, such as link and image destinations --------- Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com> |
||
|
Xin Zhao
|
731096c09a |
Fix project path handling when connecting from Unix to Windows remotes (#62038)
# Objective Follow-up of #61374. Zed now supports Windows as a remote target, but when connecting from a Unix platform to Windows, some path handling still uses the native client's path style (Unix) to construct paths, which causes weird path displays in different areas. One of them is the project path stored in the `settings.json` file, which is related to the open path picker in the codebase: https://github.com/zed-industries/zed/blob/0500fd9ee99a4a98b36e339f3674e391697690fd/crates/open_path_prompt/src/open_path_prompt.rs#L668-L679 For example, if I have a remote project at `D:\code\test_python` and want to open it in remote development, I usually use path completions, with `D:\code\` as the parent path and `test_python` as the selected candidate. Zed directly joins them using `Path::join` on the Unix platform, which results in `D:\code\/test_python`. A second thing I found is the displayed name for the git repo. The related source code is: https://github.com/zed-industries/zed/blob/0500fd9ee99a4a98b36e339f3674e391697690fd/crates/title_bar/src/title_bar.rs#L262-L268 Also taking `D:\code\test_python` as an example: the passed-in `common_dir_abs_path` is `D:\code\test_python\.git`, and `repo_identity_path()` directly uses `Path::file_name()` and `Path::parent()` from the standard library to handle this: https://github.com/zed-industries/zed/blob/0500fd9ee99a4a98b36e339f3674e391697690fd/crates/project/src/git_store.rs#L9956-L9965 Ideally, this function should return `D:\code\test_python`. But due to the platform mismatch, `D:\code\test_python\.git` is returned; after further processing in the title bar, we get `D:\code\test_python\` as the displayed name, while the expected display name is `test_python`. In the past, only Unix-like systems could serve as remote servers, and their path separator (`/`) is valid on Windows, so everything looked fine. But Unix does not support `\` as a valid separator — that's the root cause. We need to use `PathStyle`, which is designed for processing paths across platforms, to deal with these cases. ## Solution - Added new APIs `PathStyle::parent()` and `PathStyle::file_name()`, which serve as replacements for `Path::parent()` and `Path::file_name()` to process paths cross-platform. - Adopted the new APIs in `repo_identity_path()`, and updated the relevant call sites. - For the open path picker, use `PathStyle::join_path()` instead of `Path::join`. ## Testing The added `PathStyle::parent()` and `PathStyle::file_name()` are covered by detailed unit tests. These tests verify that the behavior matches the corresponding methods in `Path`, just independent of the host platform. For the path display issues, I built and tested manually; a comparison is 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) - [ ] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable ## Showcase <details> <summary>Click to view showcase</summary> | Content | Before | After | |:--:|:--:|:--:| |title bar|<img width="486" height="272" alt="title_bar_before" src="https://github.com/user-attachments/assets/d14d0e37-a1b8-43ab-b51b-fe9dd1b977eb" /> | <img width="406" height="274" alt="title_bar_after" src="https://github.com/user-attachments/assets/fc9193f4-d42c-47a8-a254-4ed08c806a11" /> | |path storage| <img width="337" height="264" alt="project_path_before" src="https://github.com/user-attachments/assets/3352add3-20df-43b9-8a20-10ee7d96e703" />| <img width="319" height="262" alt="project_path_after" src="https://github.com/user-attachments/assets/fa3d7feb-f393-416a-868d-85eb0af5cfb8" />| |open remote| <img width="554" height="135" alt="open_remote_before" src="https://github.com/user-attachments/assets/62983eca-22ad-472f-8333-8561cfc17357" />|<img width="562" height="176" alt="open_remote_after" src="https://github.com/user-attachments/assets/22528a6b-0e73-4a12-a825-673ba57a63da" /> | </details> ## Other things to note This PR also did a little refactoring: it moved the `PathStyle`-related tests from the `util` crate to the `path` crate, and updated the documentation to reflect that Windows can serve as a remote platform. The recent project picker also suffers from the same cross-platform bug, but it is not fixed here, because a clean fix requires dealing with database storage, unlike the direct API changes made here. I will address it in a follow-up PR. This PR looks very large, but most of the changes are the test migration and the new API implementation. I hope the unit tests and comments can offload some of the burden for reviewers. --- Release Notes: - Fixed project paths being built incorrectly when connecting from Unix machines to Windows remote servers. |
||
|
Gaauwe Rombouts
|
702a310ea4 |
gpui: Support image paste and async clipboard reads on web (#62871)
Deliver the DOM paste event as a full ClipboardItem (text and image files) through a new InputHandler::paste hook instead of inserting only plain text, and add Platform::read_from_clipboard_async so app-initiated paste (e.g. a custom context menu) can use the browser's asynchronous, permission-gated clipboard API. Desktop platforms are unaffected: the async read defaults to a ready task wrapping the synchronous read, and the paste hook defaults to plain-text insertion. Release Notes: - N/A |
||
|
Gaauwe Rombouts
|
82b14aa6a3 |
gpui_web: Stream Fetch response bodies (#62333)
Adds streaming support to the web `FetchHttpClient`: response bodies are now read incrementally via the Fetch `ReadableStream` API instead of being buffered whole with `arrayBuffer()`, enabling streaming responses (e.g. LLM completions) on web. A bounded channel propagates backpressure, and dropping the body cancels the browser-side stream. Release Notes: - N/A |
||
|
Jakub Konka
|
be3db5feff |
gpui_linux: Handle XKB context initialization failure (#62868)
Release Notes: - Added check for XKB context initialization failure |
||
|
Vlad Ionescuanddino
|
29acba32d5 |
agent: OpenCode model updates (+6 Go, +7/-1 Zen, removed Free) (#61199)
Closes https://github.com/zed-industries/zed/issues/62559 Related discussion: https://github.com/zed-industries/zed/discussions/61160 # Objective Adding newly-released OpenCode models. Removing OpenCode Free models completely. ## Solution > [!TIP] > This pull request is **best reviewed commit-by-commit**! **OpenCode Go**: - added **Kimi K3** as per [[1]](https://github.com/anomalyco/models.dev/blob/89183a9646cf2fa30300f7203a5b4f2ca69d1374/providers/opencode-go/models/kimi-k3.toml) and [[2]](https://github.com/anomalyco/models.dev/blob/dev/models/moonshotai/kimi-k3.toml). Currently, the only supported reasoning level available is `Max` which was validated both with Models.dev data and OpenCode CLI. - added **Grok 4.5** as per [[1]](https://github.com/anomalyco/models.dev/blob/89183a9646cf2fa30300f7203a5b4f2ca69d1374/providers/opencode-go/models/grok-4.5.toml) and [[2]](https://github.com/anomalyco/models.dev/blob/89183a9646cf2fa30300f7203a5b4f2ca69d1374/models/xai/grok-4.5.toml) - added **Tencent Hy3** as per [[1]](https://github.com/anomalyco/models.dev/commit/b013d94872bb5993fad19ad35fadf74cb029516e) and [[2]](https://github.com/anomalyco/models.dev/blob/f63b5ce78dd78869faa0612353b1055f6608dc97/models/tencent/hy3.toml) - added **GPT 5.6 Luna** as per [[1]](https://github.com/anomalyco/opencode/pull/39812) and [[2]](https://github.com/anomalyco/models.dev/blob/dev/providers/opencode-go/models/gpt-5.6-luna.toml) - added **Qwen 3.8 Max** as per [[1]](https://github.com/anomalyco/models.dev/commit/403a7bdd43ac7daeadc8bb755eccabf66a0afb9d) and [[2]](https://github.com/anomalyco/opencode/commit/e9e747245681127c9f3e300aa8c46f2554fdb294) - added **GLM 5.3** as per [[1]](https://github.com/anomalyco/models.dev/blob/3876740bf4f0290e014bc85340e1dba34f0e99a7/models/zhipuai/glm-5.3.toml) and [[2]](https://github.com/anomalyco/models.dev/commit/94a1629610b579fd80f7c488f5e4e8d78c8b6883) and [[3]](https://github.com/anomalyco/opencode/pull/42518) **OpenCode Zen**: - added **Gemini 3.5 Flash Lite** as per [[1]](https://github.com/anomalyco/models.dev/blob/f63b5ce78dd78869faa0612353b1055f6608dc97/providers/opencode/models/gemini-3.5-flash-lite.toml) and [[2]](https://github.com/anomalyco/models.dev/blob/f63b5ce78dd78869faa0612353b1055f6608dc97/models/google/gemini-3.5-flash-lite.toml) - added **Gemini 3.6 Flash** as per [[1]](https://github.com/anomalyco/models.dev/blob/f63b5ce78dd78869faa0612353b1055f6608dc97/providers/opencode/models/gemini-3.6-flash.toml) and [[2]](https://github.com/anomalyco/models.dev/blob/f63b5ce78dd78869faa0612353b1055f6608dc97/models/google/gemini-3.6-flash.toml) - added **Gemini 3.7 Flash** as per [[1]](https://github.com/anomalyco/models.dev/pull/4632) and [[2]](https://github.com/anomalyco/models.dev/commit/b1810e30d7abb11af1092b51aa28cbafc2c440b8) and [[3]](https://github.com/anomalyco/opencode/pull/42390) and [[4]](https://github.com/anomalyco/opencode/pull/42393) - added **Claude Opus 5** as per [[1]](https://github.com/anomalyco/models.dev/commit/e3ae24cdd7fb524d73e1569ed1713991c5ba688c) and [[2]](https://github.com/anomalyco/models.dev/commit/342b5572a06735d0efa8c3c419589051199459d8) - added **Kimi K3** as per [[1]](https://github.com/anomalyco/opencode/commit/a9bebd36530dbab28c4644eb7b35b2b1460b8b90) and [[2]](https://github.com/anomalyco/models.dev/commit/38ccccc20d7d827f99d791d07cc4cedb8b4eec24) - added **Grok 4.6** as per [[1]](https://github.com/anomalyco/models.dev/commit/74789f5a02746cf6c40b75c342432a9d525c28b9) and [[2]](https://github.com/anomalyco/opencode/commit/d92d1e654bd1aa8ccb972b3059825314c1633eb8) and [[3]](https://github.com/anomalyco/models.dev/pull/4575) - added **Muse Spark 1.2** as per [[1]](https://github.com/anomalyco/models.dev/commit/fa03dca90bad225a09263ad6ad227c7f47d0172d) and [[2]](https://github.com/anomalyco/models.dev/blob/3876740bf4f0290e014bc85340e1dba34f0e99a7/models/meta/muse-spark-1.2.toml) and [[3]](https://github.com/anomalyco/opencode/pull/42508) - removed **Claude Opus 4.1** as per [[1]](https://github.com/anomalyco/models.dev/commit/6951484e985fe55646a741ccd3ca1d4b15008e3f) **OpenCode Free**: removed all the models and the whole concept of "OpenCode Free" from Zed. As confirmed [by an Anomaly employee on the OpenCode Discord](https://discord.com/channels/1391832426048651334/1394667004979445931/1537530485356363899), free models are now OpenCode-only since they got abused waaaaay too much by people. Testing shows that even with an active OpenCode Go subscription configured, I can't use Free models in Zed — both Big Pickle and DeepSeek V4 Flash Free failed to reply to a _"hello"_ message and instead returned a rate-limit error. A full removal of OpenCode Free from Zed was implemented in https://github.com/zed-industries/zed/pull/61199/changes/49acbf7c92414c14c453113eb9b886f9bedff7cb as there was no point in keeping a _"Show free models"_ toggle that would confuse users. Users that had `show_free_models` configures in Zed settings will get an `Property show_free_models is not allowed.` notice. Users that had any Custom OpenCode models with `"subscription": "free"` configured will get an `Value is not accepted. Valid values: "zen", "go".` notice. Neither are blocking errors. ## Testing ✅ Kimi K3 on OpenCode Go - happily confirmed Kimi K3 works by running a simple "_rename this variable for me. add a function. delete the function_" test. ✅ Grok 4.5 on OpenCode Go - bravely resisted the continuous and relentless waves of disgust and confirmed Grok 4.5 works by running a simple "_rename this variable for me. add a function. delete the function_" test. I was a bit surprised this worked as I was located in an EU country while testing this. ✅ Hy3 on OpenCode Go - happily confirmed Hy3 works by running a simple "_rename this variable for me. add a function. delete the function_" test. ✅ GPT 5.6 Luna on OpeCode Go - confirmed GPT 5.6 Luna works on OpenCode Go by running a simple "_rename this variable for me. add a function. delete the function_" test. ✅ Qwen 3.8 Max on OpeCode Go - confirmed Qwen 3.8 Max works on OpenCode Go by running a simple "_rename this variable for me. add a function. delete the function_" test. ✅ GLM 5.3 on OpeCode Go - confirmed GLM 5.3 works on OpenCode Go by running a simple "_rename this variable for me. add a function. delete the function_" test. 🤷 I did not test the new OpenCode Zen models (Claude Opus 5, Gemini 3.5 Flash Lite, Gemini 3.6 Flash, Kimi K3, Grok 4.6, Gemini 3.7 Flash, and Muse Spark 1.2) as I don't have a Zen subscription and I am stubbornly refusing to get one. ✅ Confirmed removal of OpenCode Free does not impact the rest of the OpenCode. Confirmed that any Free-related settings generate notices and not errors. Confirmed the OpenCode tab in Setting looks good. ## 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 <details> <summary>Screenshots of the OpenCode Free deprecation warnings</summary> **Notice shown in the corner of Zed**: <img width="345" height="90" alt="Notice banner shown in Zed" src="https://github.com/user-attachments/assets/3e65ba96-582c-424e-9335-1b43d6c632a8" /> **Notice shown in Settings -> LLM Providers -> OpenCode**: <img width="421" height="323" alt="Settings screen showing unexpected values" src="https://github.com/user-attachments/assets/a5eb6005-8576-4311-8b23-9c5baf314d8d" /> **Notice shown in `settings.json`**: <img width="569" height="231" alt="Notices shown in settings.json" src="https://github.com/user-attachments/assets/475375a1-268c-4420-8ef7-a896548e4498" /> </details> --- Release Notes: - Removed OpenCode Free models from Zed's built-in OpenCode provider because they are only available through OpenCode surfaces, such as its external agent through ACP. - Added Kimi K3, Grok 4.5, Hy3, GPT 5.6 Luna, Qwen 3.8 Max, and GLM 5.3 to OpenCode Go. - Added Claude Opus 5, Gemini 3.5 Flash Lite, Gemini 3.6 Flash, Gemini 3.7 Flash, Kimi K3, Grok 4.6, and Muse Spark 1.2 to OpenCode Zen. - Removed the deprecated Claude Opus 4.1 model from OpenCode Zen. ---- > [!TIP] > This pull request is **best reviewed commit-by-commit**! --------- Co-authored-by: dino <dinojoaocosta@gmail.com> |
||
|
Dino
|
942b9b9803 |
git_ui: Refactor git panel entry collapse (#61846)
# Objective Standardize the behavior of collapsing/expanding entries between Project Panel and Git Panel. At the time of writing, using `left` or `right` on the Project Panel would find the nearest parent directory and collapse it while, on the Git Panel, that will only happen if the directory is already selected, otherwise it'll select the previous entry instead. ## Solution Update `git_ui::git_panel::GitPanel::collapse_selected_entry` in order to always try to find the nearest expanded directory, regardless of the selected entry, and then collapse it and select it. The default keymap for Vim/Helix has also been updated to ensure that `h` and `l` work for collapsing or expanding entries, similar to what already happens in Project Panel. ## Testing Tested both manually, as can be seen in the "Showcase" section as well as added a new test for these changes, `git_ui::git_panel::tests::test_collapse_selected_entry` . ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [ ] Unsafe blocks (if any) have justifying comments - [ ] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable ## Showcase <details> <summary>Before</summary> https://github.com/user-attachments/assets/2fd8db03-155a-4406-a190-17a1958dda11 </details> <details> <summary>After</summary> https://github.com/user-attachments/assets/f64bd584-a3c2-4a33-b95a-2547c8b721d2 </details> --- Release Notes: - Improved `git panel: collapse selected entry` in order to find and collapse the nearest parent directory, similar to the Project Panel. - Added support for using `h` and `l`, in Vim/Helix mode, to collapse and expand entries in the Git Panel. |
||
|
María Craig
|
55fa54b5a5 |
file_finder: Keep filenames visible for long paths (#62839)
# Objective Prevent long worktree and directory paths from shrinking filenames until they become difficult to read in file finder results. ## Solution Give the filename label non-shrinking flex sizing, and let the path label use the remaining space. When the path does not fit, it truncates from the beginning so the directories nearest the file remain visible. ## Testing - Ran `cargo fmt --all --check`. - Ran `cargo test -p file_finder --lib` — 79 tests passed. - Ran `./script/clippy -p file_finder`. - To verify manually, open a project with a long root name, search for files, and resize the file finder. Confirm that filenames remain visible while paths truncate from the beginning. ## 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 long project paths obscuring file names in the file finder. |
||
|
Anthony Eid
|
b9e156ba46 |
Restart interrupted update downloads after system wake (#60366)
Follow-up to #60301, which was reverted in #60321. I removed the reqwest part of the fix because it crashed. reqwest's `read_timeout` relies on a tokio timer, but Zed polls HTTP responses on gpui's executor instead of a tokio runtime, so it panicked when the response body was awaited. I'll follow up later by patching our reqwest fork to support the poll behavior we wanted. This fixes the download being stalled since we restart it when the system wakes. I also changed `App::on_system_wake` to return a `gpui::Subscription` to be consistent with gpui's other on-system-event handlers like `on_keyboard_layout_change` and `on_thermal_state_change`. Release Notes: - Fixed Zed update downloads stalling after the system wakes from sleep |
||
|
Anthony Eid
|
9a209fdf13 |
Enable CSV preview for all users (#62773)
Closes #58145 Remove the `tabular-data-preview` feature flag and register CSV preview actions and the quick action bar button for every user. Also remove the now-unused `feature_flags` dependency from the CSV preview crate. Release Notes: - Added CSV preview access for all users |
||
|
ArneshandKirill Bulatov
|
e440f6ee6e |
workspace: Activate the right tab when restoring a workspace (#62844)
@SomeoneToIgnore this is the follow up you asked for in #62692, done as discussed. `deserialize_to` keeps a `None` in `items` for every item that failed to deserialize, and those are never added to the pane. Any later tab therefore sits at a lower index in the pane than the one it was serialized with, so activating and previewing by serialized index lands on the tab that shifted into that slot. When the failing item is the last one, the index points past the end of the pane and nothing is activated or previewed. The serialized index is now mapped to the pane's index by counting the items before it that actually restored, and an index whose own item failed to restore is skipped. Closes #62843 Release Notes: - Fixed the wrong tab being activated when restoring a workspace containing items that fail to open --------- Co-authored-by: Kirill Bulatov <kirill@zed.dev> |
||
|
John YaniandKirill Bulatov
|
9fa09ccc24 |
Remove deprecated std::usize import from uniform_list.rs (#62841)
<img width="993" height="370" alt="image" src="https://github.com/user-attachments/assets/15e3a185-3328-4069-ad86-21d29f647f83" /> # Objective - using `std::usize` currently is a warning, but it's a hard fairule in rust nightly - gpui-web requires rust nightly - https://doc.rust-lang.org/std/usize/index.html ## Solution - remove std::usize import, it would be used a primitive type ## Testing - https://github.com/iamnbutler/gpui-unofficial/actions/runs/32189970651/job/95882109895#step:8:753 ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - N/A --------- Co-authored-by: Kirill Bulatov <kirill@zed.dev> |
||
|
Arnesh
|
22ba488f6d |
workspace: Keep pinned tabs correct when restoring a workspace (#62692)
Pinned tabs are the leading tabs of a pane, and that is persisted as a plain count. Both sides of workspace serialization could leave the count out of step with the tabs it is meant to describe: - When serializing, `serialize_pane_handle` drops items that cannot be serialized (a pinned diagnostics or project search tab, for example) from the pane's children, but still stored the pane's raw pinned count. - When restoring, `SerializedPane::deserialize_to` keeps a `None` in `items` for every item that failed to deserialize. Those are never added to the pane, but `self.pinned_count.min(items.len())` counted them anyway. In both cases the count ends up pointing past the tabs that were actually pinned, so the tabs that shift into those slots come back pinned even though they never were. This also explains the `Pinned tab count (N) exceeds actual tab count (M)` warning from #33342. Now the serialized count shrinks with each dropped pinned item, and on restore only the pinned items that were actually restored are counted. Closes #62003 Release Notes: - Fixed tabs being wrongly marked as pinned after reloading a workspace or updating Zed |
||
|
Ali
|
ac9a03c4b9 |
Make opening large files use less peak memory (#62748)
# Objective Opening a file laods it twice. `decode_file_text` builds the whole file as a `String`, and that `String` stays alive alongside the finished rope while `text::Buffer::new` copies it in. The `Vec` behind it grows by doubling, so it also commits up to nearly the file's size again in capacity it never uses. Partially addresses #27283. ## Solution Add `decode_file_text_to_rope`, which streams the file in 1 MB blocks straight into a `Rope`, validating UTF-8 and normalizing line endings as it goes. The file is never fully held as a `String`. `LoadedFile::text` becomes a `Rope` carrying the `LineEnding` detected before normalizing, so `buffer_store` calls `Buffer::new_normalized`. ## Testing On a 729 MB SQL dump, peak memory fell 25% and CPU fell around 28%. tested on 5950x, win11. Release Notes: - Improved memory use when opening large files, reducing peak memory during load by roughly the size of the file itself. |
||
|
Cameron Mcloughlin
|
be5535ef7b |
treesitter: Worker-pinned treesitter parsing (#62784)
Bumps the treesitter version to include https://github.com/tree-sitter/tree-sitter/pull/5851 Also makes some changes to `cx.spawn_dedicated` to make it work on web: - remove the blocking `recv` on the main thread - adds a new variant `TaskState::Rendezvous` to allow this code to synchronously return a task `TaskState::Rendezvous` is needed because of how `spawn_dedicated_thread` works: - the caller provides a callback that produces a non-`Send` `Future` on the dedicated thread - the callback is sent to the dedicated thread, executed, and the resulting `Task` is sent back to the main thread - this all happens synchronously, so that `spawn_dedicated_thread` returns a synchronous `Task` However, the blocking `recv` on the main thread traps on the main worker in the browser. This PR replaces that with a call to `recv_async`, but this requires a new `Rendezvous` variant on `TaskState` which represents "a task that it still waiting to receive the underlying handle from the dedicated thread". It also enables the `flume/spin` feature on the web, which is needed to avoid a synchronous lock acquisition in `send` (it's replaced with a spinlock). Note that `send_async` wouldn't work here because it acquires the same lock, and it's unnecessary because `send` only blocks when the channel is full, but it's an unbounded channel. --- Release Notes: - N/A or Added/Fixed/Improved ... |
||
|
Andrew Mitchell
|
10087cd21b |
markdown: Respect buffer_line_height in code blocks (#62785)
# Objective - Fixes #62528 - Code blocks in rendered markdown ignored the `buffer_line_height` setting. With the line height left unset, they fell back to the ambient default of ~1.618, so the same code was spaced more loosely in markdown than it was in an editor or the terminal. - The extra leading is most obvious with box-drawing characters — the ASCII-art box from the issue renders as disconnected stripes instead of continuous vertical rules. - The issue also notes that the preview font "seems bigger". That part is working as intended and is not changed here: preview code blocks size from `markdown_preview_font_size`, which falls back to `ui_font_size` rather than `buffer_font_size` so that temporary UI zoom doesn't resize the preview. Users who want it to match the editor can set `markdown_preview_font_size` explicitly. ## Solution - Set `line_height` on the code block text style in `MarkdownStyle::themed_with_overrides`, derived from `theme_settings.buffer_line_height`. - The value is `relative(...)` rather than absolute pixels so it tracks the code font size, which some callers override after building the style (e.g. the agent panel sets `code_block.text.font_size` downstream). An absolute value computed from the theme's font size would be wrong for those callers. - Scope: this applies to every `MarkdownFont` variant — preview, agent panel, and editor — since the code block style is shared and `with_preview_overrides` doesn't touch line height. - Prose leading is deliberately unchanged. It stays a per-element typographic choice, independent of the buffer setting. ## Testing - `cargo test -p markdown` — 145 passed, 0 failed. - Added `test_code_block_line_height_follows_buffer_line_height_setting`: renders a paragraph plus a fenced code block at `buffer_line_height` 1.2 and 1.8, asserts the code block's rendered line height tracks the setting, and asserts prose leading does *not* move. - Added `test_code_block_line_height_tracks_overridden_code_font_size`: overrides `code_block.text.font_size` after building the style and asserts the line height follows the override. This is what pins the `relative` vs. absolute choice. - To reproduce manually, set `"buffer_line_height": { "custom": 1.2 }` and open a markdown preview containing the ASCII-art box from #62528. The vertical rules should join into continuous lines, matching how the same block renders in an editor, and should visibly separate again at `"comfortable"`. ## 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="927" height="912" alt="Screenshot 2026-08-17 at 5 06 41 PM" src="https://github.com/user-attachments/assets/be6213bf-f3aa-42fb-8784-1985b5379d74" /> After <img width="915" height="994" alt="Screenshot 2026-08-17 at 5 06 54 PM" src="https://github.com/user-attachments/assets/c9c7f395-50cb-437b-a423-2030da88e4f4" /> --- Release Notes: - Fixed markdown code blocks not respecting the `buffer_line_height` setting |
||
|
Buyun Xu
|
e30a1d822b |
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. |
||
|
Bennet Bo Fenner
|
259e3ed786 |
Switch to async-tar fork (#62821)
This switches to `async-tar` to point to our fork, which has a fix for a bug that is causing the Cursor ACP agent fail to download in Zed, due to Pax attributes. We will switch back as soon as https://github.com/dignifiedquire/async-tar/pull/73 is merged. Closes #62655 Release Notes: - Fixed an issue where the Cursor ACP agent would fail to start |
||
|
Ben Kunkle
|
9d8cbc9980 |
gpui: Rasterize parsed SVGs at exact sizes (#62770)
# Objective Allow callers to rasterize parsed SVGs at exact device-pixel dimensions. ## Solution Add `SvgSize::ExactSize` and accept `SvgSize` in `render_parsed`. Existing scale-factor calls retain their 2× rasterization behavior. `SvgSize::Size` continues to preserve the SVG aspect ratio. Release Notes: - N/A |
||
|
|
ebd0e0b3a0 |
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> |
||
|
Oleksandr Kholiavko
|
4aef01479b |
tabular_data_preview: Finish generalizing crate naming (#62807)
# Objective #62768 renamed `crates/csv_preview` to `crates/tabular_data_preview`, but left the CSV-specific names inside it untouched (on purpose, to reduce prev PR scope & git diff noise) ## Solution Finished the generalization, one mechanical rename per commit for easier review: 1. `CsvPreviewView` -> `TabularDataPreviewPane` 2. `CsvPreviewSettings` -> `TabularDataPreviewSettings` 3. Methods/vars 4. Test helpers/fn names 5. User-facing strings and element ids: tab title fallback: - `"CSV Preview"` -> `"Tabular Data Preview"`, - empty state `"No CSV content to display"` -> `"No data to display"`, - dev tooltip, and element ids `csv-filter-*`/`csv-col-header-*`/`csv-table`/`csv-display-cell-*` -> `table-*`/`tabular-data-table` 6. Doc comments that implied CSV-only behavior, reworded to be format-agnostic > NOTE: PR is split into commits by change type for ease of review) ## Testing `cargo check -p tabular_data_preview -p zed` builds clean after each commit; `cargo test -p tabular_data_preview --lib` passes (10/10). ## 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) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - N/A |
||
|
Oleksandr KholiavkoandMrSubidubi
|
d0394b7c8c |
Rename csv_preview crate to tabular_data_preview (#62768)
# Objective #60768 renamed the feature (action names, icon, TSV/PSV/SSV support) from CSV-only to generic tabular data preview, but left the crate itself named `csv_preview` — no longer accurate now that it handles any delimited format. ## Solution Renamed `crates/csv_preview` to `crates/tabular_data_preview` and updated all references (workspace `Cargo.toml` members/dependencies, `crates/zed/Cargo.toml`, `crates/zed/src/main.rs`, `crates/zed/src/zed/quick_action_bar/preview.rs`). No behavior change. > NOTE: Mechanical changes. Internal structs not renamed on purpose to reduce git diff noise. Follow-up PRs will do the cleanup (also mechanical changes) ## Testing `cargo check -p tabular_data_preview` and `cargo check -p zed` build clean; preview still opens for csv/tsv/psv/ssv files. Zed still runs, everything still opens. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [ ] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [ ] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - N/A --------- Co-authored-by: MrSubidubi <finn@zed.dev> |
||
|
tidely
|
12f3994269 |
git_ui: Dismiss askpass prompts when requests end (#61292)
# Objective Fixes #47623 - When authenticating git commands using a security key through `askpass`. The modal which asks for user presence does not get dismissed even after the git command finishes successfully. ## Solution Add a cancellation task to the `AskPassModal`, which gets dropped when the requested operation completes. This cancellation task then dismisses the modal. ## Testing - I've tried authentication through `askpass` using my own security key. Testing both successful and failed authentication. - I've added tests which confirm that the modal gets dismissed when a task is cancelled, and that the cancellation is triggered when `ask_password` Task gets dropped. Willing to pair on review, message me on Slack. Showcase video left out because it would leak private information. ## 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 authentication prompts not dismissing automatically when using security keys with ssh |
||
|
Qiu shaoanddino
|
5e4c46ebe1 |
Fix markdown task list marker lookup (#60646)
# Objective
Fix Markdown preview task list checkboxes not rendering for task items
in
loose or nested lists.
For example, this Markdown should render all three items with
checkboxes:
```markdown
- [ ] test
- [x] test
- [x] test
```
Before this change, the items after blank lines could fall back to ordinary
list bullets instead of task checkboxes.
## Solution
Update Markdown list item rendering to detect task list markers in both tight
and loose list event shapes emitted by pulldown-cmark.
The previous renderer only handled:
Item -> TaskListMarker
Loose lists can emit:
Item -> Paragraph -> TaskListMarker
This PR adds a small helper to find task markers for both forms, then reuses
the existing checkbox rendering and toggle behavior.
## Testing
Tested on macOS with:
rustup run 1.95.0 cargo test -p markdown
test_task_marker_lookup_handles_loose_and_nested_lists
rustup run 1.95.0 cargo test -p markdown test_table_checkbox
The first test covers loose and nested task list items. The table checkbox
tests verify that [x] and [ ] inside tables still remain text and are not
treated as task list checkboxes.
## 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="927" height="275" alt="image" src="https://github.com/user-attachments/assets/a36f0b9f-8759-4593-99a9-8a256396e89e" />
after
<img width="963" height="322" alt="Snipaste_2026-07-09_12-27-05" src="https://github.com/user-attachments/assets/972fa7a7-274a-4b0a-a13c-c7e1aec27622" />
---
Release Notes:
- Fixed Markdown Preview for loose list item markers
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
|
||
|
Dom Porada
|
ef973c67c0 |
Add support for the "..." entry in file_scan_exclusions (#62769)
## Objective `file_scan_exclusions` replaces the defaults instead of adding to them, so excluding one extra directory means restating all eleven default globs and never picking up defaults added in later Zed releases. ## Solution `file_scan_exclusions` now accepts the `"..."` entry, which expands to the value it overrides, so `["**/node_modules", "..."]` adds to the inherited globs instead of replacing them. Entries listed by name keep their position, and leaving `"..."` out still replaces the list outright, so existing settings behave exactly as they do today. ## Testing - Four unit tests in `crates/settings_content/src/project.rs` cover splicing versus replacing, accumulation across successive layers, and edge cases: a repeated `"..."`, an empty list clearing the value, and a bare `["..."]` leaving it unchanged. - To check by hand: set `"file_scan_exclusions": ["**/node_modules", "..."]` in user settings and confirm `node_modules` disappears from the project panel and file finder while `.git` and `.DS_Store` stay excluded. Remove `"..."` and confirm only `node_modules` is excluded. Repeat in a project's `.zed/settings.json` to confirm it splices the resolved user settings rather than the defaults. - Tested on macOS. This is platform-independent settings-merge logic with no OS-specific code paths, so I did not test Linux or Windows. ## 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 support for the `"..."` entry in `file_scan_exclusions`. Custom exclusions can now extend the defaults instead of replacing them. |
