Rustfmt surrendered here because that method grew a bit too large. This
splits this up into smaller methods in an effort to combat this and make
the code more maintainable.
Release Notes:
- N/A
This can block the mainthread for several milliseconds given large
enough screensizes
Release Notes:
- Fixed screensharing performance on windows and linux
This feature cost $12
Release Notes:
- Changed the behavior of queued messages to gracefully wait for the
current activity to complete.
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
This PR fixes the fact that we weren't showing any @-mentions (files,
images, etc.) in the queue preview.
Release Notes:
- Agent: FIxed a bug with the message queue in the agent panel where
@-mentions weren't being displayed in the message preview within the
queue entries list.
<img width="611" height="102" alt="Screenshot 2026-01-15 at 4 18 30 PM"
src="https://github.com/user-attachments/assets/ba422cbb-4607-47c7-94c7-77752d7b4479"
/>
When viewing a branch diff (e.g., 'Changes since origin/main'), the
toolbar was hidden because `ProjectDiffToolbar` filters for
`DiffBase::Head` only. This meant users couldn't send review comments to
the Agent panel from the branch diff view.
Now there's a new `BranchDiffToolbar` which:
- Only activates for branch diff views (`DiffBase::Merge`)
- Shows only the 'Send Review to Agent' button (not stage/unstage
controls)
- Only appears when there are review comments (same behavior as the
existing toolbar)
(No release notes because this is still feature-flagged.)
Release Notes:
- N/A
Closes#40327
The env vars were only getting added if a custom command was provided.
But it makes sense in either case to be able to specify your env vars,
so now these are applied regardless.
Closes #ISSUE
Release Notes:
- acp: Fix for env vars not being properly applied to built-in ACP
agents.
Closes #ISSUE
Reproduction steps:
- Zed main branch
- Use Ollama (likely provider agnostic) in the agent panel with the
following prompt: "Explore the codebase with subagents"
- Panic
```
thread 'main' (36268) panicked at C:\Users\username\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\futures-util-0.3.31\src\stream\unfold.rs:108:21:
Unfold must not be polled after it returned `Poll::Ready(None)`
```
Following the stack trace we get to `Thread::run_turn_internal`. I
believe the panic happens in the following code which was introduced in
#46802
```rust
// Collect all immediately available events to process as a batch
let mut batch = vec![first_event];
while let Some(event) = events.next().now_or_never().flatten() {
batch.push(event);
}
```
Both `Option`s get flattened, however the inner `Option` represents the
end of the stream, after which polling the stream using `.next()` will
result in a panic.
We could fix the logic in this particular spot, but I believe the
simpler solution is to `.fuse()` the stream, which stops the stream from
panic'ing even after it has ended. This also prevents misuse in the
future.
The panic was introduces on main and did not land on a release yet, so
no release notes.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Fixes an issue where `editor::AddSelectionAbove` and
`editor::AddSelectionBelow`, when set with `skip_soft_wrap: true` ,
would lose track of the original cursor column when passing through
short lines, as `editor::Editor.add_selection` was not using the oldest
selection's column range when adding a new selection.
These changes update the `editor::Editor.add_selection` method so as to
keep track of the olde selection's column range for each group, as well
as extracting `find_next_columnar_selection_by_display_row` and
`find_next_columnar_selection_by_buffer_row` helper methods to clarify
the two navigation strategies.
Closes#46842
Release Notes:
- Fixed `editor::AddSelectionAbove` and `editor::AddSelectionBelow` when
skipping over soft-wrapped lines to preserve the original cursor column
when adding selections through lines shorter than the starting position
Closes #ISSUE
Moves the settings content definitions into their own crate, so that
they are compiled+cached separately from settings, primarily to avoid
recompiles due to changes in gpui. In that vain many gpui types such as
font weight/features, and `SharedString` were replaced in the content
crate, either with `*Content` types for font/modifier things, or
`String`/`Arc<str>` for `SharedString`. To make the conversions easy a
new trait method in the settings crate named `IntoGpui::into_gpui`
allows for `into()` like conversions to the gpui types in
`from_settings` impls.
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
This PR removes the code for the legacy plans.
No more users will be on this plan as of January 17th, so it's fine to
land these changes now (as they won't be released until the 21st).
Closes CLO-76.
Release Notes:
- N/A
Happy New Years! This PR is a second take at
https://github.com/zed-industries/zed/pull/38127 (cc @ConradIrwin)
This PR is significantly less complicated than the last attempt: while
we still keep our data on the `NavigationHistory` object, we no longer
tightly integrate it with the existing back/forward "browser history."
Instead, we keep our own stack of `(origin, target)` pairs (in a struct
to make it easy to extend with e.g., tag names in the future).
The PR is split into two separable commits. Most of the implementation
is in the second commit, which:
- Defines the stack data structure
- Implements `pane::GoToOlderTag` and `pane::GoToNewerTag` in terms of
the stack
- Hooks into `navigate_to_hover_links` to push tag stack entries
This last bit is the most fiddly. The core challenge is that we need to
keep track of the `origin` location and calculate the `target` location
across three codepaths that might involve creating a new editor and/or
splitting the pane. One thing in particular I found difficult was that
an editor's `nav_history` (an `ItemNavHistory`) seems to be populated
asynchronously. Instead of relying on it, I decided in this code to make
my own `ItemNavHistory`. I briefly tried to refactor the code in
question, but it seemed like it would significantly increase the scope
of the change.
I prefer this all-in-one tracking centered around
`navigate_to_hover_links ` to the `start/finish` approach taken in
https://github.com/zed-industries/zed/commit/b69a2ea200561de9de0edf4d0c4428ee887fb918
because I find it easier to convince myself that the right data is being
populated at the right times. Of course, let me know if you think
there's a better solution.
Closes#14206
Release Notes:
- ??? I don't know what to write here! Suggestions welcome
We can specify prompt version in the provider name itself, like this
`--provider zeta2:0113`.
This kind of tag will also be stored in the `provider` field of
jsonlines files.
This drops the `--version` parameter.
Release Notes:
- N/A
Dynamic schemas (settings, settings/lsp/*, debug_tasks) are now cached
after first generation and returned immediately via Task::ready() on
subsequent requests.
Cache is invalidated when `notify_schema_changed()` is called, which
happens when:
- Extensions are installed/uninstalled (affects settings schema)
- DAP registry changes (affects debug_tasks schema)
This eliminates repeated foreground thread blocking for the same dynamic
schema.
**Note:** This PR is based on #46823 and should be merged after it.
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Release Notes:
- Opening bundled files, keymap, and local release notes now opens in
remote windows instead of opening a new local zed window
- Opening the settings files, keymap files, task files, debug files and
logs will now open within wsl windows instead of opening a new local zed
window
Although `poetry` may store virtual environments in a global cache
directory (unlike the standard project-local `.venv`), the internal
directory structure of these environments remains consistent with
standard `venv` or `uv` environments.
Since our existing activation logic for `venv` environments relies on
relative paths within the environment root, it is naturally compatible
with `poetry` environments. Once the toolchain locates the environment's
root directory, the activation scripts can be applied without further
modification.
Testing:
- Verified on Windows: Confirmed working across `PowerShell`, `Pwsh`,
and `Cmd` for global poetry environments.
- Observation: When using an in-project `.venv` directory, the toolchain
may categorize the environment as `venv`-managed instead of
`poetry`-managed. While this behavior relates to the toolchain's
discovery logic, the activation itself remains fully functional as the
underlying structure is compatible.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Context menus close when the window becomes inactive (e.g., clicking to
another window or app). Previously, menus would remain visible until the
window regained focus.
This aligns Zed's context menu behavior with native macOS apps, where
NSMenu automatically dismisses when the window loses focus. Users expect
menus to close when switching windows or apps.
Uses `observe_window_activation` to detect when the window becomes
inactive and calls `cancel` to dismiss the menu.
Release Notes:
- Fixed context menus dismiss/cancel when the window loses focus
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Closes#46142
Release Notes:
- Fixed AI commit message button in Git panel being hidden instead of
disabled when no AI provider is configured. The button now remains
visible with a tooltip explaining how to enable the feature.
Screenshot:
<img width="90%" alt="Screenshot 2026-01-10 at 18 16 12"
src="https://github.com/user-attachments/assets/6af9c845-7857-40e1-bfb5-3118f1af8360"
/>
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
This PR fixes an issue when copilot takes 3s to complete. Right now, in
copilot edit prediction, we issue requests to both the Next Edit
Suggestion (NES) and the regular copilot inline completion endpoints.
Whichever come back first will be shown. However, there is a bug where
even if inline completion (which is usually much faster) comes back, we
still wait for NES (which takes about 3s).
This should address https://github.com/zed-industries/zed/issues/46389
and https://github.com/zed-industries/zed/issues/46880
Release notes:
- Improved responsiveness of Copilot inline completions.
It should be a no-op but causes massive main thread hangs on windows due
to the winapi calls this emits, restores the behavior pre
github.com/zed-industries/zed/pull/46256 without reverting the main
changes of that.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
The cursor in terminal vi mode was not visually updating when using
vi motion navigation keys, despite internal position tracking working correctly.
This was caused by missing `cx.notify()` calls to trigger re-rendering.
Refactored keystroke handling by extracting common logic from `key_down`
and `send_keystroke` into a shared `process_keystroke` helper method.
Closes#46736
Release Notes:
- terminal: Fixed vi mode cursor not visually updating when navigating
with vi motion keys
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Ben Kunkle