# 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.
Closes#60013
# Objective
Right now Zed can go full screen but it does not allow you to fix the
hole screen,
by that I mean that Zed can go behind the notch so you don't have extra
useless room left.
## Solution
You can now use the `fullscreen_mode` = `simple` setting to use the new
simple full screen feature, that lives besides the normal full screen
feature. But allows you to have an option to go 100% full screen without
losing any useless space on your macbook screen.
**Note** this is mostly usefull when you have a macbook that has a notch
whitch is kinda in the way of your work flow.
## 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="5712" height="4284" alt="IMG_0339"
src="https://github.com/user-attachments/assets/9f908ffd-7cef-4999-a454-c80f72c40dc8"
/>
**After** (Note now Zed is behind your notch when using the simple full
screen feature)
<img width="5712" height="4284" alt="IMG_0360"
src="https://github.com/user-attachments/assets/5917ed4d-2a64-4464-a794-bc46fd034521"
/>
---
Release Notes:
- Added support for simple fullscreen mode using the `fullscreen_mode`
setting, set it to `simple` to try it out.
## Summary
Adds a first-party `ask_user` tool to Zed's native agent
(`crates/agent`) that lets the agent ask the user a question and get an
answer back through a proper **elicitation form** rather than free-form
chat text.
This is a step towards the interactive-question experience requested in
[discussion
#48784](https://github.com/zed-industries/zed/discussions/48784)
(implement the ACP elicitation spec for agent questions). Zed already
renders elicitation forms client-side; this wires the native agent up to
that existing rail so the agent can drive single-select and/or free-text
prompts.
## What it does
The tool takes:
- `question` — the prompt shown to the user
- `options` — optional list of selectable choices (single-select)
- `allow_free_text` — whether the user may type a custom answer instead
of picking an option
The agent decides the shape of each question:
| `options` | `allow_free_text` | Result |
| --- | --- | --- |
| 2+ | `false` | Single-select only |
| 2+ | `true` | Single-select with a free-text "other" field |
| empty | `true` | Free-text only |
A typed answer takes precedence over a selected option, and the tool
always resolves (a cancelled or failed elicitation is reported back to
the agent rather than hanging).
## Demo
https://github.com/user-attachments/assets/9d438d87-af65-4fa2-b500-b1232007d0a0
## Implementation
- `thread.rs` — new `ThreadEvent::Elicitation(ElicitationRequest)`
variant plus `ToolCallEventStream::request_elicitation`, mirroring the
existing `prompt_for_decision` permission rail.
- `agent.rs` — handles the elicitation event by building a
session-scoped `acp::CreateElicitationRequest` and routing it through
`AcpThread::request_elicitation`, piping the response back to the tool.
- `tools/ask_user_tool.rs` — the tool itself, including schema
construction and response extraction.
- Registered in the `write` and `ask` profiles and excluded from the
tool-permissions setup UI.
No client-side UI changes were needed — the existing elicitation form
rendering handles it.
## Tests
`cargo test -p agent ask_user` — 5 unit tests covering schema
construction, validation, and accept/decline/cancel handling.
Release Notes:
- Added an `ask_user` tool that lets the agent ask the user a question
with selectable options and/or free-text input, rendered as an
elicitation form
Closes#21054
## Summary
• make the JetBrains base keymap use subword motions for
`Alt+Left/Right` and `Shift+Alt+Left/Right` in editors
• keep Zed's default keymaps and the underlying `word`/`subword`
primitives unchanged
• document word vs. subword navigation in the key bindings docs
• document the JetBrains default in the IntelliJ, WebStorm, PyCharm, and
RustRover migration guides
## Testing
• `./script/check-keymaps`
• `cargo fmt --all -- --check`
• `./script/clippy -p editor`
• `cd docs && pnpm dlx prettier@3.5.0 src/key-bindings.md
src/migrate/intellij.md src/migrate/webstorm.md src/migrate/pycharm.md
src/migrate/rustrover.md --check`
Related to #12816 and #34090, but does not actually address the
configurable word separators or broader subword semantics. Intentionally
scoped to JetBrains keymap defaults & docs.
Release Notes:
- Improved JetBrains keymap behavior by adding CamelHump-style subword
navigation in editors.
---------
Co-authored-by: Tom Houlé <tom@tomhoule.com>
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Fixes https://github.com/zed-industries/zed/issues/35780
Collab schema migration PR:
https://github.com/zed-industries/cloud/pull/3422
The corresponding database schema migration has been created in the
Cloud repo and applied to the production database.
Before, Zed scanned each and every entry in the tree down from the
directory it was opened in, except gitignored files and scan exclusions.
The approach is unchanged, if Zed detects it was open inside a git
repository: e.g. the directory open in Zed contains `.git` directory.
For the rest of the projects, 2 optimizations are made:
* Limit the depth of file scan traversal.
Now, `file_scan_depth` (default `5`) restricts Zed from traversing any
directory that has same number or more segments in its file path.
Such directories behave similar to gitignored directories: their
contents is not available in file finder, project search and project
panel, but can be lazily traversed when the directory is expanded (e.g.
project panel expands it or a nested file is open by path via terminal,
etc.)
To indicate that to the users, a status entry is shown firs time the
limitation is hit in the project:
<img width="858" height="133" alt="image"
src="https://github.com/user-attachments/assets/7da6cfbb-98b4-4cc3-bf2a-8902a9597a15"
/>
* During the scan, any git repositories that are not direct children of
the directory open in Zed (depth >= 2), are traversed and indexed
normally, but their git metadata is never fetched eagerly.
Only when Zed opens a buffer from that repo the git metadata is fetched
and applied.
All that combined now uses a way more moderate amount of CPU and RAM
when opening `~`:
<img width="1717" height="368" alt="Screenshot 2026-08-13 at 17 43 53"
src="https://github.com/user-attachments/assets/ec83e2a9-f7cc-452b-8eb7-af158284ca4e"
/>
File scan inclusions and exclusions are considered still for such
projects.
Set `file_scan_depth` to `0` to enable old behavior.
The setting is supported in the project settings, so custom values can
be set based on the project's structure.
---
Release Notes:
- Fixed Zed using a lot of memory and CPU in large, non-git-tracked,
directory trees
# Objective
Make `G` keybinding in Helix mode work like in Helix and not like in
Vim.
Fixes https://github.com/zed-industries/zed/issues/61580
## Solution
Helix has two ways to jump to a line by line number.
One is the `goto_file_start` command (bound to `gg`) that optionally
takes a count to go to that line instead of the start of the file. Zed
already supports it as `vim::StartOfDocument`.
The other is the dedicated `goto_line` command (bound to `G`) that only
does that and nothing else. Zed did not have it.
What's worse, the default `"shift-g": "vim::EndOfDocument"` binding
leaked from Vim keymap into Helix keymap, which previously made
`<count>G` accidentally work in Helix mode for the wrong reason, until
https://github.com/zed-industries/zed/pull/59449 fixed the behavior of
`vim::StartOfDocument` and `vim::EndOfDocument` actions to match Helix
exactly. This broke `<count>G` and exposed that `G` was bound to the
wrong action in Helix mode, and the correct one didn't exist.
This PR fixes that in the following way:
- adds new`vim::HelixGotoLine` action
- binds it to `shift-g` in `helix_normal` and `helix_select` modes in
the default Vim keymap
## Testing
- Unit tests
- Manual testing
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed the behavior of `G` binding in Helix mode and added new
`vim::HelixGotoLine` action
Signed-off-by: Oleksii Orlenko <alex@aqrln.net>
# Objective
Helix uses tab/shift-tab to navigate code action menus. Currently, this
will indent the code instead of navigating within the menu.
## Solution
Add keymaps.
## Testing
I tested it manually.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Added support for using `tab` and `shift-tab` to navigate the code
actions menu in Helix mode
# Objective
When developing remotely, when I close the uncommitted changes tab, I
need some time to load before I can copy the path. Or have to switch to
the project panel to find the specific file. All of this is annoying, so
I added a copy path action to the git panel's context menu and key
bindings consistent with the project panel.
## Solution
Already described in the Objective section.
## Testing
I wrote a unit test and tested it manually.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
<img width="411" height="535" alt="showcase"
src="https://github.com/user-attachments/assets/a17e7633-eb92-4737-aa30-958fe58bb99f"
/>
<img width="717" height="427" alt="showcase"
src="https://github.com/user-attachments/assets/d067e892-17de-4527-ac20-16cad6f38015"
/>
---
Release Notes:
- Added "Copy Path" and "Copy Relative Path" actions to the Git Panel's
context menu
## Summary
- Add `terminal.starts_open` setting so the terminal panel can open
automatically in new workspaces, like project and git panels already can
- Expose the setting through terminal settings docs, default settings,
Settings Editor metadata, and the terminal panel implementation
- I also added a matching settings page item for the existing
`git_panel.start_open` setting
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behaviour
- I decided not to add tests as the behaviour seems covered by the
existing settings tests, and similar areas don't seem to have their own
explicit tests.
- [x] Performance impact has been considered and is acceptable
Related to #51542 (issue mentions possibly adding for all panels, closed
with implementation for `git_panel`)
Release Notes:
- Added `terminal.starts_open` to control whether the terminal panel
opens automatically in new workspaces
## Summary
Adds a `gutter.git_gutter_width` setting that lets users pin the width,
in pixels, of the git diff hunk indicators in the editor gutter.
Previously the width was always derived from the buffer font size
(`floor(0.275 * line_height)`), which can render too thin or too thick
depending on font family and display pixel density. This adds an
optional override:
```json
{
"gutter": {
"git_gutter_width": 6
}
}
```
When the setting is unset (`null`, the default), the width continues to
scale with the buffer font size, so existing behavior is unchanged.
## Motivation
Requested in [discussion
#27799](https://github.com/zed-industries/zed/discussions/27799). Beyond
the width itself, participants noted the git hunk hit target is
extremely narrow and hard to click. Because the hunk hitbox reuses the
painted strip bounds, setting a wider `git_gutter_width` also widens the
clickable area, addressing that complaint with the same setting.
## Changes
- `settings_content`: new `git_gutter_width: Option<f32>` on
`GutterContent`.
- `editor`: mirror field on the resolved `Gutter`; `gutter_strip_width`
now consults the setting, and the value flows through `diff_hunk_bounds`
(including the deleted-hunk marker) and the gutter layout anchors for
line numbers, folds, and expand toggles.
- `settings` (VS Code import): pass through the new field.
- Docs + `default.json`: document the new setting.
## Notes
- `Eq` was dropped from `GutterContent`/`Gutter` because `f32` is not
`Eq`; this matches the existing `EditorSettingsContent` convention for
float-bearing settings.
Release Notes:
- Added a `gutter.git_gutter_width` setting to configure the width of
git diff indicators in the editor gutter
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
# Objective
Let git indicators — the editor gutter, file colors, and `git::Diff` —
show all changes on the current branch relative to its merge base with
the default branch, instead of only uncommitted changes.
Supersedes #60398; thanks to @samuelcolvin for the original
implementation and motivation.
Closes FR-135
## Solution
- New `git.diff_base` setting (`"head"` | `"default_branch"`), applied
live and toggleable per session from the editor controls menu ("Diff
Against Default Branch").
- Statuses come from a real merge-base-to-worktree tree diff (`git diff
--merge-base`), so local edits that revert branch changes correctly show
as unchanged.
- `GitStore` shares one `DiffBufferList` per repository with the Branch
Diff view; `repo_snapshots` and `project_path_git_status` keep returning
index/worktree truth, while display surfaces use separate `display_*`
APIs.
- `BufferDiff` now records what its base is (`DiffBaseKind`); hunks
whose base isn't HEAD are read-only in the gutter — stage/restore
buttons and keybindings are inert, so committed work can't be silently
rewritten.
- `git::Diff` follows the setting; new `git::DiffHead` always opens the
HEAD diff; `git::BranchDiff` is renamed `git::DiffBranch` (deprecated
alias kept).
Tradeoffs / known limitations:
- Hunk-level staging is unavailable while in `default_branch` mode
(whole-file staging via the git panel still works). Staging just the
uncommitted sub-ranges of a branch hunk is a follow-up.
- Remote hosts running an older server ignore the new
`GetTreeDiff.includes_worktree` proto field and degrade to
committed-changes-only branch diffs.
- Repositories with no resolvable default branch fall back to
HEAD-relative behavior; a failed first resolution retries on the next
branch-list change.
## Testing
- Real-git-repo tests for the merge-base-to-worktree diff's edge cases:
files recreated after index deletion, committed deletions recreated on
disk, and symlinks.
- GPUI tests for status semantics (a branch change reverted on disk
shows clean), `git::Diff` routing, live setting changes, and read-only
hunk enforcement (restore/stage leave buffer and index untouched).
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Git: Added a `git.diff_base` setting (`"head"` or `"default_branch"`)
that makes the editor gutter, file colors, and diff view show all
changes on the current branch since its merge base with the default
branch, instead of only uncommitted changes.
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
# Objective
Fixes#58492.
With Vim mode enabled and an editor focused in normal mode, Escape does
not close the release notes notification shown after an update. Vim
consumes Escape before the workspace can handle `menu::Cancel`.
## Solution
Add Windows-specific Escape bindings for `menu::Cancel` in Vim and Helix
normal modes. Place them after the existing Escape bindings so GPUI
tries `menu::Cancel` first.
This is limited to Windows because macOS and Linux already provide
non-conflicting `Ctrl-C` and `Ctrl-Escape` alternatives, respectively.
## Testing
Added regression coverage for dismissing workspace notifications with
Escape in Vim normal mode.
I verified the test passes and the visible notification is dismissed
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
## Showcase
https://github.com/user-attachments/assets/3895385f-7be1-4c62-8d7c-05a5b580d855
---
Release Notes:
- Fixed release notes notifications not closing with `escape` when Vim
or Helix mode is enabled, on Windows.
The notebook editor has actions for adding and moving cells but no way
to delete one. This adds `notebook::DeleteCell`:
- Trash icon button in the notebook toolbar (own group below
add-markdown/add-code, disabled when the notebook has no cells)
- Jupyter-style `d d` binding plus `backspace` in cell command mode
(macOS and Linux keymaps)
- Deletes the selected cell; selection moves to the neighboring cell,
focus returns to command mode, and the item is marked dirty via the
existing structural-change tracking so saving persists the deletion
Tested locally on macOS with the notebook feature enabled: button click
and bindings delete the selected cell and saving writes the result.
(Screenshots in comments.)
Release Notes:
- Added a delete-cell action (`d d` in command mode and a toolbar
button) to the notebook editor (preview-only).
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
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#53517
Release Notes:
- Added Helix trim whitespace from selections action on `_`.
---------
Co-authored-by: Tom Houlé <tom@tomhoule.com>
Objective:
Allow users to configure the font families used by agent panel content
separately from the main UI and buffer fonts.
Solution:
- Add `agent_ui_font_family` for agent responses in the agent panel.
- Add `agent_buffer_font_family` for the agent panel message editor and
user messages.
- Keep context menus on the primary UI font family.
- Document the new settings and expose them in the settings UI.
Testing:
- Ran `cargo fmt`.
- Ran `cargo check -p settings_content -p theme_settings -p markdown -p
agent_ui -p settings_ui -p ui`.
- Ran `git diff --check`.
- Manually tested the agent panel font behavior in a dev build.
Release Notes:
- Added settings for configuring agent panel UI and buffer font
families.
Co-authored-by: Finn Evers <finn@zed.dev>
# Objective
Fix Git panel keybindings intercepting input intended for the repository
selector.
With Vim mode enabled, pressing `i` in the selector focused the
commit-message editor instead of filtering repositories. Platform
keybindings could also intercept printable input such as spaces.
Fixes#57936
## Solution
Exclude the `GitRepositorySelector` context from the Git panel
changes-list bindings in the macOS, Linux, Windows, and Vim keymaps.
## Testing
Manually tested on macOS using a debug build with Vim mode enabled and a
workspace containing two Git repositories
## 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 Git repository selector input being intercepted by Git panel
keybindings, including in Vim mode.
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Currently, Zed's "VSCode" keymap has certain discrepancies that are not
changed for compatibility reasons, e.g. opening inline assistant is
different in each editor.
To simplify the transition, extract VSCode bindings its own keymap so in
the future it's simpler to accept changes to each keymap separately.
Caveat: people who had ever changed the keymap, will have VSCode keymap
in their settings which will change their bindings slightly after this
commit is released.
I had to introduce more logic to `null` handling as had to somehow
disable `ctrl-enter` on mac from spawning the inline assistant block for
VSCode keymap (it's cmd-i there).
Release Notes:
- Split VSCode and Zed keymap files
Adds documentation for **PHPantom**—a fast, Rust-based PHP language
server—as a selectable language server alongside `PhpTools`,
`Intelephense`, and `Phpactor`.
Release Notes:
- N/A
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
# Objective
Closes#58986
This PR fixes `Ctrl-K Ctrl-O` opening a file picker while the Recent
Projects picker is focused.
The keymaps globally bind `Ctrl-O` to `workspace::OpenFiles` and `Ctrl-K
Ctrl-O` to `workspace::Open`
The Recent Projects context also binds `Ctrl-K` to toggle its actions
menu. The more specific binding ate `Ctrl-K` stopping the global `Ctrl-K
Ctrl-O` bind occuring.
## Solution
Add a `RecentProjects`-specific `Ctrl-K Ctrl-O` binding to
`workspace::Open` after the existing contextual `Ctrl-K` binding.
This matches the action associated with “Open Local Folders,” including
its multiple-selection and open-mode behavior.
macOS is unchanged because its primary `Cmd-O` shortcut already maps to
`workspace::Open`.
## Testing
Try #58986, then this.
## 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 `Ctrl-K Ctrl-O` opening a file picker instead of the local
folder picker from Recent Projects.
This PR converts the collab panel list from a GPUI list into a uniform
list, which was a requirement for the indent guides to be displayed. I
have been wanting to add that to the channels list for a while, and
finally carved out some time. Ended up adding some more tweaks here and
there as overall improvements (e.g., using a lock icon for private
icons) and to make the indent guide fully work design-wise given we have
the chevron buttons rendering on top of them.
Here's how it looks:
<img width="600" alt="Screenshot 2026-07-21 at 10 08@2x"
src="https://github.com/user-attachments/assets/351b7e0f-aeb4-4c79-8177-7f1cdf635fbe"
/>
Release Notes:
- N/A
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
# Objective
Fix discrepancy where, while in `Insert` mode and focused on the commit
editor, using `tab` or `shift-tab` would focus back on the changes list
but, in `Normal` mode, it would not.
## Solution
Update vim's default keymap in order to properly support handling `tab`
and `shift-tab` when focused on the commit editor and in `Normal` mode.
While in `Insert` mode, using these bindings would focus back on the
changes but, while in `Normal` mode that was not the case, so this
change fixes that issue.
## Testing
Manually confirmed to be working as expected.
## 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
## Showcase
<details>
<summary>Before</summary>
https://github.com/user-attachments/assets/5599d8a8-6451-428b-9a00-6a9ab348852c
</details>
<details>
<summary>After</summary>
https://github.com/user-attachments/assets/2be0654c-ca22-48c6-96eb-5b497f90c3a1
</details>
---
Release Notes:
- Fixed `tab` and `shift-tab` behavior in git's commit editor while in
Vim's `Normal` mode not focusing back on the changes list.
Adds a title_bar.show_worktree_name setting (default: true) that hides
the worktree picker button in the title bar, mirroring how
show_branch_name gates the branch picker. The "/" separator only renders
when both buttons are visible, and the container is omitted entirely
when both are hidden.
The setting is hide-only: it deliberately does not join the
render_project_items gate, so configurations with show_branch_name and
show_project_items both disabled keep hiding the whole group as before.
Requested in discussion
[zed-industries/zed#54902](https://github.com/zed-industries/zed/discussions/54902).
# Objective
The worktree name is always present in the title bar even when unused.
Unlike the branch name it has no dedicated option to disable it.
Requested in discussion
[zed-industries/zed#54902](https://github.com/zed-industries/zed/discussions/54902).
## Solution
Adds a `title_bar.show_worktree_name` setting (default: true) that hides
the worktree picker button in the title bar, mirroring how
show_branch_name gates the branch picker. The "/" separator only renders
when both buttons are visible, and the container is omitted entirely
when both are hidden.
The setting is hide-only: it deliberately does not join the
render_project_items gate, so configurations with show_branch_name and
show_project_items both disabled keep hiding the whole group as before.
## Testing
I tested the setting added by running the application by adding,
removing and toggling the `title_bar.show_worktree_name` setting in the
`settings.json`
## 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
- [ ] Performance impact has been considered and is acceptable
## Showcase
<img width="1496" height="982" alt="title_bar.show_worktree_name =
false"
src="https://github.com/user-attachments/assets/b2c502de-a8d8-4409-ba04-5ab807c77a8e"
/>
<img width="1496" height="982" alt="title_bar.show_worktree_name = true"
src="https://github.com/user-attachments/assets/6cea7eb5-0e88-454c-9c97-3b4ad62aed51"
/>
---
Release Notes:
- title_bar: Added title_bar.show_worktree_name (default: true) to hide
worktree picker button
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
on linux with the emacs keymap, holding `ctrl-n` at the end of the
buffer opens a new file every press. `ctrl-p` at the top opens the file
finder.
the keymap already tries `"ctrl-n": null`, but `null` only breaks
resolution in a *user* keymap, so from a base keymap
`workspace::NewFile` still resolves. a targeted unbind works regardless
of source:
```json
"ctrl-p": ["zed::Unbind", "file_finder::Toggle"],
"ctrl-n": ["zed::Unbind", "workspace::NewFile"],
```
left the MoveDown/MoveUp propagation alone, it's load bearing (agent
panel uses it for up-to-edit-last-message). tests cover the fix plus the
narrower ctrl-n/ctrl-p bindings still winning, since the unbind only
targets the one action.
ctrl-g/ctrl-x in that block are still null and probably just as broken,
but ctrl-x is a prefix key so i left them.
Closes#45010.
Release Notes:
- Fixed `ctrl-n` opening a new file and `ctrl-p` opening the file finder
at the ends of a buffer when using the Emacs keymap on Linux
# Objective
Make solo diff views show the full file by default while preserving an
easy way to focus on changed hunks. This addresses a recurring request
across issues and pull requests for full-file context in single-file Git
diffs.
## Solution
- Initialize the solo diff with a singleton multibuffer so the entire
file is visible on open.
- Keep the existing toolbar toggle available for switching to
changes-only excerpts.
- Use the singleton path key when replacing excerpts so toggling remains
reliable.
- Preserve Git change indicators in the scrollbar; the editor generates
those markers for singleton buffers.
## Testing
- Ran `cargo fmt -p git_ui`.
- Ran `git diff --check`.
- Ran `cargo check -p git_ui --no-default-features` successfully.
- Manually reviewed the full-file and changes-only state transitions in
`SoloDiffView`.
## 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, solo diffs opened with only changed hunks and surrounding
context. They now open with the complete file, retain Git change
indicators in the scrollbar, and can still be toggled to changes-only
from the toolbar.
---
Release Notes:
- Improved solo diffs to show the full file by default while retaining
Git change indicators in the scrollbar.
# Objective
Fixes#60540
## Solution
I suggest to focus on new feature keybindings support `Text Finder`
instead of supporting old `DeployReplace`:
1. Add `cmd+opt+f` bind for `Text Finder` in `Editor` and `BufferSearch`
to all platforms (now it's not there)
2. Remove `cmd+opt+f` bind for `buffer_search::DeployReplace` from
`Editor` and `BufferSearch` on macOS.
3. Add breaking changes `buffer_search::DeployReplace` has no keybind
anymore on macOS.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
<details>
<summary>Click to view showcase</summary>
Uploading github.mov…
</details>
---
Release Notes:
- `Text Search` now opens from almost all contexts (added `Editor`,
`BufferSearch`)
- Breaking changes: Dropped support for toggle filters hotkey in
`BufferSearch` in macOS instead of supporting new `Text Search` feature
with `cmd+alt+f`
Sometimes when creating Git worktrees, it's necessary to set things up
so the new worktree is ready. For example, copying env.vars, installing
dependencies, etc. That was already possible in Zed through the tasks
system, but you'd only maybe know about that if you read the
documentation or is super familiar with it already; nothing in the
product in the context of worktrees told you about that. This is what
this PR does.
Now, in the worktree picker, there's a "" button that opens the
`tasks.json` file exposing the `create_worktree` hook, which allows you
to plugin all sorts of things to be run by the time of a worktree
creation. If you don't already have a `tasks.json` file, we will create
a new one for you with a worktree-creation template. Otherwise, we
either append the `create_worktree` hook content to it or just open the
file.
Here's a quick video:
https://github.com/user-attachments/assets/21908be4-306b-4cf3-bed0-50d52cad9d79
Release Notes:
- Git Worktrees: Improved discoverability of the `create_worktree` hook
for setting up things that need to happen by the time of worktree
creation.
# Objective
Closes#59829
Provide a filterable, preview-backed picker for LSP results as an
alternative to the multi-buffer view, for references, definitions,
implementations.
## Solution
Update the 3 existing LSP actions (definitions, implementations, find
all references) to add a `open_results_in` parameter which accepts
either `multi_buffer` (default) or `picker` to show the results in a
filterable picker with preview. This behavior can be configured globally
in the settings via `lsp_results_location`.
UX:
- The 3 existing LSP actions each accept a `open_results_in` parameter
so that each action can be configuring individually with a custom
keybind
- The `lsp_results_location` global setting can be used to set a default
behavior with `open_results_in == None`
- Go to definition falls back to find all references (if configured) on
empty results which is consistent with the non-picker path
- Results are grouped by file; each row shows the line number and the
syntax-highlighted source line with the match emphasized.
- Typing filters by line text or path; the preview updates with the
selection.
- Enter/click opens the selection, `cmd/ctrl-enter` opens it in a split,
and re-invoking the command toggles the picker closed.
- Empty results show a toast so the command never silently does nothing.
- Note: the new pickers do not open on cmd-click, only when invoked via
the command palette or keybind
## Testing
- No automated tests yet — holding for first-round feedback on the
approach and UX before adding tests.
## 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
- [ ] Performance impact has been considered and is acceptable
## Showcase
https://github.com/user-attachments/assets/41538f23-9b54-4dfc-bfa7-a61564a675a8
---
Release Notes:
- The find all references, go to definitions, and go to implementations
LSP actions can be configured to open results in a picker with preview
instead of a multibuffer.
# Objective
Closes#60928
Currently, only the declaration of parameters in a function header is
highlighted as `variable.parameter`. Inside the function body,
parameters are highlighted as normal variables, making them
indistinguishable from local variables.
This PR ensures consistent highlighting for parameters throughout their
entire scope, helping developers distinguish between function inputs and
locally defined variables.
## Solution
- Updated the `default_semantic_token_rules.json`: when the token type
is `parameter`, no matter what token modifiers are, it is now mapped to
`variable.parameter` highlight style.
## Testing
Tested locally with Rust. The improvement in visual hierarchy is
demonstrated in the comparison below.
## 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 | After |
| :---: | :---: |
| <img width="1178" height="400" alt="before"
src="https://github.com/user-attachments/assets/90a01543-2dcc-41e0-a2a3-f8020c6d77ee"
/> | <img width="1194" height="387" alt="after"
src="https://github.com/user-attachments/assets/c81ba273-2ea7-4d38-b7df-a6069c09c28a"
/>|
---
Release Notes:
- Improved semantic token highlighting to distinguish function
parameters from local variables.
This PR adds a series of design improvements to the branch picker,
including:
- Consistent icon used for filter actions
- A keybinding/action to trigger the filter menu with the keyboard
- Filter menu positioning depending on the picker's editor position
- Error display that displays the full label without truncation/tooltip,
and is placed accordingly also depending on the picker's editor position
- List subheader in the search list depending on filtered option
Here's a quick video:
https://github.com/user-attachments/assets/70922daf-fc9f-4d94-bed8-c84d3ea73534
- - -
Release Notes:
- N/A
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
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.
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 ...
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>
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
# 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.
Turns out I only tested it with all tabs closed, the keybinding would
only work when all tabs were closed and you focused the agent panel. If
a file was opened in the center pane, cmd-f would open a search in that
file instead of searching in the agent panel, even if the thread view as
focused.
Closes#60686
Release Notes:
- agent: Fixed an issue where cmd-f would not work if file is open in
center pane
## Context
On Linux, `ctrl-q` is globally bound to `zed::Quit`. When a
`TerminalView` is focused, pressing `ctrl-q` quit the application
instead of forwarding the keycode to the shell, breaking programs like
`ftp`, `tig`, and any app that uses XON/XOFF flow control.
Windows already had the fix: its `Terminal` keymap context overrides
`ctrl-q` with `["terminal::SendKeystroke", "ctrl-q"]`. The Linux keymap
was simply missing that override.
Closes#58809
Manual test after fix below :
[Screencast from 2026-06-09
00-46-37.webm](https://github.com/user-attachments/assets/3d103b2a-bff1-4559-af1d-2a52d57a6b18)
## How to Review
- **`assets/keymaps/default-linux.json`** : One-line addition in the
`Terminal` context under the "Overrides for conflicting keybindings"
comment, mirroring the existing Windows entry.
- **`crates/terminal_view/src/terminal_view.rs`** : Regression test
`ctrl_q_is_forwarded_to_terminal_not_quit` (Linux-only, `#[cfg(target_os
= "linux")]`): loads the default keymap, focuses a display-only
terminal, simulates `ctrl-q`, and asserts the PTY receives byte `0x11`
instead of the quit action firing.
## 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 is consistent with the UI/UX checklist
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed `ctrl-q` quitting Zed instead of being forwarded to the shell
when a terminal is focused on Linux
## Summary
Introduces `format_on_save` variants that format only modified lines,
limiting formatting to lines changed since the last commit. This
prevents massive diffs when editing legacy codebases. Aligns with VS
Code's `editor.formatOnSaveMode` naming:
- `"modifications"` — formats only git-diffed lines. Requires source
control; skips formatting if no diff is available.
- `"modifications_if_available"` — formats only git-diffed lines,
falling back to full-file formatting for untracked files, when source
control is unavailable, or when the LSP does not support range
formatting.
Also supports importing equivalent VS Code settings
(`formatOnSaveMode`).
This PR uses the range-based whitespace/newline infrastructure from the
dependency PR above.
## Changes
<details>
<summary><b>New settings, modified ranges computation, VS Code
import</b></summary>
### New settings (`language.rs`, `default.json`, `all-settings.md`)
Two new `FormatOnSave` variants: `Modifications` and
`ModificationsIfAvailable`.
### Modified ranges computation (`items.rs`)
- `compute_format_decision()` — reads `format_on_save` setting across
all buffers, determines whether to use ranged formatting (`Ranges`),
full formatting (`Full`), or skip (`Skip`).
- `compute_modified_ranges()` — extracts modified line ranges from git
diff hunks via `BufferDiffSnapshot`.
- `is_empty_range()` — helper to detect deletion-only hunks that produce
no formatable content.
The `save()` method calls `compute_format_decision()` and dispatches
accordingly.
### Modifications mode in `lsp_store.rs`
- Adds `FormatOnSave::Modifications |
FormatOnSave::ModificationsIfAvailable` to the formatter selection match
arm.
- `ModificationsIfAvailable` falls back to full-file formatting when
ranged formatting produces no results.
### VS Code settings import (`vscode_import.rs`, `settings_store.rs`)
Imports `editor.formatOnSaveMode` mapping:
- `"modifications"` → `FormatOnSave::Modifications`
- `"modificationsIfAvailable"` →
`FormatOnSave::ModificationsIfAvailable`
- `"file"` → `FormatOnSave::On`
</details>
## Tests
- `test_modifications_format_on_save` — basic modifications mode
formatting with dirty buffer
- `test_modifications_format_no_changes` — clean buffer triggers no
formatting
- `test_modifications_format_lsp_no_range_support` — LSP without range
formatting skips entirely for `Modifications`
- `test_modifications_format_lsp_returns_empty_edits` — empty edits
handled gracefully
- `test_modifications_format_multiple_hunks` — two non-adjacent edits
produce two separate range formatting requests
---
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#16509
Depends on #53942
Release Notes:
- Added `modifications` and `modifications_if_available` options to
`format_on_save`, which format only git-changed lines instead of the
entire file
- When using modifications mode, `remove_trailing_whitespace_on_save`
and `ensure_final_newline_on_save` are also scoped to changed lines,
preventing unwanted diff jitter in legacy codebases
- Added support for importing VS Code's `editor.formatOnSaveMode`
setting
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
This fixes#56956.
The terminal link-open gesture was split between `mouse_down` and
`mouse_up`, but both halves only ran in the non-mouse-reporting path.
When a foreground app enabled terminal mouse reporting, a secondary
click on a URL or file path was forwarded to the PTY instead of opening
the link.
This changes secondary-click link handling so it checks for a hyperlink
before mouse reporting on press, and completes the matching hyperlink
open before mouse reporting on release. The event is only consumed when
the click actually lands on the same link, so normal clicks in
mouse-reporting TUIs continue to be forwarded as before.
Validation:
- `CARGO_BUILD_JOBS=1 cargo test -j1 -p terminal
test_hyperlink_ctrl_click_same_position_in_mouse_mode`
- `CARGO_BUILD_JOBS=1 cargo check -j1 -p terminal`
Release Notes:
- Improved terminal links: Cmd/Ctrl-click now opens links even when the
application has mouse reporting enabled (e.g. vim, opencode, claude).
Disable `terminal.open_links_in_mouse_mode` to forward these clicks to
the application instead.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
