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>
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>
This PR adds the ability to open local terminals when working in remote
projects. When working in a remote (often actually remoting into a local
container) I always need to run separate terminals outside Zed so I can
run local build tools, scripts, agents, etc. for the related project.
I'd like to be able to run all of these in the same Zed window and this
adds that ability via one-off local terminals.
## Changes
Adds an optional `local` parameter to terminal commands. When set to
`true`, creates a local shell on your machine instead of connecting to
the remote.
### Implementation
- Added `force_local` parameter to terminal creation logic
- Created `create_local_terminal()` method that bypasses remote client
- Updated terminal actions (`NewTerminal`, `NewCenterTerminal`) to
accept optional `local: bool` field (defaults to `false`)
### Usage
**Via keybinding:**
```json
{
"bindings": {
"cmd-t": "workspace::NewCenterTerminal",
"cmd-T": ["workspace::NewCenterTerminal", { "local": true }]
}
},
{
"context": "Terminal",
"bindings": {
"cmd-n": "workspace::NewTerminal",
"cmd-N": ["workspace::NewTerminal", { "local": true }],
},
},
```
**Behavior:**
- Default terminal commands continue to work as before (remote in remote
projects, local in local projects)
- The `local` parameter is optional and defaults to `false`
Release Notes:
- Added support for opening local terminals in remote projects via
`local` parameter on terminal commands.
Closes#46574
The `default_working_directory()` function in
`crates/terminal_view/src/terminal_view.rs:1585` returned `None` when no
project directory was available. The code comment (now removed)
incorrectly claimed "None implies `~` on whichever machine we end up
on". However, when `None` is passed to `alacritty_terminal`, it uses the
process CWD, not the home directory. On macOS when Zed is launched from
a .`app` bundle, the CWD is `/`.
Added a fallback at the end of` default_working_directory()` that
explicitly returns the home directory when no project directory is
found: `directory.or_else(dirs::home_dir)`
This ensures:
1. `CurrentProjectDirectory` with no project open → home directory
2. `FirstProjectDirectory `with no project open → home directory
3. `AlwaysHome `→ home directory (explicitly, not relying on shell
behavior)
4. Always `{ directory }` with invalid directory → home directory
Release Notes:
- Fixed terminal opening in `/` instead of home directory when no
project is open.
Closes https://github.com/zed-industries/zed/issues/45553
## Summary
When using applications that hide the terminal cursor (e.g., via ANSI
escape sequence `\e[?25l`), the IME candidate window appeared at the
bottom-left of the screen, and the composition text was not displayed at
all. This affects tools like Claude Code that hide the cursor during
operation.
The root cause was that cursor position calculation was skipped when the
cursor shape was `Hidden`. This fix separates cursor visibility from IME
position calculation by always computing cursor bounds for IME
positioning.
## Movies
### Zed 0.218.6
https://github.com/user-attachments/assets/a66d569a-178d-4bca-a577-fcc65e9fd2c4
### With this fix
https://github.com/user-attachments/assets/456323d1-6c18-45ea-88e8-fb5375c00f98
Release Notes:
- Fixed IME candidate window and composition text position in terminal
when cursor is hidden
This brings the terminal element's viewport culling in line with the
editor optimization in PR #44995 and the fix in PR #45077.
## Problem
When a terminal is inside a scrollable container (e.g., the Agent Panel
thread view), it would render ALL cells during prepaint, even when the
terminal was entirely outside the viewport. This caused unnecessary CPU
usage when multiple terminal tool outputs existed in the Agent Panel.
## Solution
Calculate the intersection of the terminal's bounds with the current
content_mask (the visible viewport after all parent clipping). If the
intersection has zero area, skip all cell processing entirely.
### Three code paths
1. **Offscreen** (`intersection.size <= 0`): Early exit, process 0 cells
2. **Fully visible** (`intersection == bounds`): Fast path, stream cells
directly (no allocation)
3. **Partially clipped**: Group cells by line, skip/take visible rows
only
### Key insight: filter by screen position, not buffer coordinates
The previous approach tried to filter cells by `cell.point.line`
(terminal buffer coordinates), which breaks in Scrollable mode where
cells can have negative line numbers for scrollback history.
The new approach filters by **screen position** using
`chunk_by(line).skip(N).take(M)`, which works regardless of the actual
line numbers because we're filtering on enumerated line group index.
## Testing
Added comprehensive unit tests for:
- Screen-position filtering with positive lines (Inline mode)
- Screen-position filtering with negative lines (Scrollable mode with
scrollback)
- Edge cases (skip all, positioning math)
- Unified filtering works for both modes
Manually verified:
- Terminal fully visible (no clipping) ✓
- Terminal clipped from top/bottom ✓
- Terminal completely outside viewport ✓
- Scrollable terminals with scrollback history ✓
- Selection/interaction still works ✓
Release Notes:
- Improved Agent Panel performance when terminals are scrolled
offscreen.
/cc @as-cii
Draft as a base for continuing the discussion in #8008 : adds a
`SplitOperation` enum to support bindings like `["pane::SplitLeft",
{"operation": "Clear"}]`
To be discussed @MrSubidubi and others:
- Naming: Generally not happy with names yet and specifically `Empty` is
unclear, e.g., what does this mean for terminal panes? Added placeholder
code to split without cloning, but unsure what users would expect in
this case.
- ~~I removed `SplitAndMoveXyz` actions but I guess we should keep them
for backwards compatibility?~~
- May have missed details in the move implementation. Will check the
code again for opportunities to refactor more code after we agree on the
approach.
- ~~Tests should go to `crates/collab/src/tests/integration_tests.rs`?~~
Closes#8008
Release Notes:
- Add `pane::Split` mode (`{ClonePane,EmptyPane,MovePane}`) to allow
creating an empty buffer.
---------
Co-authored-by: Finn Evers <finn.evers@outlook.de>
Co-authored-by: MrSubidubi <finn@zed.dev>
Closes https://github.com/zed-industries/zed/issues/43208
This PR essentially unblocks the editable number field. The function
that shapes editor lines was hard-coding text alignment to the left,
meaning that whatever different alignment we'd pass through
`EditorStyles`would be ignored. To solve this, I just added a text align
and align width fields to the line paint function and updated all call
sites keeping the default configuration. Had to also add an
`alignment_offset()` helper to make sure the cursor positioning, the
selection background element, and the click-to-focus functionality were
kept in-sync with the non-left aligned editor.
Then... the big star of the show here is being able to add the `mode`
method to the number field, which uses `TextAlign::Center`, thus making
it work as we designed it to work.
https://github.com/user-attachments/assets/3539c976-d7bf-4d94-8188-a14328f94fbf
Next up, is turning the number filed to edit mode where applicable.
Release Notes:
- Fixed a bug where different text alignment configurations (i.e.,
center and right-aligned) wouldn't take effect in editors.
## Summary
Fixes arithmetic underflow panics in `terminal_scrollbar.rs` by
converting unsafe subtractions to `saturating_sub`.
Closes#45281
## Problem
Two locations perform raw subtraction on `usize` values that panic when
underflow occurs:
- `offset()`: `state.total_lines - state.viewport_lines -
state.display_offset`
- `set_offset()`: `state.total_lines - state.viewport_lines`
This happens when `total_lines < viewport_lines + display_offset`, which
can occur during terminal creation, with small window sizes, or when
display state becomes stale.
## Solution
Replace the two unsafe subtractions with `saturating_sub`, which returns
0 on underflow instead of panicking.
Also standardizes the existing `checked_sub().unwrap_or(0)` in
`max_offset()` to `saturating_sub` for consistency across the file.
## Changes
- N/A
## Summary
Fix panic "cannot update workspace::pane::Pane while it is already being
updated" when dragging terminal tabs to split the pane.
## Problem
When dragging a terminal tab to create a split, the app panics due to
re-entrancy: the drop handler calls `terminal_panel.center.split()`
synchronously, which invokes `mark_positions()` that tries to update all
panes in the group. When the pane being updated is part of the terminal
panel's center group, this causes a re-entrancy panic.
## Solution
Defer the split operation using `cx.spawn_in()`, similar to how
`move_item` was already deferred in the same handler. This ensures the
split (and subsequent `mark_positions()` call) runs after the current
pane update completes.
## Test plan
- Open terminal panel
- Create a terminal tab
- Drag the terminal tab to split the pane
- Verify no panic occurs and split works correctly
Closes#45179
## Summary
Fixes the focus behavior when creating terminals with
`RevealStrategy::NoFocus` or `RevealStrategy::Never`. Previously,
terminals would still receive focus if the terminal pane already had
focus, contradicting the documented behavior.
## Changes
- **`add_terminal_task()`**: Changed focus logic to only focus when
`RevealStrategy::Always`
- **`add_terminal_shell()`**: Same fix
The fix changes:
```rust
// Before
let focus = pane.has_focus(window, cx)
|| matches!(reveal_strategy, RevealStrategy::Always);
// After
let focus = matches!(reveal_strategy, RevealStrategy::Always);
```
## Impact
This affects:
- Vim users running `:!command` (uses `NoFocus`)
- Debugger terminal spawning (uses `NoFocus`)
- Any programmatic terminal creation requesting background behavior
Release Notes:
- Fixed terminal focus behavior to respect `RevealStrategy::NoFocus` and
`RevealStrategy::Never` settings when the terminal pane already has
focus.
When running Codex CLI, Claude Code, or other TUI agents in Zed’s
terminal, pasting images wasn’t supported — Zed
treated all clipboard content as plain text and simply pushed it into
the PTY, so the agent never saw the image data.
This change makes terminal pastes behave like they do in a native
terminal: if the clipboard contains an image, Zed now emits a raw Ctrl+V
to the PTY so the agent can read the system clipboard itself.
Release Notes:
- Fixed terminal-launched Codex/Claude sessions by forwarding Ctrl+V for
clipboard images so agents can attach them
Closes #ISSUE
Problem:
- The status bar’s pending keystroke indicator (shown next to --NORMAL--
in Vim mode) didn’t clear when focus moved to another context, e.g.
hitting g in the editor then clicking the Git panel. The keymap state
correctly canceled the prefix, but observers that render the indicator
never received a “pending input changed” notification, so the UI kept
showing stale prefixes until a new keystroke occurred.
Fix:
- The change introduces a `pending_input_changed_queued` flag and a new
helper `notify_pending_input_if_needed` which will flushes the queued
notification as soon as we have an App context. The
`pending_input_changed` now resets the flag after notifying subscribers.
Before:
https://github.com/user-attachments/assets/7bec4c34-acbf-42bd-b0d1-88df5ff099aa
After:
https://github.com/user-attachments/assets/2264dc93-3405-4d63-ad8f-50ada6733ae7
Release Notes:
- Fixed: pending keybinding prefixes on the status bar now clear
immediately when focus moves to another panel or UI context.
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
🔜
TODO:
- [x] Add a utility pane to the left and right edges of the workspace
- [x] Add a maximize button to the left and right side of the pane
- [x] Add a new agents pane
- [x] Add a feature flag turning these off
POV: You're working agentically
<img width="354" height="606" alt="Screenshot 2025-12-13 at 11 50 14 PM"
src="https://github.com/user-attachments/assets/ce5469f9-adc2-47f5-a978-a48bf992f5f7"
/>
Release Notes:
- N/A
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Zed <zed@zed.dev>
This ensures that the casing of this entry aligns with other entries in
the app popover Menus.
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Just recently realized we don't need this custom component for it given
we now have `Tooltip::element`. UI result is exactly the same; nothing
changes.
Release Notes:
- N/A
Fixes an issue where the terminal cursor wouldn't always be displayed in
the default `blink: "terminal_controlled"` mode unless the terminal
requested cursor blinking.
Release Notes:
- N/A
Fixes#42945
## Problem
When opening a single file via command line (e.g., `zed
~/Downloads/file.txt`), the terminal panel was opening in the root
directory (/) instead of the file's directory.
## Root Cause
The code only checked for active project directory, which returns None
when a single file is opened. Additionally, file worktrees weren't
handling parent directory lookup.
## Solution
Added fallback logic to use the first project directory when there's no
active entry, and made file worktrees return their parent directory
instead of None.
## Testing
- All existing tests pass
- Added test coverage for file worktree scenarios
- Manually tested with `zed ~/Downloads/file.txt` - terminal now opens
in correct directory
This improves the user experience for users who frequently open single
files from the command line.
## Release Notes
- Fixed terminal opening in root directory when editing single files
from the command line
Closes#41975.
This change adjusts some of the ranges which were incorrectly labeled or
excluded characters. The new ranges include three codepoints which are
not assigned in Nerd Fonts. However, one of these codepoints were
already included prior to this change. These codepoints are:
- U+E0C9, between the two ice separators
- U+E0D3, between the two trapezoid separators. The ranges prior to this
PR already included this one.
- U+E0D5, between the trapezoid separators and the inverted triangle
separators
I included these so as to not overcomplicate the ranges by
cherry-picking the defined codepoints. That being said, if we're okay
with this and an additional unassigned codepoint (U+E0CB, between ice
separators and honeycomb separators) being included then a simple range
from 0xE0B0 to 0xE0D7 nicely includes all of the Powerline characters.
I wasn't sure how to write tests for this so I just added two characters
to the existing tests which were previously not covered lol. All of the
Powerline characters can be seen
[here](https://www.nerdfonts.com/cheat-sheet) by searching `nf-pl`.
Release Notes:
- Fixed certain Powerline characters incorrectly having terminal
contrast adjustment applied.
Release Notes:
- N/A
When I was implementing Input, I often used `TextRun`, but `background`,
`underline` and `strikethrough` were often not used.
So make change to simplify it.
When rerunning a task, our process id fetching seems to sometimes return
the previous terminal's process id when respawning the task, causing us
to kill the new terminal once the previous one drops as we spawn a new
one, then drop the old one. This results in rerun sometimes spawning a
blank task as the terminal immediately exits. The fix here is simple, we
actually want to kill the process running inside the terminal process,
not the terminal process itself when we exit in the terminal.
No relnotes as this was introduced yesterday in
https://github.com/zed-industries/zed/pull/41562
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes#41125
Release Notes:
- Fixed `SwitchToHelixNormalMode` to keep selection
- Added default keybinds for `SwitchToHelixNormalMode` when in Helix
mode
Attempt 2 for https://github.com/zed-industries/zed/pull/40774
We were spawning the process on the foreground thread before which can
block an arbitrary amount of time. Likewise we no longer block
deserialization on the terminal loading.
Release Notes:
- Improved startup time on systems with slow process spawning
capabilities
When trying to split and clone a non clone-able workspace item we now
attempt split and move instead of doing nothing. Additionally we disable
the split menu buttons if we can't split the active item at all.
Release Notes:
- Improved handling of unsplittable panes
Split out from https://github.com/zed-industries/zed/pull/40774 to
reduce the size of the reland of that PR (once I figure out the cause of
the issue)
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes#39172
This refactors when we resolve UI keybindings in an effort to reduce
flickering whilst painting these: Previously, we would always resolve
these upon creating the binding. This could lead to cases where the
corresponding context was not yet available and no binding could be
resolved, even if the binding was then available on the next presented
frame. Following that, on the next rerender of whatever requested this
keybinding, the keybind for that context would then be found, we would
render that and then also win a layout shift in that process, as we went
from nothing rendered to something rendered between these frames.
With these changes, this now happens less often, because we only look
for the keybinding once the context can actually be resolved in the
window.
| Before | After |
| --- | --- |
|
https://github.com/user-attachments/assets/adebf8ac-217d-4c7f-ae5a-bab3aa0b0ee8
|
https://github.com/user-attachments/assets/70a82b4b-488f-4a9f-94d7-b6d0a49aada9
|
Also reduced cloning in the keymap editor in this process, since that
requiered changing due to this anyway.
Release Notes:
- Fixed some cases where keybinds would appear with a slight delay,
causing a flicker in the process
We were spawning the process on the foreground thread before which can
block an arbitrary amount of time. Likewise we no longer block
deserialization on the terminal loading.
Release Notes:
- Improved startup time on systems with slow process spawning
capabilities
Closes#39901
I'm unsure as to which direction the team wants to go with this, but
this is the behavior of VSCode which is what this feature is based off
so i'm going with this.
Changes:
1. Introduced a new argument to the `new` method on the Pane called
`ignore_max_tabs` that forces the `max_tabs` to None if it's true.
2. Added a new test `test_bypass_max_tabs_limit`.
Release Notes:
- Fixed: `max_tabs` Setting affecting the terminal pane.
---------
Co-authored-by: Joseph T. Lyons <JosephTLyons@gmail.com>
I love keybindings.
I spend way to much time thinking about them.
I also REALLY like working in Zed.
so far, however, I have found the key context system in Zed to be less
flexible than in VSCode.
the HUGE context that is available in VSCode helps you create
keybindings for very specific targeted scenarios.
the tree like structure of the Zed key context means you loose some
information as focus moves throughout the application.
For example, it is not currently possible to create a keybinding in the
editor that will only work when one of the Docks is open, or if a
specific dock is open.
this would be useful in implementing solutions to ideas like #24222
we already have an action for moving focus to the dock, and we have an
action for opening/closing the dock, but to my knowledge (very limited
lol) we cannot determine if that dock *is open* unless we are focused on
it.
I think it is possible to create a more flexible key binding system by
adding more context information to the higher up context ancestors.
while:
```
Workspace right_dock=GitPanel
Dock
GitPanel
Editor
```
may seem redundant, it actually communicates fundamentally different
information than:
```
Workspace right_dock=GitPanel
Pane
Editor
```
the first says "the GitPanel is in the right hand dock AND IT IS
FOCUSED",
while the second means "Focus is on the Editor, and the GitPanel just
happens to be open in the right hand dock"
This change adds a new set of identifiers to the `Workspace` key_context
that will indicate which docks are open and what is the specific panel
that is currently visible in that dock.
examples:
- `left_dock=ProjectPanel`
- `bottom_dock=TerminalPanel`
- `right_dock=GitPanel`
in my testing the following types of keybindings seem to be supported
with this change:
```jsonc
// match for any value of the identifier
"context": "Workspace && bottom_dock"
"context": "Workspace && !bottom_dock"
// match only a specific value to an identifier
"context": "Workspace && bottom_dock=TerminalPanel"
// match only in a child context if the ancestor workspace has the correct identifier
"context": "Workspace && !bottom_dock=DebugPanel > Editor"
```
some screen shots of the context matching in different circumstances:
<img width="2032" height="1167" alt="Screenshot 2025-10-16 at 23 20 34"
src="https://github.com/user-attachments/assets/116d0575-a1ae-4577-95b9-8415cda57e52"
/>
<img width="2032" height="1167" alt="Screenshot 2025-10-16 at 23 20 57"
src="https://github.com/user-attachments/assets/000fdbb6-80bd-46e9-b668-f4b54ab708d2"
/>
<img width="2032" height="1167" alt="Screenshot 2025-10-16 at 23 21 37"
src="https://github.com/user-attachments/assets/7b1c82da-b82f-4e14-a97c-3cd0e71bbca0"
/>
<img width="2032" height="1167" alt="Screenshot 2025-10-16 at 23 21 52"
src="https://github.com/user-attachments/assets/1fd4b65a-09f7-47a9-a9b7-fdce4252aec3"
/>
<img width="2032" height="1167" alt="Screenshot 2025-10-16 at 23 22 38"
src="https://github.com/user-attachments/assets/f4c2ac5c-e6f9-4e0e-b683-522b237e3328"
/>
the persistent_name values for `ProjectPanel` and `OutlinePanel` needed
to be updated to not have a space in them in order to pass the
`Identifier` check. all the other Panels already had names that did not
include spaces, so it just makes these conform with the other ones.
I think this is a great place to start with adding more context
identifiers and i think this type of additional information will make it
possible to create really dynamic keybindings!
Release Notes:
- Workspace key context now includes the state of the 3 docks
We've been considering removing workspace-hack for a couple reasons:
- Lukas ran into a situation where its build script seemed to be causing
spurious rebuilds. This seems more likely to be a cargo bug than an
issue with workspace-hack itself (given that it has an empty build
script), but we don't necessarily want to take the time to hunt that
down right now.
- Marshall mentioned hakari interacts poorly with automated crate
updates (in our case provided by rennovate) because you'd need to have
`cargo hakari generate && cargo hakari manage-deps` after their changes
and we prefer to not have actions that make commits.
Currently removing workspace-hack causes our workspace to grow from
~1700 to ~2000 crates being built (depending on platform), which is
mainly a problem when you're building the whole workspace or running
tests across the the normal and remote binaries (which is where
feature-unification nets us the most sharing). It doesn't impact
incremental times noticeably when you're just iterating on `-p zed`, and
we'll hopefully get these savings back in the future when
rust-lang/cargo#14774 (which re-implements the functionality of hakari)
is finished.
Release Notes:
- N/A
