Closes#46252
Uses the `remoteUser` property returned from the devcontainer CLI so
that settings are respected. Additionally, checks for a default shell in
`passwd` if `$SHELL` is not set.
Release Notes:
- Fixed remote_user and shell inconsistencies from within dev containers
- Remove old attempt to sync scrolling
- Share a `ScrollAnchor` between the two sides, and be sure to resolve
it against the correct snapshot
- Allow either side to initiate an autoscroll request, and make sure
that request is processed in the same frame by the other side
Release Notes:
- N/A
---------
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Co-authored-by: Jakub <jakub@zed.dev>
Closes#45198
Release Notes:
- Fixed an issue where "Reopen Closed Item" would fail to reopen tabs
that had been converted from preview to non-preview before being closed.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Closes#46509
Release Notes:
- Fixed: `workspace::SendKeystrokes` would not allow remapping keys in
different keyboard layouts
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Validate task variable names when the file is saved, immediately
displaying an error toast if any invalid `ZED_*` variables are found.
Valid tasks in the same file are still loaded and work normally.
- Add `task::task_template::TaskTemplate::unknown_variables()` to detect
invalid `ZED_` variable names
- Add `project::ToastLink` struct and optional `link` field to
`project::Event::Toast`
- Show documentation link in the error toast
Closes#23275
Release Notes:
- Fixed user-defined tasks with unresolved `ZED_*` variables being
silently omitted
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Also ensured that we clear only the highlights of the current view
(which probably would have been the the case almost always anyway).
Release Notes:
- Fixed a small issue where highlights of the syntax tree view would
persist after the view was closed.
Enables restoration of empty workspaces (without folders) that contain
unsaved items like drafts or single files. Empty workspaces are now
identified by workspace_id rather than paths, allowing multiple empty
workspaces to coexist and be properly restored on startup. This ensures
users don't lose work when closing Zed with unsaved files in empty
workspaces.
Closes#15098
Release Notes:
- Improved: Empty workspaces with unsaved files now restore on startup
(hot-exit)
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
This PR improves the performance of the `CopyButton` component by
tracking the copied state locally through a `CopyButtonState` struct
instead of making an OS call every time the component re-renders. Also
pushing a slight improvement here by resetting the state after two
seconds so as to make the check mark go away after you clicked to copy.
Release Notes:
- N/A
When focus is on a dock panel that doesn't contain a pane (e.g., project
panel), `pane::CloseActiveItem` will now close the active item in the center
pane instead of doing nothing.
This allows users to bind, for example, `cmd-w` to `pane::CloseActiveItem`
and have it work consistently regardless of whether focus is on a dock
panel or the editor.
Closes#45261
Release Notes:
- Improved `pane::CloseActiveItem` to close center pane items even when
focus is on a dock panel like the project panel or outline panel
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Adds the ability to create a dev container definition from scratch.
Additionally, separates devcontainer logic out into its own crate, since
it was getting sufficiently complex to separate from the
`recent_projects` crate.
A screen recording of the modal experience:
https://github.com/user-attachments/assets/f6cf95e1-eb7b-4ca3-86c7-c1cbc26ca557
Release Notes:
- Added modal to initialize a dev container definition in the project
with `projects: initialize dev container`
- Added podman support for dev container actions with the `use_podman`
setting
- Improved devcontainer error handling
---------
Co-authored-by: Sam Coward <idoru42@gmail.com>
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/aebd394fb60641a2dd32b1f1b76a7c79ec4aa2ea
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
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
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 ...
This refactors the "Panel Button Clicked" telemetry event to fire from
`workspace.rs` instead of `dock.rs`.
Previously, the event was emitted in the `PanelButtons` render method's
click handler. Now it fires at the workspace level in two places:
- `toggle_dock()` - captures panel toggles via dock buttons
- `focus_panel<T>()` - captures panel focus via keyboard shortcuts
This ensures the telemetry fires once per user action regardless of
input method, and retrieves the panel name dynamically via
`persistent_name()` rather than relying on a pre-computed local
variable.
Release Notes:
- N/A
This PR introduces a project dropdown when working with multiple
folders/projects in one workspace. Here are some interaction details
that I hope improves the UX of working on this scenario significantly:
- The dropdown shows the currently "active" project, which is determined
by:
- Either the file you're currently editing
- Or the file you have just recently switched to
- Some example cases:
- If you are focused on file from project A but switch to project B in
the titlebar, nothing happens. However, as soon as you type on the file
from project A, the title bar will update and your active project will
return to being project A.
- If you're focused on file from project A and change tabs to a file
from project B, the title bar will update, showing project B as the
active one.
- The content you'll see in the branch picker will correspond to the
currently active project
- It's still possible to reach the "Recent Projects" picker through the
project dropdown
- It's possible to do all interactions (trigger dropdown, select active
project, and remove project from workspace) with the keyboard
https://github.com/user-attachments/assets/e2346757-74df-47c5-bf4d-6354623b6f47
Note that this entire UX is valid only for a multiple folder workspace
scenario; nothing changes for the single project case.
Release Notes:
- Workspace: Improved the UX of working with multiple projects in the
same workspace through introducing a project dropdown that more clearly
shows the currently active project as well as allowing you to change it.
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.
## Problem:
When working with many `pinned tabs`, they consume significant
horizontal space in the tab bar, leaving less room for unpinned (active
working) tabs, especially on small screens. This creates a poor user
experience as users must constantly scroll to find their working tabs,
or the tabs become too narrow to read file names.
## Solution:
Added a new opt-in setting `tab_bar.show_pinned_tabs_in_separate_row`
that displays pinned and unpinned tabs in two separate rows:
- Top row: Pinned tabs with navigation buttons and tab bar controls
- Bottom row: Unpinned (working) tabs with full horizontal space
- when pinned and not pinned tabs we show 2 rows:
<img width="1512" height="159" alt="2_rows"
src="https://github.com/user-attachments/assets/62a85fcc-8073-40d2-a8e4-270efd0d0f21"
/>
This is a well-established UX pattern used in many popular IDEs
including JetBrains products (IntelliJ IDEA, WebStorm, PyCharm,
RubyMine), Visual Studio, and Eclipse.
The two-row layout only appears when both pinned AND unpinned tabs
exist. If only one type is present, a single row is displayed:
- when only not pinned tabs we show one row:
<img width="1510" height="111" alt="when only not pinned"
src="https://github.com/user-attachments/assets/048df4fc-4b17-4ea2-9c5b-b4db91cdfc78"
/>
- when only pinned tabs we show one row:
<img width="1510" height="111" alt="when only pinned tabs"
src="https://github.com/user-attachments/assets/7ccf2517-8711-4114-815d-6cbb1e89d7e2"
/>
**Important** - Default Behavior Preserved:
- The setting defaults to false - existing users will see no change
whatsoever
- Original tab bar logic is preserved in a dedicated
`render_single_row_tab_bar` method, while the new two-row layout lives
in `render_two_row_tab_bar`. Both methods share common components
(`configure_tab_bar_start`, `configure_tab_bar_end`,
`render_unpinned_tabs_container`, `render_tab_bar_drop_target`) ensuring
DRY code and consistent behavior.
- Purely opt-in - users must explicitly enable this feature via Settings
UI or settings.json
- No impact on default UX - Zed's default tab bar appearance and
behavior remains identical
This implementation ensures zero risk to the existing user experience
while providing an optional enhancement for users who prefer separated
tab rows.
Configuration
Via Settings UI:
- Open Settings (Cmd+,) → Editor section → "Pinned Tabs Layout" toggle
Via settings.json:
```json
{
"tab_bar": {
"show_pinned_tabs_in_separate_row": true
}
}
```
<img width="468" height="67" alt="manual_settings"
src="https://github.com/user-attachments/assets/d21f6dde-7683-47b3-8dca-d190049d32fb"
/>
## Video of implemented feature:
https://github.com/user-attachments/assets/b1e52074-a5a1-4c4e-ad59-e55e2213509d
## Tested:
- Verify default behavior unchanged (single row with pinned + unpinned
tabs inline)
- Enable setting → verify two rows appear when both pinned and unpinned
tabs exist
- Enable setting → verify single row when only pinned tabs exist
- Enable setting → verify single row when only unpinned tabs exist
- Verify drag & drop works in both layouts
- Verify navigation buttons and tab bar buttons render correctly
- Verify setting toggle works in Settings UI
- Verify setting works via settings.json
Tested on: MacBook Pro M4, macOS 26.2
## Release Notes:
- Added `tab_bar.show_pinned_tabs_in_separate_row` setting to display
pinned and unpinned tabs in separate rows, giving unpinned tabs full
horizontal space
---------
Co-authored-by: Matt Miller <mattrx@gmail.com>
## Motivation
This PR unifies the async execution infrastructure between GPUI and
other components that depend on the `scheduler` crate (such as our cloud
codebase). By having a scheduler that lives independently of GPUI, we
can enable deterministic testing across the entire stack - testing GPUI
applications alongside cloud services with a single, unified scheduler.
## Summary
This PR completes the integration of the `scheduler` crate into GPUI,
unifying async execution and enabling deterministic testing of GPUI
combined with other components that depend on the scheduler crate.
## Key Changes
### Scheduler Integration (Phases 1-5, previously completed)
- `TestDispatcher` now delegates to `TestScheduler` for timing, clock,
RNG, and task scheduling
- `PlatformScheduler` implements the `Scheduler` trait for production
use
- GPUI executors wrap scheduler executors, selecting `TestScheduler` or
`PlatformScheduler` based on environment
- Unified blocking logic via `Scheduler::block()`
### Dead Code Cleanup
- Deleted orphaned `crates/gpui/src/platform/platform_scheduler.rs`
(older incompatible version)
## Intentional Removals
### `spawn_labeled` and `deprioritize` removed
The `TaskLabel` system (`spawn_labeled`, `deprioritize`) was removed
during this integration. It was only used in a few places for test
ordering control.
cc @maxbrunsfeld @as-cii - The new priority-weighted scheduling in
`TestScheduler` provides similar functionality through
`Priority::High/Medium/Low`. If `deprioritize` is important for specific
test scenarios, we could add it back to the scheduler crate. Let me know
if this is blocking anything.
### `start_waiting` / `finish_waiting` debug methods removed
Replaced by `TracingWaker` in `TestScheduler` - run tests with
`PENDING_TRACES=1` to see backtraces of pending futures when parking is
forbidden.
### Realtime Priority removed
The realtime priority feature was unused in the codebase. I'd prefer to
reintroduce it when we have an actual use case, as the implementation
(bounded channel with capacity 1) could potentially block the main
thread. Having a real use case will help us validate the design.
## Testing
- All GPUI tests pass
- All scheduler tests pass
- Clippy clean
## Architecture
```
┌─────────────────────────────────────────────────────────────┐
│ GPUI │
│ ┌──────────────────────┐ ┌────────────────────────────┐ │
│ │ gpui::Background- │ │ gpui::ForegroundExecutor │ │
│ │ Executor │ │ - wraps scheduler:: │ │
│ │ - scheduler: Arc< │ │ ForegroundExecutor │ │
│ │ dyn Scheduler> │ └────────────┬───────────────┘ │
│ └──────────┬───────────┘ │ │
│ │ │ │
│ └──────────┬──────────────────┘ │
│ ▼ │
│ ┌───────────────────────┐ │
│ │ Arc<dyn Scheduler> │ │
│ └───────────┬───────────┘ │
│ ┌──────────────┴──────────────┐ │
│ ▼ ▼ │
│ ┌──────────────────┐ ┌────────────────────┐ │
│ │ PlatformScheduler│ │ TestScheduler │ │
│ │ (production) │ │ (deterministic) │ │
│ └──────────────────┘ └────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
```
Release Notes:
- N/A
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Co-authored-by: Yara <git@yara.blue>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Un-preview the active tab when closing other tabs.
In my mind the intent when clicking `Close Others` is to keep the
current tab around, so it should no longer be treated as a preview.
This also matches the VSCode behavior.
Release Notes:
- Make preview tab permanent after closing all other tabs
## Context / Related PRs This PR is the third part of the encoding
support improvements, following:
- #44819: Introduced initial legacy encoding support (Shift-JIS, etc.).
- #45243: Fixed UTF-16 saving behavior and improved binary detection.
## Summary
This PR implements a status bar item that displays the character
encoding of the active buffer (e.g., `UTF-8`, `Shift_JIS`). It provides
visibility into the file's encoding and indicates the presence of a Byte
Order Mark (BOM).
## Features
- **Encoding Indicator**: Displays the encoding name in the status bar.
- **BOM Support**: Appends `(BOM)` to the encoding name if a BOM is
detected (e.g., `UTF-8 (BOM)`).
- **Configuration**: The active_encoding_button setting in status_bar
accepts "enabled", "disabled", or "non_utf8". The default is "non_utf8",
which displays the indicator for all encodings except standard UTF-8
(without BOM).
- **Settings UI**: Provides a dropdown menu in the Settings UI to
control this behavior.
- **Documentation**: Updated `configuring-zed.md` and
`visual-customization.md`.
## Implementation Details
- Created `ActiveBufferEncoding` component in
`crates/encoding_selector`.
- The click handler for the button is currently a **no-op**.
Implementing the functionality to reopen files with a specific encoding
has potential implications for real-time collaboration (e.g., syncing
buffer interpretation across peers). Therefore, this PR focuses strictly
on the visualization and configuration aspects to keep the scope simple
and focused.
- Updated schema and default settings to include
`active_encoding_button`.
## Screenshots
<img width="487" height="104" alt="image"
src="https://github.com/user-attachments/assets/041f096d-ac69-4bad-ac53-20cdcb41f733"
/>
<img width="454" height="99" alt="image"
src="https://github.com/user-attachments/assets/ed76daa2-2733-484f-bb1f-4688357c035a"
/>
## Configuration
To hide the button, add the following to `settings.json`:
```json
"status_bar": {
"active_encoding_button": "disabled"
}
```
- **enabled**: Always show the encoding.
- **disabled**: Never show the encoding.
- **non_utf8**: Shows for non-UTF-8 encodings and UTF-8 with BOM. Only
hides for standard UTF-8 (Default).
<img width="1347" height="415" alt="image"
src="https://github.com/user-attachments/assets/7f4f4938-3320-4d21-852c-53ee886d9a44"
/>
## Heuristic Limitations:
The underlying detection logic (implemented in #44819 and #45243)
prioritizes UTF-8 opening performance and does not guarantee perfect
detection for all encodings. We consider this margin of error
acceptable, similar to the behavior seen in VS Code. A future "Reopen
with Encoding" feature would serve as the primary fallback for any
misdetections.
Release Notes:
- Added a status bar item to display the active file's character encoding (e.g. `UTF-16`). This shows for non-utf8 files by default and can be configured with `{"status_bar":{"active_encoding_button":"disabled|enabled|non_utf8"}}`
Breadcrumb visual reorchestration which makes a couple of key changes:
- Breadcrumbs are now displayed in file headers for multibuffer views.
Singleton buffers are unchanged.
- Multibuffer views now have collapse/expand all buttons available in
the toolbar
- Search in multibuffer views now takes up less space, by occupying the
primary toolbar location erstwhile taken up by breadcrumbs
<img width="1721" height="823" alt="Screenshot 2025-12-22 at 4 15 41 PM"
src="https://github.com/user-attachments/assets/38e924f7-fe9e-4c83-84fb-2eee98137f43"
/>
<img width="1722" height="762" alt="Screenshot 2025-12-22 at 4 15 51 PM"
src="https://github.com/user-attachments/assets/ccc98ca3-75ce-4aca-bceb-890817b0f04d"
/>
Release Notes:
- Moved breadcrumbs to file headers in multibuffer views
- Added collapse/expand all options for multibuffer views
- Improved use of space for multibuffer search by taking the place of
the former breadcrumb toolbar location
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
This PR essentially removes the logic I introduced in
https://github.com/zed-industries/zed/pull/45361 to position workspace
modals based on the pointer click coordinates. All of this code has
become unnecessary given in
https://github.com/zed-industries/zed/pull/45924 we made the remote,
project, and branch modals use popovers when triggered with a pointer,
which already handle all the anchored positioning based on the trigger
(much better).
Release Notes:
- N/A
This mimics VSCode's `files.readonlyExclude` setting, to allow setting
specific path matches as readonly locations like lockfiles and generated
sources etc.
Also renders a lock icon to the right side of the path names for
readonly files now.
This does a couple more things for completion sake:
- Tabs of readonly buffers now render a file lock icon
- Multibuffer buffer headers now render a file lock icon if the excerpts
buffer is readonly
- ReadWrite multibuffers now no longer allow edits to read only buffers
contained within
Release Notes:
- Added `read_only_files` setting to allow specifying glob patterns of
files that should not be editable by default
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Closes https://github.com/zed-industries/zed/issues/45630
Remote host location alone is not enough to distinguish between remote
worktrees: different remote projects open in different windows will have
the same remote host location and _will_ have the same `WorktreeId`.
Thus, require an associated `WorktreeStore` with all
`WorktreeId`-related trust questions, and store those IDs based on the
store key.
Release Notes:
- Fixed worktree trust handling of multiple projects on the same remote
host
KyleBarton