Closes#44720
Release Notes:
- Fixed dock panel button tooltips not being dismissed when toggling
panels via keyboard shortcut
**Problem:** When hovering over a dock panel button and using a keyboard
shortcut to toggle the panel, the tooltip remains visible with stale
content. This is inconsistent with mouse click behavior, where the
tooltip is dismissed on mouse down.
**Solution:** Include the panel's active state in the button's element
ID. When the state changes, the element ID changes (e.g., `"DebugPanel"`
→ `"DebugPanel-active"`), which causes GPUI to discard the old element
state including the cached tooltip.
**Testing:** Manually verified:
1. Hover over a dock panel button, wait for tooltip
2. Press keyboard shortcut to toggle the panel
3. Tooltip is now dismissed (consistent with mouse click behavior)
https://github.com/user-attachments/assets/ed92fb6c-6c22-44e2-87e3-5461d35f7106
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
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 #ISSUE
Release Notes:
- Fixed an issue where the `pane: close all items` action would give up
if you hit "Cancel" on the prompt for what to do with a dirty buffer
From Zed's title bar, you can click on buttons to open three modal
pickers: remote projects, projects, and branches. All of these pickers
use the modal layer, which by default, renders them centered on the UI.
However, a UX issue we've been bothered by is that when you _click_ to
open them, they show up just way too far from where your mouse likely is
(nearby the trigger you just clicked). So, this PR introduces a
`ModalPlacement` enum to the modal layer, so that we can pick between
the "centered" and "anchored" options to render the picker. This way, we
can make the pickers use anchored positioning when triggered through a
mouse click and use the default centered positioning when triggered
through the keybinding.
One thing to note is that the anchored positioning here is not as
polished as regular popovers/dropdowns, because it simply uses the x and
y coordinates of the click to place the picker as opposed to using
GPUI's `Corner` enum, thus making them more connected to their triggers.
I chose to do it this way for now because it's a simpler and more
contained change, given it wouldn't require a tighter connection at the
code level between trigger and picker. But maybe we will want to do that
in the near future because we can bake in some other related behaviors
like automatically hiding the button trigger tooltip if the picker is
open and changing its text color to communicate which button triggered
the open picker.
https://github.com/user-attachments/assets/30d9c26a-24de-4702-8b7d-018b397f77e1
Release Notes:
- Improved the UX of title bar modal pickers (remote projects, projects,
and branches) by making them open closer to the trigger when triggering
them with the mouse.
Closes#42268
We've migrated user selections when a given workspace has a single
worktree (as then we could determine what the target worktree is).
Release Notes:
- python: Fixed selected virtual environments not being
persisted/deserialized correctly within long-running Zed sessions (where
multiple different projects might've been opened). This is a breaking
change for users of multi-worktree projects - your selected toolchain
for those projects will be reset.
Co-authored-by: Dino <dino@zed.dev>
Closes#13304
Release Notes:
- Add global `git status` and `git diff` on/off in one place instead of
control everywhere
We can first review to ensure this change meets both `Zed` and user
requirements, as well as code rules. Currently, we only support
user-level settings. We can wait for this PR:
https://github.com/zed-industries/zed/pull/43173 to be merged, then
modify it to support both user and project levels.
Previously, when opening a new project (one that was never opened
before), the window bounds restoration logic would fall through to
GPUI's default window sizing instead of using the last known window
bounds.
This change consolidates the window bounds restoration logic so that
both empty workspaces and new projects use the stored default window
bounds, making the behavior consistent: any new window will use the last
resized window's size and position.
Closes#45092
Release Notes:
- Fixed new files and projects opening with default window size instead
of the last used window size.
Closes#28732
Release Notes:
- Opening the command palette or other modals no longer triggers
auto-save with the `{ "autosave": "on_focus_change" }` setting. This
reduces the chance of unwanted format changes when executing actions,
and fixes a race condition with `:w` in Vim mode
Follow-up of https://github.com/zed-industries/zed/pull/44887
Trims the worktree trust mechanism to the actual `worktree`s, so now
"global", workspace-level things like `prettier`, `NodeRuntime`,
`copilot` and global MCP servers are considered as "trusted" a priori.
In the future, a separate mechanism for those will be considered and
added.
Release Notes:
- N/A
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>
Closes#20613
Release Notes:
- Fixed: New windows no longer flicker between "Open a file or project
to get started" and an empty editor.
---
When opening a new window (`cmd-shift-n`), the window rendered showing
the empty state message before the editor was created, causing a visible
flicker.
**Changes:**
- Modified `Workspace::new_local` to accept an optional `init` callback
that executes inside the window build closure
- The init callback runs within `cx.new` (the `build_root_view`
closure), before `window.draw()` is called for the first render
- Changed the NewWindow action handler to use
`Project::create_local_buffer()` (synchronous) instead of
`Editor::new_file()` (asynchronous)
- Updated `open_new` to pass the editor creation callback to `new_local`
- All other `new_local` call sites pass `None` to maintain existing
behavior
**Key Technical Detail:**
The window creation sequence in `cx.open_window()` is:
1. `build_root_view` closure is called (creates workspace via `cx.new`)
2. `window.draw(cx)` is called (first render)
3. `open_window` returns
The fix uses `Project::create_local_buffer()` which creates a buffer
**synchronously** (returns `Entity<Buffer>` directly), rather than
`Editor::new_file()` which is asynchronous (calls
`project.create_buffer()` which returns a `Task`). The editor is created
from this buffer inside the `cx.new` closure (step 1), ensuring it
exists before step 2 renders the first frame.
**Before:**
```rust
let task = Workspace::new_local(Vec::new(), app_state, None, env, cx);
cx.spawn(async move |cx| {
let (workspace, _) = task.await?; // Window already drawn
workspace.update(cx, |workspace, window, cx| {
Editor::new_file(workspace, ...) // Async - editor not present for first render
})?;
})
```
**After:**
```rust
cx.open_window(options, {
move |window, cx| {
cx.new(|cx| {
let mut workspace = Workspace::new(...);
// Create buffer synchronously, then create editor
if let Some(init) = init {
init(&mut workspace, window, cx); // Uses create_local_buffer (sync)
}
workspace
})
}
})?
```
The editor is now part of the workspace before the window's first frame
is rendered, eliminating the flicker.
<!-- START COPILOT ORIGINAL PROMPT -->
<details>
<summary>Original prompt</summary>
>
> ----
>
> *This section details on the original issue you should resolve*
>
> <issue_title>Opening a new window flickers before opening an empty
buffer</issue_title>
> <issue_description>### Check for existing issues
>
> - [x] Completed
>
> ### Describe the bug / provide steps to reproduce it
>
> Opening a new window, with e.g. `cmd-shift-n`, flickers for a fraction
of a second. The new window first shows the startup page, "Open a file
or project to get started.". Then, a frame or two later, a new empty
buffer opens.
>
> Not sure if I'm sensitive or something but these kinds of flashes can
knock me out of focus/flow pretty easily.
>
> It'd be great to either have the empty buffer open from the first
frame, or to have an option to simply not open that empty buffer when a
new window is opened.
>
> ### Zed Version and System Specs
>
> Zed: v0.170.4 (Zed)
> OS: macOS 14.6.1
> Memory: 36 GiB
> Architecture: aarch64
>
> ### If applicable, add screenshots or screencasts of the incorrect
state / behavior
>
>
https://github.com/user-attachments/assets/6d9ba791-8a02-4e13-857c-66a33eb0905b
>
> ### If applicable, attach your Zed.log file to this issue.
>
> N/A</issue_description>
>
> <agent_instructions>We should make sure that the window is created in
the correct state, and not have an intermediate render before the editor
opens.</agent_instructions>
>
> ## Comments on the Issue (you are @copilot in this section)
>
> <comments>
> <comment_new><author>@ConradIrwin</author><body>
> Ugh, no. I don't believe I never noticed this before, but now I can't
unsee it :s
>
> If you'd like to pair on this: https://cal.com/conradirwin/pairing,
otherwise I'll see if I get around to it.</body></comment_new>
> <comment_new><author>@ConradIrwin</author><body>
> Yeah... I wonder if that can be a preview tab or something. It's nice
when you want it, but not so nice when you don't.
>
> Fixing this will also make zed-industries/zed#33334 feel much
smoother.</body></comment_new>
> <comment_new><author>@zelenenka</author><body>
> @robinplace do you maybe have an opportunity to test it with the
latest stable version, 0.213.3?</body></comment_new>
> </comments>
>
</details>
<!-- START COPILOT CODING AGENT SUFFIX -->
- Fixeszed-industries/zed#23742
<!-- START COPILOT CODING AGENT TIPS -->
---
💡 You can make Copilot smarter by setting up custom instructions,
customizing its development environment and configuring Model Context
Protocol (MCP) servers. Learn more [Copilot coding agent
tips](https://gh.io/copilot-coding-agent-tips) in the docs.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: ConradIrwin <94272+ConradIrwin@users.noreply.github.com>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Follow-up of https://github.com/zed-industries/zed/pull/44887
This fixes remote server builds.
Additionally:
* slightly rewords workspace trust text in the security modal
* eagerly ask for worktree trust on open
Release Notes:
- N/A
Closes https://github.com/zed-industries/zed/issues/12589
Forces Zed to require user permissions before running any basic
potentially dangerous actions: parsing and synchronizing
`.zed/settings.json`, downloading and spawning any language and MCP
servers (includes `prettier` and `copilot` instances) and all
`NodeRuntime` interactions.
There are more we can add later, among the ideas: DAP downloads on
debugger start, Python virtual environment, etc.
By default, Zed starts in restricted mode and shows a `! Restricted
Mode` in the title bar, no aforementioned actions are executed.
Clicking it or calling `workspace::ToggleWorktreeSecurity` command will
bring a modal to trust worktrees or dismiss the modal:
<img width="1341" height="475" alt="1"
src="https://github.com/user-attachments/assets/4fabe63a-6494-42c7-b0ea-606abb1c0c20"
/>
Agent Panel shows a message too:
<img width="644" height="106" alt="2"
src="https://github.com/user-attachments/assets/0a4554bc-1f1e-455b-b97d-244d7d6a3259"
/>
This works on local, SSH and WSL remote projects, trusted worktrees are
persisted between Zed restarts.
There's a way to clear all persisted trust with
`workspace::ClearTrustedWorktrees`, this will restart Zed.
This mechanism can be turned off with settings:
```jsonc
"session": {
"trust_all_worktrees": true
}
```
in this mode, all worktrees will be trusted by default, allowing all
actions, but no auto trust will be persisted: hence, when the setting is
changed back, auto trusted worktrees will require another trust
confirmation.
This settings switch was added to the onboarding view also.
Release Notes:
- Introduced worktree trust mechanism, can be turned off with
`"session": { "trust_all_worktrees": true }`
---------
Co-authored-by: Matt Miller <mattrx@gmail.com>
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: John D. Swanson <swanson.john.d@gmail.com>
Hi,
This PR fixes nothing. I just miss the option to open recent projects
quickly upon opening Zed, so I made this. Hope I can see it soon in
Preview channel.
If there is any suggestion, just comment. I will take it seriously.
Thank you!
|ui|before|after|
|-|-|-|
|empty pane|<img width="1571" height="941" alt="Screenshot 2025-12-03 at
12 39 25"
src="https://github.com/user-attachments/assets/753cbbc5-ddca-4143-aed8-0832ca59b8e7"
/>|<img width="1604" height="952" alt="Screenshot 2025-12-03 at 12 34
03"
src="https://github.com/user-attachments/assets/2f591d48-ef86-4886-a220-0f78a0bcad92"
/>|
|new window|<img width="1571" height="941" alt="Screenshot 2025-12-03 at
12 39 21"
src="https://github.com/user-attachments/assets/a3a1b110-a278-4f8b-980e-75f5bc96b609"
/>|<img width="1604" height="952" alt="Screenshot 2025-12-04 at 10 43
17"
src="https://github.com/user-attachments/assets/74a00d91-50da-41a2-8fc2-24511d548063"
/>|
---
Release Notes:
- Added a new value to the `restore_on_startup` setting called
`launchpad`. This value makes Zed open with a variant of the welcome
screen ("the launchpad") upon startup. Additionally, this same page
variant is now also what is displayed if you close all tabs in an
existing window that doesn't contain any folders open. The launchpad
page shows you up to 5 recent projects, making it easy to open something
you were working recently.
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Closes#14472
Introduces `workspace::ZoomIn` and `workspace::ZoomOut` actions that
complement the existing `workspace::ToggleZoom` action. ZoomIn only
zooms if not already zoomed, and ZoomOut only zooms out if currently
zoomed. This enables composing zoom actions with
`workspace::SendKeystrokes` for workflows like "focus terminal then zoom
in".
<details><summary>Example usage</summary>
<p>
Example keybindings:
```json
[
{
"bindings": {
"ctrl-cmd-,": "terminal_panel::ToggleFocus",
"ctrl-cmd-.": "workspace::ZoomIn",
}
},
{
"context": "Terminal",
"bindings": {
"cmd-.": "terminal_panel::ToggleFocus"
}
},
{
"context": "!Terminal",
"bindings": {
"cmd-.": ["workspace::SendKeystrokes", "ctrl-cmd-, ctrl-cmd-."]
}
},
]
```
Demo:
https://github.com/user-attachments/assets/1b1deda9-7775-4d78-a281-dc9622032ead
</p>
</details>
Release Notes:
- Added the actions: `workspace::ZoomIn` and `workspace::ZoomOut` that
complement the existing `workspace::ToggleZoom` action
🔜
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>
- Edit prediction providers can now be configured through the settings
UI
- Cleaned up the status bar menu to only show _configured_ providers
- Added to the status bar icon button tooltip the name of the active
provider
- Only display the data collection functionality under "Privacy" for the
Zed models
- Moved the Codestral edit prediction provider out of the Mistral
section in the agent panel into the settings UI
- Refined and improved UI and states for configuring GitHub Copilot as
both an agent and edit prediction provider
#### Todos before merge:
- [x] UI: Unify with settings UI style and tidy it all up
- [x] Unify Copilot modal `impl`s to use separate window
- [x] Remove stop light icons from GitHub modal
- [x] Make dismiss events work on GitHub modal
- [ ] Investigate workarounds to tell if Copilot authenticated even when
LSP not running
Release Notes:
- settings_ui: Added a section for configuring edit prediction providers
under AI > Edit Predictions, including Codestral and GitHub Copilot.
Once you've updated you can use the following link to open it:
zed://settings/edit_predictions.providers
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Partially addresses #11473
MVP of dev containers with the following capabilities:
- If in a project with `.devcontainer/devcontainer.json`, a pop-up
notification will ask if you want to open the project in a dev
container. This can be dismissed:
<img width="1478" height="1191" alt="Screenshot 2025-12-08 at 3 15
23 PM"
src="https://github.com/user-attachments/assets/ec2e20d6-28ec-4495-8f23-4c1d48a9ce78"
/>
- Similarly, if a `devcontainer.json` file is in the project, you can
open a devcontainer (or go the devcontainer.json file for further
editing) via the `open remote` modal:
https://github.com/user-attachments/assets/61f2fdaa-2808-4efc-994c-7b444a92c0b1
*Limitations*
This is a first release, and comes with some limitations:
- Zed extensions are not managed in `devcontainer.json` yet. They will
need to be installed either on host or in the container. Host +
Container sync their extensions, so there is not currently a concept of
what is installed in the container vs what is installed on host: they
come from the same list of manifests
- This implementation uses the [devcontainer
CLI](https://github.com/devcontainers/cli) for its control plane. Hence,
it does not yet support the `forwardPorts` directive. A single port can
be opened with `appPort`. See reference in docs
[here](https://github.com/devcontainers/cli/tree/main/example-usage#how-the-tool-examples-work)
- Editing devcontainer.json does not automatically cause the dev
container to be rebuilt. So if you add features, change images, etc, you
will need to `docker kill` the existing dev container before proceeding.
- Currently takes a hard dependency on `docker` being available in the
user's `PATH`.
Release Notes:
- Added ability to Open a project in a DevContainer, provided a
`.devcontainer/devcontainer.json` is present
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: Danilo Leal <67129314+danilo-leal@users.noreply.github.com>
This bug was caused by using two separate keys for writing/reading from
the KVP database. The bug didn't show up in my debug build because there
was an old entry of a valid key.
I added an integration test for this feature to prevent future
regressions as well.
Release Notes:
- debugger: Fix a bug where the stack frame filter state wouldn't
persist between sessions
We were just deleting them before
Co-Authored-By: Matthew Chisolm <mchisolm0@gmail.com>
Closes #ISSUE
Release Notes:
- Fixed restoring window location for single-file worktrees
Co-authored-by: Matthew Chisolm <mchisolm0@gmail.com>
Closes#44090
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Release Notes:
- python: Improved sorting order of toolchains in monorepos with
multiple local virtual environments.
- python: Fixed toolchain selector not having an active toolchain
selected on open.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Co-authored-by: Smit <smit@zed.dev>
Release Notes:
- pane::ActivatePreviousItem and pane::ActivateNextItem now toggle the
most recent pane when called from a dock panel
a couple months ago i posted a work around that used `SendKeystrokes` to
cycle through pane items when focused on a dock.
#35253
this pr would add this functionality to the these actions by default.
i implemented this by adding an action listener to the workspace level.
------
if the current context is a dock that does not hold a pane
it retrieves the most recent pane from `activation_history` and
activates the next item on that pane instead.
- `"Pane > Editor"`
cycles through the current pane like normal
- `"Dock > Pane > Terminal"`
also cycles through the pane items like normal
- `"Dock > (Any Child that is not a child of Pane)"`
cycles through the items of the most recent pane.
this is the standard behavior in VS Code i believe.
in the video below you can see the actions cycling through the editor
like normal when focus is on the editor.
then you can see the editor continue to cycle when the focus is on the
project panel.
and that the focus stays on the project panel.
and you can see the action cycle the terminal items when the focus is
moved to the terminal
https://github.com/user-attachments/assets/999ab740-d2fa-4d00-9e53-f7605217e6ac
the only thing i noticed is that for this to work the keybindings must
be set above `Pane`
so they have to be set globally or on workspace. otherwise they do not
match in the context
We'll now add panels to the workspace as soon as they're ready rather
than waiting for all the rest to complete. We should strive to make all
panels fast, but given that their load tasks are fallible and do IO,
this approach seems more resilient.
Additionally, we'll now start loading the agent panel at the same time
as the rest.
Release Notes:
- workspace: Add panels as soon as they are ready
This PR finally removes the `CheckboxWithLabel` component, which is not
fully needed given the `Checkbox` can take a `label` method. Then, took
advantage of the opportunity to add more methods with regards to label
customization (position, size, and color) in both the `Checkbox` and
`Switch` components.
Release Notes:
- N/A
