mirror of
https://github.com/zed-industries/zed.git
synced 2026-08-24 00:16:18 +00:00
234 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
99f4c21c03
|
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]]( |
||
|
|
a7d74150ac
|
Fix the git_gutter_width setting (#62704)
Some checks are pending
run_tests / check_style (push) Waiting to run
run_tests / check_scripts (push) Blocked by required conditions
run_tests / check_postgres_and_protobuf_migrations (push) Blocked by required conditions
run_tests / extension_tests (push) Blocked by required conditions
run_tests / tests_pass (push) Blocked by required conditions
Congratsbot / check-author (push) Waiting to run
Congratsbot / congrats (push) Blocked by required conditions
deploy_nightly_docs / deploy_docs (push) Waiting to run
run_tests / orchestrate (push) Waiting to run
run_tests / clippy_windows (push) Blocked by required conditions
run_tests / clippy_linux (push) Blocked by required conditions
run_tests / clippy_mac (push) Blocked by required conditions
run_tests / clippy_mac_x86_64 (push) Blocked by required conditions
run_tests / run_tests_windows (push) Blocked by required conditions
run_tests / run_tests_linux (push) Blocked by required conditions
run_tests / run_tests_mac (push) Blocked by required conditions
run_tests / miri_scheduler (push) Blocked by required conditions
run_tests / doctests (push) Blocked by required conditions
run_tests / check_workspace_binaries (push) Blocked by required conditions
run_tests / build_visual_tests_binary (push) Blocked by required conditions
run_tests / check_wasm (push) Blocked by required conditions
run_tests / check_dependencies (push) Blocked by required conditions
run_tests / check_docs (push) Blocked by required conditions
run_tests / check_licenses (push) Blocked by required conditions
# 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> |
||
|
|
cf08569e82
|
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. |
||
|
|
2893b86b04
|
gpui_macos: Add simple fullscreen mode that covers the notch (#60020)
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. |
||
|
|
18be72fd68
|
Make file scanner less eager in non-git-tracked directory trees (#62583)
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 |
||
|
|
08827f9208
|
Add starts_open setting to terminal panel (#54373)
Some checks are pending
Congratsbot / check-author (push) Waiting to run
Congratsbot / congrats (push) Blocked by required conditions
deploy_nightly_docs / deploy_docs (push) Waiting to run
run_tests / orchestrate (push) Waiting to run
run_tests / check_style (push) Waiting to run
run_tests / clippy_windows (push) Blocked by required conditions
run_tests / clippy_linux (push) Blocked by required conditions
run_tests / clippy_mac (push) Blocked by required conditions
run_tests / clippy_mac_x86_64 (push) Blocked by required conditions
run_tests / run_tests_windows (push) Blocked by required conditions
run_tests / run_tests_linux (push) Blocked by required conditions
run_tests / run_tests_mac (push) Blocked by required conditions
run_tests / miri_scheduler (push) Blocked by required conditions
run_tests / doctests (push) Blocked by required conditions
run_tests / check_workspace_binaries (push) Blocked by required conditions
run_tests / build_visual_tests_binary (push) Blocked by required conditions
run_tests / check_wasm (push) Blocked by required conditions
run_tests / check_dependencies (push) Blocked by required conditions
run_tests / check_docs (push) Blocked by required conditions
run_tests / check_licenses (push) Blocked by required conditions
run_tests / check_scripts (push) Blocked by required conditions
run_tests / check_postgres_and_protobuf_migrations (push) Blocked by required conditions
run_tests / extension_tests (push) Blocked by required conditions
run_tests / tests_pass (push) Blocked by required conditions
## 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 |
||
|
|
35cb7558a9
|
editor: Add configurable git gutter width setting (#61304)
Some checks are pending
run_tests / orchestrate (push) Waiting to run
run_tests / check_style (push) Waiting to run
run_tests / clippy_windows (push) Blocked by required conditions
run_tests / clippy_linux (push) Blocked by required conditions
run_tests / clippy_mac (push) Blocked by required conditions
run_tests / clippy_mac_x86_64 (push) Blocked by required conditions
run_tests / run_tests_windows (push) Blocked by required conditions
run_tests / run_tests_linux (push) Blocked by required conditions
run_tests / run_tests_mac (push) Blocked by required conditions
run_tests / miri_scheduler (push) Blocked by required conditions
run_tests / doctests (push) Blocked by required conditions
run_tests / check_workspace_binaries (push) Blocked by required conditions
run_tests / check_wasm (push) Blocked by required conditions
run_tests / check_dependencies (push) Blocked by required conditions
run_tests / check_docs (push) Blocked by required conditions
run_tests / check_licenses (push) Blocked by required conditions
Congratsbot / check-author (push) Waiting to run
Congratsbot / congrats (push) Blocked by required conditions
deploy_nightly_docs / deploy_docs (push) Waiting to run
run_tests / build_visual_tests_binary (push) Blocked by required conditions
run_tests / tests_pass (push) Blocked by required conditions
run_tests / check_scripts (push) Blocked by required conditions
run_tests / check_postgres_and_protobuf_migrations (push) Blocked by required conditions
run_tests / extension_tests (push) Blocked by required conditions
## 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>
|
||
|
|
5e1fd392f6
|
git: Add diff_base setting for showing changes since the default branch (#61501)
Some checks are pending
Congratsbot / check-author (push) Waiting to run
Congratsbot / congrats (push) Blocked by required conditions
deploy_nightly_docs / deploy_docs (push) Waiting to run
run_tests / run_tests_windows (push) Blocked by required conditions
run_tests / check_workspace_binaries (push) Blocked by required conditions
run_tests / check_scripts (push) Blocked by required conditions
run_tests / orchestrate (push) Waiting to run
run_tests / check_style (push) Waiting to run
run_tests / clippy_windows (push) Blocked by required conditions
run_tests / clippy_linux (push) Blocked by required conditions
run_tests / clippy_mac (push) Blocked by required conditions
run_tests / clippy_mac_x86_64 (push) Blocked by required conditions
run_tests / run_tests_linux (push) Blocked by required conditions
run_tests / run_tests_mac (push) Blocked by required conditions
run_tests / miri_scheduler (push) Blocked by required conditions
run_tests / doctests (push) Blocked by required conditions
run_tests / build_visual_tests_binary (push) Blocked by required conditions
run_tests / check_wasm (push) Blocked by required conditions
run_tests / check_dependencies (push) Blocked by required conditions
run_tests / check_docs (push) Blocked by required conditions
run_tests / check_licenses (push) Blocked by required conditions
run_tests / check_postgres_and_protobuf_migrations (push) Blocked by required conditions
run_tests / extension_tests (push) Blocked by required conditions
run_tests / tests_pass (push) Blocked by required conditions
# 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> |
||
|
|
790dcefb01
|
edit_prediction: Support self-hosted Sweep Next Edit models (#51139)
This adds support for running self-hosted Sweep Next Edit edit prediction models through Zed's OpenAI-compatible provider. The target use case is a local deployment based on [sweepai/sweep-next-edit-1.5B](https://huggingface.co/sweepai/sweep-next-edit-1.5B), using the rewrite-window prompting approach described in [OSS Next Edit](https://blog.sweep.dev/posts/oss-next-edit). Personal user testing shows impressive quality from this small edit prediction model. This is valuable because it allows more flexibility for Zed users to self-host state of the art next edit prediction models! This PR addresses the self-hosted workflow discussed in https://github.com/zed-industries/zed/discussions/50929. Note that the self-hosted model path needed more than just a new dropdown value. Zed has to build the rewrite-window prompt shape the model expects, map the rewritten window back into anchored edits, and make `prompt_format: "infer"` work with the filename-style model identifiers that llama-server local server reports. The main changes are: - add a `Sweep` prompt format for OpenAI-compatible edit prediction providers and route it to a dedicated `SweepPrompt` model path - build Sweep rewrite-window prompts from the active cursor window, recent change history, and related file excerpts - convert rewrite responses back into anchored edits and suppress no-op rewrites - add fixed cursor-window extraction used by the Sweep rewrite prompt path - recognize `sweep-next-edit` model names during `infer`, including filename-style identifiers such as `sweepai_sweep-next-edit-1.5B_sweep-next-edit-1.5b.q8_0.v2.gguf` - reject reserved Sweep prompt tokens before sending malformed requests to a self-hosted server - update the docs to describe the actual Sweep rewrite-window prompt format Local setup used for manual verification: ```sh llama-server \ --hf-repo sweepai/sweep-next-edit-1.5B \ --hf-file sweep-next-edit-1.5b.q8_0.v2.gguf \ --ctx-size 8192 \ --host 127.0.0.1 \ --port 8080 ``` ```json { "edit_predictions": { "provider": "open_ai_compatible_api", "open_ai_compatible_api": { "api_url": "http://127.0.0.1:8080/v1/completions", "model": "sweepai_sweep-next-edit-1.5B_sweep-next-edit-1.5b.q8_0.v2.gguf", "prompt_format": "infer", "max_output_tokens": 512 } } } ``` The request that produced this PR included screenshots of the OpenAI-compatible provider configuration and the prompt format dropdown with `Sweep` selected. Tests added in this branch: - `test_sweep_prompt_format_routes_to_sweep_prompt_model` - `test_fixed_line_window_around_cursor_start_middle_and_end` - `test_sweep_prompt_request_prediction_diffs_rewritten_window_into_anchored_edits` - `test_sweep_prompt_request_prediction_returns_none_for_identical_rewrite` - `test_original_window_for_current_window_uses_latest_pre_edit_snapshot` - `test_original_window_for_current_window_returns_none_without_matching_history` - `test_recent_change_block_from_event_formats_original_and_updated_sections` Verification run locally: - `cargo test -p zed sweep_prompt_format_routes` - `cargo test -p zed subscribe_uses_stale_provider_config` - `cargo test -p edit_prediction sweep_prompt` - `cargo test -p edit_prediction fixed_line_window_around_cursor_start_middle_and_end` - `cargo test -p edit_prediction test_sweep_prompt_request_prediction_diffs_rewritten_window_into_anchored_edits` - `cargo test -p edit_prediction test_sweep_prompt_request_prediction_returns_none_for_identical_rewrite` - `./script/clippy -p zed -p edit_prediction -p settings_content` Release Notes: - Added support for self-hosted Sweep Next Edit models in OpenAI-compatible edit predictions, including the `sweep` prompt format and `infer` detection for `sweep-next-edit` model names. --------- Co-authored-by: Ben Kunkle <ben@zed.dev> |
||
|
|
36911f8cab
|
docs: Clarify window_decorations currently only works on Linux (#61883)
Also add the setting to our docs at https://zed.dev/docs -- it’s currently missing. Updated a stale comment as well -- window decorations were [always supported on X11](https://github.com/zed-industries/zed/pull/13611)? Closes #61788. --- Release Notes: - N/A |
||
|
|
33f1112fc2
|
theme: Specify color format and pattern in schema (#49136)
## Purpose
While developing a theme for Zed I remarked that the schema available
doesn't mark colors in a way that Zed recognize to display the color
annotations:
```json
{
"$schema": "https://zed.dev/schema/themes/v0.2.0.json"
}
```
<img width="119" height="190" alt="Screenshot 2026-02-25 at 23 15 10"
src="https://github.com/user-attachments/assets/3f1bb703-cb26-4630-9598-3a7cb8873c20"
/>
But Zed has support for it when colors are marked with `"format":
"color"` in the schema:
<img width="127" height="186" alt="Screenshot 2026-02-25 at 23 14 58"
src="https://github.com/user-attachments/assets/1a9387a4-613a-4cf8-a3af-f6ac201bdf54"
/>
So I searched if the schema file was Open Source somewhere, discovered
it was generated from the codebase and attempted the change.
## Implementation
This is essentially done using a `ThemeColor` wrapper for the color
strings that implements `JsonSchema` with a dedicated regex for
validation and the color format specified. This ends up with a new
`$defs` of `Color` being specified and used:
```json
{
"$defs": {
"Color": {
"type": "string",
"format": "color",
"pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{4}|[0-9a-fA-F]{6}|[0-9a-fA-F]{8})$"
}
}
}
```
## Other
- There is a small change I made for testing to the schema_generator
that adds an `--output` / `-o` flag. When provided it writes the
generated schema JSON to the specified file path instead of printing to
stdout. This was done to made testing easier but I can remove it or
split it to a separate PR (It's already a separate commit)
- For this PR to do anything a new schema version will need to be
published at something like `https://zed.dev/schema/themes/v0.3.0.json`
and documentation needs to be updated to point to it.
Before you mark this PR as ready for review, make sure that you have:
- [x] Added a solid test coverage and/or screenshots from doing manual
testing (Manual testing, couldn't find any existing good place to test
it)
- [x] Done a self-review taking into account security and performance
aspects
- [x] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
|
||
|
|
12a19dccef
|
agent: Re-enable sandbox (#61711)
Fixes the bug that made us remove the sandbox. The bug in question was very dumb: - there is sophisticated machinery for detecting whether a user-granted writable path is swapped out for a symlink in the timing gap between approval and sandbox creation - there was no equivalent machinery to do the same for the (much larger) gap between a user *persisting an approval* (either for the current thread or permanently via settings) - The fix is essentially to store canonical (i.e. absolute and symlink-free at all depths) paths as the source of truth, but retain the raw path for display purposes - On WSL, there is extra care needed becasue of the bidirectional mounting (i.e. `/mnt/c/...` and `\\wsl.localhost\Ubuntu\...`). In particular, `/mnt/c/...` paths, since their inodes do not necessarily pin NTFS file references, weaken the sandbox guarantees, and so we need some extra UI to call this out and docs etc... This also does not remove the feature flag, but just toggles it to "enabled_for_all" --- Release Notes: - N/A or Added/Fixed/Improved ... --------- Co-authored-by: Richard Feldman <oss@rtfeldman.com> Co-authored-by: Jakub Konka <kubkon@jakubkonka.com> Co-authored-by: Danilo Leal <daniloleal09@gmail.com> Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com> |
||
|
|
1ca8f8396b
|
Add agent panel font family settings (#59629)
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> |
||
|
|
9a5344b9eb
|
agent: Add agent.compaction_model setting for context compaction (#60012)
# Objective
Add a new `agent.compaction_model` setting that lets users specify a
separate language model for context compaction (`/compact` and
auto-compaction), independent of the thread's active conversation model.
Compaction is just summarization — there's no reason to pay Opus prices
for it when a cheaper model does the job faster. We've also seen
reasoning models misbehave on this task (empty responses, repetition
loops at high effort), so picking a dedicated non-reasoning model for
compaction is useful.
## Solution
- New `compaction_model: Option<LanguageModelSelection>` field in
`AgentSettingsContent` and `AgentSettings`, mirroring
`thread_summary_model`.
- New `compaction_model: Option<ConfiguredModel>` slot on
`LanguageModelRegistry` with `select_/set_/compaction_model()` trio,
mirroring the existing pattern. The setter deliberately does **not**
emit a registry event in v1; callers read the slot lazily at compaction
time.
- New `Thread::compaction_model(&self, cx: &App)` helper that returns
the configured model or falls back to `self.model()`. Two call sites —
`Thread::compact` and `perform_compaction_if_needed` — now go through
this helper instead of reading `self.model()` directly.
- `build_compaction_telemetry` accepts the compaction model explicitly
so the `model` field reflects the model that actually streamed the
request. `max_tokens` still derives from `thread.model()` (threshold
semantics are unchanged).
- Documentation updated at `docs/src/ai/agent-settings.md` (new
user-facing setting).
**Example:**
```json
{
"agent": {
"default_model": {
"provider": "anthropic",
"model": "claude-opus-4-6"
},
"compaction_model": {
"provider": "anthropic",
"model": "claude-sonnet-4-5"
}
}
}
```
**Resolution chain:**
```
agent.compaction_model (if set & available)
→ thread.model() (always available, current behavior)
```
**Behavior change:**
| Trigger | Before | After |
| --- | --- | --- |
| Manual `/compact` | Uses `thread.model()` | Uses
`agent.compaction_model` if set & available; else `thread.model()` |
| Auto-compaction | Uses `thread.model()` | Same as above |
| `/compact` when thread has no model | `NoModelConfiguredError` |
Succeeds if `compaction_model` resolves |
| `compaction_model` configured but provider missing / model id unknown
| n/a | Falls back to `thread.model()` and logs a one-time warning |
**Explicit non-goals:**
- No `Event::CompactionModelChanged`(no consumer; the `_cx` parameter on
`set_compaction_model` is intentionally accepted for future use).
- No GUI selector (consistent with all other feature-specific models).
- No per-profile override.
- No runtime API-error fallback — only config-time failure (provider not
registered, model id not in `provided_models`) triggers fallback. This
matches every other feature-specific model.
- No change to threshold calculation, auto-compact trigger, or
`COMPACTION_PROMPT`.
- No propagation to subagent threads.
## Testing
3 new unit tests in `crates/agent/src/thread.rs::tests`:
- `test_compaction_uses_configured_compaction_model` — manual `/compact`
routes to the configured model; thread's primary model receives no
request; telemetry reflects the configured model.
- `test_compaction_falls_back_when_compaction_model_unavailable` —
configured-but-unresolvable falls back to `thread.model()`; telemetry
reflects the fallback model.
- `test_auto_compaction_uses_compaction_model` — auto-compaction
triggered by threshold honors the same setting.
All 14 existing compaction tests still pass. Test suites in
`crates/agent_settings`, `crates/language_model`,
`crates/settings_content`, `crates/agent_ui` unchanged. `cargo clippy`
clean on the changed crates.
**How reviewers can test:**
1. Add `agent.compaction_model` to `settings.json` with a cheaper model
than the thread's primary model, run `/compact`, observe the cheaper
model receives the request.
2. Set `agent.compaction_model` to a non-existent provider/model id, run
`/compact`, observe fallback to thread model and a `log::warn!` line.
3. Trigger auto-compaction by reaching the threshold, observe it uses
`compaction_model`.
**Platforms tested:** local Linux (cargo check + cargo test on agent /
agent_settings / language_model / settings_content / agent_ui crates).
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments — no `unsafe`
blocks introduced
- [x] The content adheres to Zed's UI standards — N/A: settings-only
change, no UI touched
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable — model
resolution is an O(1) registry lookup, not on any hot path; no new work
in the streaming loop
Release Notes:
- agent: Add support for specifying which model is used for compaction
(`agent.compaction_model`)
---------
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
Co-authored-by: Bennet Bo Fenner <bennet@zed.dev>
|
||
|
|
8276687148
|
Use proper rules for merging language server settings (#61546)
Closes https://github.com/zed-industries/zed/issues/61524 https://github.com/zed-industries/zed/issues/60763 was a bogus issue: the semantic of root `language_settings` is the **default settings for all languages**, not a "magic string that gets applied when an `!x` exclusion is mentioned there". Thus, reverts https://github.com/zed-industries/zed/pull/60984 and redoes https://github.com/zed-industries/zed/pull/60000 in a correct way: more custom settings replace less custom ones, same applies to the language server settings. Instead of doing some odd `!x` manipulations, the right fix is to remove the old state as ```diff impl merge_from::MergeFrom for AllLanguageSettingsContent { fn merge_from(&mut self, other: &Self) { ... self.defaults.merge_from(&other.defaults); for language_settings in self.languages.0.values_mut() { + let language_servers = language_settings.language_servers.take(); language_settings.merge_from(&other.defaults); + language_settings.language_servers = language_servers; } for (language_name, user_language_settings) in &other.languages.0 { if let Some(existing) = self.languages.0.get_mut(language_name) { existing.merge_from(&user_language_settings); } else { let mut new_settings = self.defaults.clone(); + new_settings.language_servers = None; new_settings.merge_from(&user_language_settings); ``` After the final override is determined, `...` is expanded and `!x` entries are removed from the final list. Project settings override user settings, so it's possible that a certain language server is disabled by the user and re-enabled in the project: worktree trust mechanism is supposed to mitigate the security issues. More tests were added to cover all the cases. Release Notes: - Fixed project settings not re-enabling language servers |
||
|
|
8c7811ea72
|
Split VSCode and Zed keymap files (#61532)
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 |
||
|
|
d47347d1aa
|
settings: Fix VS Code import appending duplicate file associations (#61355)
Some checks are pending
Congratsbot / check-author (push) Waiting to run
Congratsbot / congrats (push) Blocked by required conditions
deploy_nightly_docs / deploy_docs (push) Waiting to run
run_tests / orchestrate (push) Waiting to run
run_tests / check_style (push) Waiting to run
run_tests / clippy_windows (push) Blocked by required conditions
run_tests / clippy_linux (push) Blocked by required conditions
run_tests / clippy_mac (push) Blocked by required conditions
run_tests / clippy_mac_x86_64 (push) Blocked by required conditions
run_tests / run_tests_windows (push) Blocked by required conditions
run_tests / run_tests_linux (push) Blocked by required conditions
run_tests / run_tests_mac (push) Blocked by required conditions
run_tests / miri_scheduler (push) Blocked by required conditions
run_tests / doctests (push) Blocked by required conditions
run_tests / check_workspace_binaries (push) Blocked by required conditions
run_tests / build_visual_tests_binary (push) Blocked by required conditions
run_tests / check_wasm (push) Blocked by required conditions
run_tests / check_dependencies (push) Blocked by required conditions
run_tests / check_docs (push) Blocked by required conditions
run_tests / check_licenses (push) Blocked by required conditions
run_tests / check_scripts (push) Blocked by required conditions
run_tests / check_postgres_and_protobuf_migrations (push) Blocked by required conditions
run_tests / extension_tests (push) Blocked by required conditions
run_tests / tests_pass (push) Blocked by required conditions
Closes #56536 ## What & why Running `zed: import vs code settings` more than once kept re-adding the same file extensions to `file_types`, so `files.associations` entries grew without bound: ```json "file_types": { "c": ["*.keymap", "*.keymap", "*.keymap"] } ``` The import merges the VS Code-derived settings into the user's existing settings, and `file_types` values were `ExtendingVec`s, whose `merge_from` appends every incoming value unconditionally. Per review feedback, instead of changing `ExtendingVec`'s merge semantics (it also backs ssh/wsl connections, `private_files`, etc.), this adds a new `ExtendingSet` type that actually behaves like a set, and switches `FileTypeMap`'s file associations to it: - Backed by an insertion-order-preserving `IndexSet`, so users' pattern order round-trips through the settings file unchanged (the import machinery diffs serialized old/new content to produce edits; a sorted set would reorder existing arrays). - Merging only accumulates new values, so re-importing an already-present association is a no-op. - Since it's a real set, deserialization also collapses duplicates that earlier imports already wrote into the settings file. - `ExtendingVec` and all its other users are untouched. ## Testing - Added a `test_vscode_import` case that re-imports an already-present `files.associations` entry and asserts the extension isn't duplicated. It fails before the change and passes after. - `cargo test -p settings -p settings_content -p language` pass. - `./script/clippy -p settings -p settings_content -p language -p recent_projects -p json_schema_store` is clean. Release Notes: - Fixed importing VS Code settings repeatedly adding duplicate `file_types` entries for `files.associations`. --------- Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com> |
||
|
|
c4c55bade4
|
Add wrapper type for language servers in settings (#61398)
Some checks are pending
Congratsbot / check-author (push) Waiting to run
Congratsbot / congrats (push) Blocked by required conditions
deploy_nightly_docs / deploy_docs (push) Waiting to run
run_tests / tests_pass (push) Blocked by required conditions
run_tests / orchestrate (push) Waiting to run
run_tests / check_style (push) Waiting to run
run_tests / clippy_windows (push) Blocked by required conditions
run_tests / clippy_linux (push) Blocked by required conditions
run_tests / clippy_mac (push) Blocked by required conditions
run_tests / clippy_mac_x86_64 (push) Blocked by required conditions
run_tests / run_tests_windows (push) Blocked by required conditions
run_tests / run_tests_linux (push) Blocked by required conditions
run_tests / run_tests_mac (push) Blocked by required conditions
run_tests / miri_scheduler (push) Blocked by required conditions
run_tests / doctests (push) Blocked by required conditions
run_tests / check_workspace_binaries (push) Blocked by required conditions
run_tests / build_visual_tests_binary (push) Blocked by required conditions
run_tests / check_wasm (push) Blocked by required conditions
run_tests / check_dependencies (push) Blocked by required conditions
run_tests / check_docs (push) Blocked by required conditions
run_tests / check_licenses (push) Blocked by required conditions
run_tests / check_scripts (push) Blocked by required conditions
run_tests / check_postgres_and_protobuf_migrations (push) Blocked by required conditions
run_tests / extension_tests (push) Blocked by required conditions
This is in preparation for making configuration of language servers more comfortable for users/extensions. Release Notes: - N/A |
||
|
|
54c5db8346
|
Disable LSP for files with very long lines (#61447)
Release Notes: - Fixed ui stutters when opening large single line files like minified javascript due to running LSP requests against them |
||
|
|
e80cdd2ff7
|
Autocomplete language names in file_types setting (#58595)
## Context Closes #58571 When editing `settings.json`, typing a new key under `languages` triggers language-name autocomplete. The same did not work for `file_types`, even though both keys map language names to configuration. The root cause: the JSON schema generator uses `replace_subschema` to inject installed language names as the allowed properties of a named type. The `languages` field backed by `LanguageToSettingsMap` (a named newtype) got this treatment; `file_types` was backed by a raw `HashMap<Arc<str>, ExtendingVec<String>>` with no named type to target. The fix introduces a `FileTypeMap` newtype parallel to `LanguageToSettingsMap` and wires it into the same schema-injection path. Video of manual test below : [Screencast from 2026-06-05 00-04-16.webm](https://github.com/user-attachments/assets/5d8afb60-d566-4c99-ad2a-66ebbb47ed2e) ## How to Review - `crates/settings_content/src/language.rs` : Adds `FileTypeMap(HashMap<Arc<str>, ExtendingVec<String>>)` with the full set of derives (`Debug`, `Clone`, `Default`, `PartialEq`, `Serialize`, `Deserialize`, `JsonSchema`, `MergeFrom`) and an `IntoIterator for &FileTypeMap` impl so existing call sites (`all_languages.file_types.iter().flatten()`) continue to work without changes. Changes the `file_types` field in `AllLanguageSettingsContent` from the raw HashMap to `Option<FileTypeMap>`. - `crates/settings/src/settings_store.rs` : In `configure_schema_generator`, adds a `replace_subschema::<FileTypeMap>` call mirroring the existing `LanguageToSettingsMap` one: injects installed language names as the allowed properties, with `ExtendingVec<String>` (array of glob patterns) as the value schema. Adds `test_file_types_schema_generation` to verify the injected properties. - `crates/settings/src/vscode_import.rs` : Updates `file_types()` to return `Option<FileTypeMap>` and wraps the constructed map accordingly. - `crates/language/src/buffer_tests.rs` : Updates the existing custom `file_types` test setup to extend the inner map of the new `FileTypeMap` wrapper explicitly, keeping the language crate test build passing after the type change. ## 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 language name autocomplete not working in the `file_types` setting --------- Co-authored-by: Kirill Bulatov <kirill@zed.dev> |
||
|
|
34bfb3842d
|
title_bar: Add show_worktree_name setting (#61137)
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> |
||
|
|
ba1990441d
|
git_ui: Show full files by default in solo diffs (#60989)
# 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. |
||
|
|
fee12a7c3f
|
bedrock: Add GPT-5.6 Sol, Terra, and Luna Mantle models (#61008)
# Objective - Adds the three GPT-5.6 models (Sol, Terra, and Luna) that OpenAI now serves through AWS Bedrock's `bedrock-mantle` endpoint, so they can be selected as built-in models under the Amazon Bedrock provider. - Follows up on the native Bedrock Mantle support added in #60480. - Addresses the feature request in https://github.com/zed-industries/zed/discussions/61003. ## Solution - Adds `Gpt5_6Sol`, `Gpt5_6Terra`, and `Gpt5_6Luna` variants to `MantleModel` in `crates/bedrock/src/models.rs`, with per-model `id`/`request_id`/`display_name` and shared capability arms. - All three are Responses-API, `bedrock-mantle`-only models, so they reuse the existing Mantle request/response plumbing, region gating, bearer-token auth, and model-picker wiring (`MantleModel::iter()`) with no other changes required. - Metadata mirrors the AWS Bedrock model cards ([Sol](https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-openai-gpt-56-sol.html), [Terra](https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-openai-gpt-56-terra.html), [Luna](https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-openai-gpt-56-luna.html)): 272K context window, image input, tool and thinking support, and `openai.gpt-5.6-{sol,terra,luna}` request IDs. - Updates the Amazon Bedrock section of "Use a Gateway" to mention the GPT-5.6 family. ## Testing - `cargo test -p bedrock` — adds `test_gpt_5_6_mantle_model_metadata` and extends `test_builtin_mantle_models_use_responses_protocol`; all pass. - `cargo test -p language_models mantle` — the consumer crate compiles and all Mantle tests pass. - `./script/clippy -p bedrock` passes with no new warnings; docs pass `prettier --check`. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments — N/A, no unsafe code - [x] The content adheres to Zed's UI standards — N/A, no UI change - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - Added GPT-5.6 Sol, Terra, and Luna models to the Amazon Bedrock provider via the `bedrock-mantle` endpoint. --------- Co-authored-by: Anant Goel <anant@zed.dev> |
||
|
|
63692b8b47
|
search: Add LSP location pickers for references, definitions, and diagnostics (#59838)
# 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. |
||
|
|
ba0eea3f49
|
settings_content: Fix globally excluded language servers starting (#60984)
Closes https://github.com/zed-industries/zed/issues/60763 Follow-up to #60000. Global language server exclusions were added to per-language settings without removing an explicit enable for the same server, allowing it to still start. For example, this setting should disable `vtsls` for every language: ```json { "language_servers": ["!vtsls", "..."] } ``` However, TypeScript’s default configuration explicitly enables `vtsls`, causing it to still start. Release Notes: - Fixed language servers starting despite being disabled globally. |
||
|
|
d06ebb7c03
|
Disable all spinners in Zed (#60614)
Closes https://github.com/zed-industries/zed/pull/48577 Part of https://github.com/zed-industries/zed/issues/8043 See https://zed-industries.slack.com/archives/C07NUKHLVUZ/p1783335475957139 for context. Release Notes: - Allow to reduce animations with `"reduce_motion": "on"` settings |
||
|
|
2268045a11
|
a11y: Landmarks and menu improvements (#60397)
Fixes menu a11y, and adds landmarks with `F6`-navigation. Also fixes a GPUI bug, and adds debug actions for dumping a11y tree info. Since `F6` was already in use by the pause debugger keybind, also tightens up the debugger keybind context so they require an active debugger session. When there is one active, `F6` stays as pause debugger. `ctrl-F6` always works to go to the next landmark. Also adds an "accessible mode" setting. Currently, this only controls whether we show all menus all the time, but I suspect it will expand significantly in the future. Also adds `.aria_keyshortcuts()` API, but it's not wired up within accesskit adapters, so is not yet reported to screen readers. --- Release Notes: - N/A or Added/Fixed/Improved ... |
||
|
|
65e1c5af25
|
git_panel: Add group by staging view option (#59884)
Some checks are pending
run_tests / orchestrate (push) Waiting to run
run_tests / check_style (push) Waiting to run
run_tests / clippy_windows (push) Blocked by required conditions
run_tests / clippy_linux (push) Blocked by required conditions
run_tests / clippy_mac (push) Blocked by required conditions
run_tests / clippy_mac_x86_64 (push) Blocked by required conditions
run_tests / run_tests_windows (push) Blocked by required conditions
run_tests / run_tests_linux (push) Blocked by required conditions
run_tests / run_tests_mac (push) Blocked by required conditions
Congratsbot / check-author (push) Waiting to run
Congratsbot / congrats (push) Blocked by required conditions
deploy_nightly_docs / deploy_docs (push) Waiting to run
run_tests / check_workspace_binaries (push) Blocked by required conditions
run_tests / check_scripts (push) Blocked by required conditions
run_tests / check_licenses (push) Blocked by required conditions
run_tests / miri_scheduler (push) Blocked by required conditions
run_tests / doctests (push) Blocked by required conditions
run_tests / build_visual_tests_binary (push) Blocked by required conditions
run_tests / check_wasm (push) Blocked by required conditions
run_tests / check_dependencies (push) Blocked by required conditions
run_tests / check_docs (push) Blocked by required conditions
run_tests / check_postgres_and_protobuf_migrations (push) Blocked by required conditions
run_tests / extension_tests (push) Blocked by required conditions
run_tests / tests_pass (push) Blocked by required conditions
# Objective - Add a view option for group by staging. ## Solution - Add a new option for group_by under git_panel view options, with 2 sections "Staged" and "Unstaged", with buttons (+/-) to stage and unstage ## Testing - cargo check -p git_ui ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable ## Showcase <img width="1679" height="1140" alt="Screenshot 2026-06-25 at 2 09 44 PM" src="https://github.com/user-attachments/assets/1b605cad-7792-4823-983c-ada41be25504" /> --- Release Notes: - Added group by staging view option --------- Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com> |
||
|
|
8f92822cbf
|
agent: Sandbox security review and docs update (#60291)
Closes security loopholes and updates docs: - installs seccomp filter for blocking naughty syscalls - tightens macos seatbelt profile - fetch tool responses that redirect are now constrained by allowed domains list Also adds a few "Learn More" buttons that link to the new docs. Also fixes a bug where the agent would try to create a `~/.config/zed/AGENTS.md` directory Also adds unicode confusable detection to URL/path privilege escalation prompts. --- Release Notes: - N/A or Added/Fixed/Improved ... --------- Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com> |
||
|
|
bd2e879213
|
anthropic: Allow configured models to opt into fast mode (#58225)
Adds support for enabling Anthropic fast mode on configured models. Previously, Anthropic models configured through `language_models.anthropic.available_models` were always marked as not supporting fast mode, so `speed: "fast"` would be stripped before sending requests even when the configured model supported Anthropic fast mode. This adds an optional `supports_fast_mode` field to configured Anthropic models. When enabled, the model is marked as supporting fast mode and the required Anthropic beta header is added automatically. Built-in fast-mode model detection remains the fallback when the setting is omitted. Testing: - `cargo fmt --package anthropic --package language_models --package settings_content` - `cargo test -p language_models available_model --lib` - `cargo test -p anthropic from_listed_enables_fast_mode --lib` - `cargo check -p language_models` - Manual: verified in a local build that a configured Anthropic model can send fast mode requests correctly. Release Notes: - agent: Allow specifying if fast mode is supported for custom anthropic models Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de> |
||
|
|
b9f3396b68
|
Add support for format_on_save only changed lines (#49964)
## 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> |
||
|
|
f5c975162c
|
terminal: Open links with Cmd/Ctrl-click when mouse mode is enabled (#60067)
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> |
||
|
|
d12b980ee0
|
bedrock: Add native support for Bedrock Mantle models (#60480)
Adds native support for AWS Bedrock's Mantle endpoint (`bedrock-mantle`), which serves models with no `Converse`/`Invoke` support on `bedrock-runtime`, such as GPT-5.5, GPT-5.4, and Grok 4.3 but more importantly **open-weight** models Closes #60471 ## What's changed - Renamed the existing `Model` enum in the `bedrock` crate to `ConverseModel`, and added a new `MantleModel` enum for Mantle-only models. Mantle models reuse the existing OpenAI-compatible Chat Completions/Responses request and response plumbing (`into_open_ai`/`into_open_ai_response`, `OpenAiEventMapper`/`OpenAiResponseEventMapper`) already used by the native OpenAI and OpenAI-compatible providers, rather than introducing new marshalling code. - Added a `BedrockMantleModel` language model that routes requests to the `bedrock-mantle` endpoint, dispatching to Chat Completions or the Responses API depending on the model. Mantle models appear in the model picker alongside Converse models under the same Bedrock provider. - Added region gating: `bedrock-mantle` is only available in a subset of AWS Regions, so using a Mantle model outside of them surfaces a clear error naming the current Region and the supported ones, instead of an opaque HTTP failure. - Implemented Bedrock bearer token authentication for Mantle requests: a configured Bedrock API key is used as-is, and every other auth method (IAM credentials, named profile, SSO, automatic) derives a short-term token by locally SigV4-presigning a `CallWithBearerToken` request. This requires no extra network round trip and no token caching, since re-signing locally is cheap. - Added a specific error for the 403 you get when your credentials have `bedrock:CallWithBearerToken` but not the separate `bedrock-mantle:CallWithBearerToken` permission Mantle models require, since this is the most common misconfiguration. - Added a `mantle_available_models` setting so custom models served through `bedrock-mantle` can be configured, the same way other providers support custom models via `available_models`. - Documented Mantle models and the new setting in the Amazon Bedrock section of [Use a Gateway](https://zed.dev/docs/ai/use-a-gateway#amazon-bedrock). ## Testing - Added unit tests covering: the local SigV4 bearer-token signing (including a byte-for-byte cross-check against a reference implementation), Mantle endpoint URL construction, the Mantle-supported-regions list, thinking-effort normalization, and the settings-to-model protocol mapping. - `cargo test -p bedrock -p language_models -p settings_content -p settings` passes. - `./script/clippy` passes with no new warnings. Release Notes: - Added native support for AWS Bedrock's Mantle endpoint, enabling GPT-5.5, GPT-5.4, and Grok 4.3 through the Amazon Bedrock provider. |
||
|
|
452e1cb273
|
opencode: Model updates + fixes (#60526)
**TL;DR**: model updates + reasoning levels + fixes discovered when working on https://github.com/zed-industries/zed/pull/60373 # Objective Since the model auto-discovery PR was [cancelled](https://github.com/zed-industries/zed/pull/60373#issuecomment-4886521448), here is a manual model list update! I also copied the stand-alone bugfixes/enhancements from that PR. ## Solution A lot of manual work 😅 **OpenCode Zen**: - added Fable 5 and Sonnet 5 - added models that were previously only available on OpenCode Go: GLM 5.2, Kimi K2.7 Code, and Minimax M3 - added reasoning levels for all models. I started from the data on [`Models.dev`](https://models.dev) (the `/api.json` raw data), and then I matched that with what is shown in the OpenCode CLI and what I know to be true **OpenCode Go**: - added reasoning levels for GLM 5.2 **OpenCode in general**: - added `protocol` validation for the settings, by moving from a random `String` to an `enum`, for both nicer error messages (random strings or typos will get an error instead of using `openai_chat` by default) and to avoid issues like [folks saying non-existent protocols are a thing](https://github.com/zed-industries/zed/issues/56869#issuecomment-4550154554) - enabled parallel tool calls by default. As per [OpenCode developer on Discord](https://discord.com/channels/1391832426048651334/1471233160993050918/1472020924881702912), _"almost all models worth using support parallel tool calling natively"_. Manual tests confirmed all OpenCode Go models support this correctly (and was enabled by default on the OpenCode side for all but 1 model). I initially wanted to skip this from the release notes, but I added it so folks are aware of it in case any issues are caused by this being enabled for all models - allegedly fixed Google thinking since reasoning levels / thinking effort levels were added for Google models and an auto-checker LLM highlighted that was not properly configured - added support for the new-ish `supports_disabling_thinking` so thinking-only models don't get a no-impact toggle to disable thinking I have no idea if any of the Free models will disappear in 2 days or not, so I did not update those 🤷 (as per decision in https://github.com/zed-industries/zed/issues/56869#issuecomment-4466637648) ## Testing The Zen and Google changes were not tested as I don't have a Zen subscription and I stubbornly refuse to get one. The Free&Go changes were tested by running a "_rename this variable for me. add a function. delete the function_" test with a few different models. ## 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: - Agent: OpenCode settings now validate `protocol` values - Agent: OpenCode only shows the "Disable thinking" toggle if thinking can indeed be disabled/enabled - Agent: OpenCode models now enable parallel tool calls by default - Agent: Updated OpenCode Zen models (added Fable 5, Sonnet 5, GLM 5.2, Kimi K2.7 Code, and Minimax M3) - Agent: Added OpenCode Go GLM 5.2 reasoning effort levels - Agent: Added reasoning effort levels for all OpenCode Zen models - Agent: Fixed thinking for OpenCode Zen Google models |
||
|
|
f961889ad4
|
Fix excluded language servers starting nonetheless (#60000)
Despite the default Zed settings containing an exclusion for
`typescript-language-server`
|
||
|
|
21d66eb9d5
|
settings: Remove unused message_editor setting (#60260)
Used this at one point when we still had chat in Collab, but now it's unused. Release Notes: - N/A |
||
|
|
995e56d263
|
markdown_preview: Use UI font for base font size (#60212)
Some checks are pending
Congratsbot / check-author (push) Waiting to run
Congratsbot / congrats (push) Blocked by required conditions
deploy_nightly_docs / deploy_docs (push) Waiting to run
run_tests / orchestrate (push) Waiting to run
run_tests / check_style (push) Waiting to run
run_tests / clippy_windows (push) Blocked by required conditions
run_tests / clippy_linux (push) Blocked by required conditions
run_tests / clippy_mac (push) Blocked by required conditions
run_tests / clippy_mac_x86_64 (push) Blocked by required conditions
run_tests / run_tests_windows (push) Blocked by required conditions
run_tests / run_tests_linux (push) Blocked by required conditions
run_tests / run_tests_mac (push) Blocked by required conditions
run_tests / miri_scheduler (push) Blocked by required conditions
run_tests / doctests (push) Blocked by required conditions
run_tests / check_workspace_binaries (push) Blocked by required conditions
run_tests / build_visual_tests_binary (push) Blocked by required conditions
run_tests / check_wasm (push) Blocked by required conditions
run_tests / check_dependencies (push) Blocked by required conditions
run_tests / check_docs (push) Blocked by required conditions
run_tests / check_licenses (push) Blocked by required conditions
run_tests / check_scripts (push) Blocked by required conditions
run_tests / check_postgres_and_protobuf_migrations (push) Blocked by required conditions
run_tests / extension_tests (push) Blocked by required conditions
run_tests / tests_pass (push) Blocked by required conditions
This PR makes the `markdown_preview_font_size` setting be based on the UI font size instead of the buffer UI font size. I typically use a much smaller code font than UI font, and that made reading the markdown preview super small. I don't think this will be uncommon because the dimensions between mono and non-mono typefaces are different... Release Notes: - Changed the markdown preview to fall back to the UI font size instead of the buffer font size when `markdown_preview_font_size` is unset. |
||
|
|
3648fe6f19
|
agent: Sandboxing polish (#60173)
Removes git sandbox feature The reason is essentially: - write access to a `.git` dir can be trivially escalated to unsandboxed access - therefore, it is misleading to offer git access separate from unsandboxed access - instead, we encourage the model to use `--no-optional-locks` to avoid needing write access to `git status`, etc. Adds sandboxing to fetch tool --- Release Notes: - N/A or Added/Fixed/Improved ... --------- Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com> |
||
|
|
df33d78661
|
cli: Always open new window when cli_default_open_behavior=new_window (#59415)
Some checks are pending
Congratsbot / check-author (push) Waiting to run
Congratsbot / congrats (push) Blocked by required conditions
deploy_nightly_docs / deploy_docs (push) Waiting to run
run_tests / check_workspace_binaries (push) Blocked by required conditions
run_tests / orchestrate (push) Waiting to run
run_tests / check_style (push) Waiting to run
run_tests / clippy_windows (push) Blocked by required conditions
run_tests / clippy_linux (push) Blocked by required conditions
run_tests / clippy_mac (push) Blocked by required conditions
run_tests / clippy_mac_x86_64 (push) Blocked by required conditions
run_tests / run_tests_windows (push) Blocked by required conditions
run_tests / run_tests_linux (push) Blocked by required conditions
run_tests / run_tests_mac (push) Blocked by required conditions
run_tests / miri_scheduler (push) Blocked by required conditions
run_tests / doctests (push) Blocked by required conditions
run_tests / build_visual_tests_binary (push) Blocked by required conditions
run_tests / check_wasm (push) Blocked by required conditions
run_tests / check_dependencies (push) Blocked by required conditions
run_tests / check_docs (push) Blocked by required conditions
run_tests / check_licenses (push) Blocked by required conditions
run_tests / check_scripts (push) Blocked by required conditions
run_tests / check_postgres_and_protobuf_migrations (push) Blocked by required conditions
run_tests / extension_tests (push) Blocked by required conditions
run_tests / tests_pass (push) Blocked by required conditions
This makes sure that the behaviour of the CLI matches that of the UI. In Zed itself we always open a new window (e.g. when clicking on Open Project in new window in the recent projects picker), but in the CLI we where re-using existing windows even when specifying "cli_default_open_behavior": "new_window". This caused confusion, so this PR ensures that we always open a new window, even if that folder is already open. We still focus the active window in the case where the path is a subpath of a project that is already open. Can be tested with ``` cd crates/cli cargo run -- --zed ../../target/debug/zed somefolder ``` Release Notes: - cli: Ensure `zed somefolder` always opens a new window, even when `cli_default_open_behavior` is set to `new_window` and the project is already open |
||
|
|
3856272188
|
agent: Add commit message project rules toggle (#56867)
This follows up on discussion #56551. Right now, when Zed generates a commit message, it includes project rules files like `AGENTS.md`, `CLAUDE.md`, and `.rules` in the prompt alongside the git diff. That can add a lot of extra context for a task that is really just summarizing the changes in a commit. This PR adds an `include_project_rules` option to `agent.commit_message_model`. When it is set to `false`, Zed skips loading project rules when generating commit messages. If the option is omitted, the current behavior stays the same. Example: ```json { "agent": { "commit_message_model": { "provider": "anthropic", "model": "claude-3-5-haiku", "include_project_rules": false } } } ``` I also updated the settings plumbing so this option is only used for commit message generation and defaults to true when not specified. 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 Release Notes: - agent: Added setting to exclude project rules files from commit message generation prompts (`agent.commit_message_include_project_rules`) --------- Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de> |
||
|
|
45015f89d7
|
acp: Support boolean ACP config options (#59698)
Still behind a feature flag until the RFD is completed. Release Notes: - N/A --------- Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com> |
||
|
|
3bb922014e
|
language_models: Rename llama.cpp provider ID (#60112)
Release Notes: - N/A |
||
|
|
4b119fc547
|
Add llama.cpp as a language model provider (#59964)
Hi there, I'm Celina from Hugging Face! Opening this PR to add [llama.cpp](https://llama.app) as a model provider # Objective Today Zed users running llama.cpp have to fall back to the generic OpenAI-compatible provider, which means no auto-discovery (the router mode (`llama serve`) discovers models from the cache and loads them on demand) and manual configuration of every model and its capabilities. This PR makes `llama.cpp` a first-class provider with the same auto-discovery experience. ## Solution - Add a `llama_cpp` client crate with the OpenAI-compatible chat types (`/v1/chat/completions`, including `reasoning_content`) and the discovery types (`/v1/models`, `/props`), mirroring the existing `ollama` crate. - Add the provider in `crates/language_models/src/provider/llama_cpp.rs`, modeled on the Ollama provider (settings, configuration view, event mapping). - Auto discover served models and their context length and tool/vision support from `/props`. Set `auto_discover: false` to list models manually instead. - An unloaded model can't be inspected without loading it, so it is listed with optimistic defaults (large context, tools enabled) and is usable from the first message; its real context length and tool support are filled in once it loads. These live behind a shared map, so a model already selected in an open conversation picks them up without being re-selected. - Show load progress. The provider subscribes to `/models/sse` and surfaces each model's load progress (e.g. "Loading weights 42%") in its display name, reconciling stale labels against `/v1/models`. Builds without `/models/sse` degrade gracefully - no progress, and no capability refresh after the initial discovery. - Add settings (`api_url`, `auto_discover`, `available_models` with per-model `max_tokens` / `supports_tools` / `supports_images`, `context_window`, `custom_headers`), the provider icon, a `default.json` entry, and documentation under "Use a Local Model". No new dependencies: the crate reuses existing workspace dependencies, and shared state uses `std::sync::RwLock`. ## Testing - Unit tests in both new crates cover wire/response parsing, model discovery for single-model and router shapes, the cold-start optimistic defaults, the in-place capability refresh once a model loads, and the `/models/sse` event handling (state changes, load failure, load progress). - Built Zed locally and ran it against a local `llama serve` router: confirmed models are discovered without manual configuration, that the first message works before a model has finished loading, that load progress is shown in the model's display name while it loads, and that the reported context length and tool support refine to the model's real values once it finishes loading. - Platforms: tested on macOS (Apple Silicon). ## 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 The generation speed (tokens/sec) depends on the machine you're running the model, here it's a Apple M3 Max 64GB running a 4-bit quant of https://huggingface.co/Qwen/Qwen3.5-35B-A3B. For the load progress status, make sure to upgrade your llama.cpp version to the latest build. https://github.com/user-attachments/assets/0254f6ef-abe9-42ed-810b-ef1a5b8fa3bd --- Release Notes: - Added llama.cpp as a language model provider --------- Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com> |
||
|
|
f2006b20ac
|
git: Allow showing inline blame in the status bar (#59696)
# Add status bar location for inline git blame ## Objective - Closes #12133 by implementing the VS Code-like behavior for status bar git blame ## Solution Adds a VS Code–style option to render the current-line git blame in the status bar instead of inline at the cursor. Whats new - A new location setting: Under the inline_blame configuration, you can now choose between two options: - `inline` (Default) — Keeps things exactly as they are, showing the blame details at the end of your current line. - `status_bar` — Moves the blame info down to the bottom status bar. - The Status Bar Item: When you choose the status bar option, a clean new button appears at the bottom left of your window. It features a Git icon, the author's name, how long ago the change was made, and the commit summary - Behaves as it does before, but displayed at a different location - Clicking the status bar item will instantly open up the full Git commit details like at vscode - Settings UI: - The "Location" control is now a `DynamicItem` nested under "Enabled", so it only appears when inline blame is enabled. - Registers a dropdown renderer for `InlineBlameLocation`. - Updates `all-settings.md` and `visual-customization.md` for the new option. ## Testing - Manually tested both modes by toggling `git.inline_blame.location` between `inline` and `status_bar`: - `inline` keeps the existing behavior unchanged. - `status_bar` shows the blame for the focused line in the status bar, hides the inline blame, updates on cursor movement, clears when no editor is focused, and opens the blame commit on click. - Verified the settings UI shows the "Location" dropdown only when inline blame is enabled. - Tested with `show_commit_summary` toggled when location is `status_bar` (for inline location, nothing is changed) Areas that could use more testing: - Remote (collab) editors ? Reviewers can test by setting the following in `settings.json` and moving the cursor across blamed lines: ```json { "git": { "inline_blame": { "enabled": true, "location": "status_bar" } } } ``` ## Showcase <details> <summary>Click to view showcase</summary> ### Video https://github.com/user-attachments/assets/6d9f490d-7bf3-473c-9562-8351546dfaf9 ### Screenshots <img width="894" height="749" alt="image" src="https://github.com/user-attachments/assets/c6a49008-899d-4a0c-9098-1ffb9e28252b" /> </details> Release Notes: - Added a `git.inline_blame.location` setting to render current-line git blame in the status bar instead of inline. |
||
|
|
46ff888db8
|
markdown_preview: Add font size settings and actions (#55489)
Add support for scaling the Markdown preview's body text and headings with `cmd-=` / `cmd--` / `cmd-0`. Previously these shortcuts only resized code blocks because the preview's body used `ui_font_size` and headings used a rem-based scale anchored to it, while the keybindings only mutated `BufferFontSize`. The preview's scroll subtree is now wrapped in `WithRemSize(buffer_font_size)`, so `1rem` resolves to the buffer font size inside the preview. Body text, headings (`text_3xl`/`text_2xl`/...), and rem-based spacing all scale together. The outer focus root and scrollbar remain at the UI font size. 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 #55374 Release Notes: - Added `markdown_preview_font_size` setting and actions to scale Markdown preview font size separately from the editor. --------- Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com> |
||
|
|
7187d65774
|
language_models: Set support_thinking in Responses API for OpenAI-compatible provider (#59213)
# Objective Fix OpenAI-compatible reasoning/thinking support. Previously, `OpenAiCompatibleLanguageModel` never reported thinking support, so configured `reasoning_effort` values did not reliably reach the wire and Responses API reasoning state could miss `include: ["reasoning.encrypted_content"]`. Fixes #58289 Addresses #59207 for OpenAI-compatible Responses models configured with `reasoning_effort`. ## Solution - Treat a non-`none` configured `reasoning_effort` as OpenAI-compatible thinking support. - Expose common OpenAI-style effort levels in the agent UI, using the configured effort as the default. - Honor selected reasoning effort for OpenAI-compatible chat-completions requests. - Send `reasoning_effort: "none"` when thinking is disabled for a configured reasoning model. - Preserve native OpenAI behavior by continuing to use native model-specific supported efforts and `max_completion_tokens`. - Add an OpenAI-compatible `max_tokens_parameter` capability for endpoints that expect output limits as `max_tokens`. - Parse common streamed thinking fields (`reasoning` and `reasoning_content`). - Add provider setup UI and docs for configuring OpenAI-compatible reasoning models. ## Testing - `cargo fmt -p language_model_core -p agent_ui -p language_models` - `cargo test -p language_models provider::open_ai_compatible::tests --lib` - `cargo test -p language_models provider::open_ai::tests --lib` - `cargo test -p open_ai completion::tests --lib` - `cargo test -p agent_ui agent_configuration::add_llm_provider_modal::tests --lib` - `git --no-pager diff --check` ## 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: - Improved OpenAI-compatible provider setup for reasoning models. --------- Co-authored-by: Anant Goel <anant@zed.dev> |
||
|
|
eea5f57dc5
|
Allow sandboxed Git writes from worktrees (#57981)
Agent terminal sandboxing now protects `.git` metadata by default and exposes an explicit `allow_git_access` approval. Without it, file contents of the `.git` directories for opened worktrees and discovered repositories (including a linked worktree's common `.git`) cannot be read or written, though their metadata stays visible; when approved, those Git directories become writable so commands like fetch/commit work. SSH commit signing keeps working because the inherited `SSH_AUTH_SOCK` is allowed as local Unix-socket IPC, which does not let sandboxed commands send network packets to other machines. The Seatbelt profile also allows PTY terminal-control ioctls so signing/passphrase prompts can manage terminal state. This intentionally restricts only `.git` itself (whose location we know exactly, including the worktree case) rather than `.gitignore`/`.gitattributes`/`.gitmodules`, since those can be nested arbitrarily and the goal is to keep the policy expressible as a plain deny-by-default allowlist that will port to Linux and Windows sandboxes later. Closes AI-334 Release Notes: - Improved agent terminal sandboxing for Git metadata, Git worktrees, and SSH commit signing. |
||
|
|
037f32aef0
|
Refine agent terminal sandbox off-switch and expand WSL env blocklist (#59520)
Follow-ups to the recently-landed agent terminal sandboxing work. - Make the persistent "Allow Unsandboxed Terminal Commands" setting (`allow_unsandboxed`) the single off-switch for the agent terminal sandbox: when enabled, the sandboxed terminal tool isn't exposed and the system prompt omits the sandbox section, so the model uses the plain `terminal` tool (and on Windows, WSL sandbox setup is skipped). This removes the dead, unwired `disabled` setting that was meant to do the same thing but had no UI, writer, or docs. Per-command and per-thread `unsandboxed: true` grants are unchanged. - Expand the blocklist of Windows-specific environment variables that aren't forwarded into the WSL sandbox (system locations, `HOME`/profile paths, host/session identity, CPU descriptors, etc.) so they can't shadow or break Linux commands. It stays a blocklist, so portable variables like `LANG` still reach the command. Release Notes: - N/A |
||
|
|
514b14ed49
|
git_ui: Add setting to control default click behavior for git panel (#59649)
Some checks are pending
Congratsbot / check-author (push) Waiting to run
Congratsbot / congrats (push) Blocked by required conditions
deploy_nightly_docs / deploy_docs (push) Waiting to run
run_tests / orchestrate (push) Waiting to run
run_tests / check_style (push) Waiting to run
run_tests / clippy_windows (push) Blocked by required conditions
run_tests / clippy_linux (push) Blocked by required conditions
run_tests / clippy_mac (push) Blocked by required conditions
run_tests / clippy_mac_x86_64 (push) Blocked by required conditions
run_tests / run_tests_windows (push) Blocked by required conditions
run_tests / run_tests_linux (push) Blocked by required conditions
run_tests / run_tests_mac (push) Blocked by required conditions
run_tests / miri_scheduler (push) Blocked by required conditions
run_tests / doctests (push) Blocked by required conditions
run_tests / check_workspace_binaries (push) Blocked by required conditions
run_tests / build_visual_tests_binary (push) Blocked by required conditions
run_tests / check_wasm (push) Blocked by required conditions
run_tests / check_dependencies (push) Blocked by required conditions
run_tests / check_docs (push) Blocked by required conditions
run_tests / check_licenses (push) Blocked by required conditions
run_tests / check_scripts (push) Blocked by required conditions
run_tests / check_postgres_and_protobuf_migrations (push) Blocked by required conditions
run_tests / extension_tests (push) Blocked by required conditions
run_tests / tests_pass (push) Blocked by required conditions
# Objective The current behavior of the git panel is that when you click a file it will open the multi-buffer view that shows all files with changes. If you use CMD+Click or CTRL+Click, it will open the solo-file experience where you only see the diff of the file you have selected. But, there is no way to customize this behavior. Related to: https://github.com/zed-industries/zed/pull/56152#issuecomment-4641971669 ## Solution This MR adds a setting that allows you to customize the default click behavior. The alternate behavior will always be accessible via CMD+Click or CTRL+Click. ## 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 a setting to control default click behavior for git panel files --------- Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com> |
||
|
|
076fd14c88
|
git_panel: Add better view options (#59043)
Self-Review Checklist: - [x] I have reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed 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 ## Summary This updates the Git Panel view controls so the panel can independently model: - whether entries are shown as a list or tree - whether flat entries are sorted by path or name - whether entries are grouped by status or shown as one combined set It also keeps the Project Diff order consistent with the Git Panel, including tree ordering, status grouping, and flat name/path sorting. ## Why This Is Useful The previous sort_by_path boolean overloaded two separate ideas: sorting and grouping. That made it hard to represent the view users actually wanted, especially a single tree where tracked and untracked files are not split into separate sections. This change replaces that boolean with explicit enum settings: - git_panel.sort_by: path or name - git_panel.group_by: none or status That keeps the settings mutually exclusive, easier to extend, and closer to the UI model. ## Implementation Notes - Adds a dedicated Git Panel View Options menu using the sliders icon. - Moves view, sort, and group controls out of the overflow actions menu. - Disables sort options in tree view because tree order is folder-first rather than pure path/name sorting. - Removes the Tracked heading when grouping is disabled. - Keeps Git Panel tree expansion state when switching view options. - Recomputes Project Diff sort prefixes from tree_view, sort_by, and group_by so diff cards follow the same top-to-bottom order as the Git Panel. - Preserves Project Diff open/closed file state across view option changes by carrying fold state by repo path instead of by synthetic sort key. - Updates settings UI renderers and docs for the new enum settings. ## Testing - [x] cargo fmt --package git_ui --package settings_ui - [x] cargo check -p git_ui - [x] Verified settings UI enum dropdown rendering for Git Panel sort/group settings Closes https://github.com/zed-industries/zed/issues/53555 Closes https://github.com/zed-industries/zed/issues/56039 Closes https://github.com/zed-industries/zed/issues/45438 Release Notes: - Improved Git Panel view options and Project Diff ordering. --------- Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com> |