Closes #ISSUE
it is was still in
[discussion](https://github.com/zed-industries/zed/discussions/37983)
Release Notes:
- Added: `--reuse` (`-r`) CLI flag to replace the workspace in an
existing window instead of opening a new one
This PR adds a new `--reuse` (`-r`) CLI flag that allows users to
replace the workspace in an existing Zed window instead of opening a new
one or adding files to the current workspace.
### What it does
The `--reuse` flag finds an available local workspace window and
replaces its workspace with the newly specified paths. This provides a
third workspace opening mode alongside the existing `--add` and `--new`
flags.
### Implementation Details
- **CLI Flag**: Added `--reuse` (`-r`) flag with proper mutual exclusion
with `--add` and `--new`
- **Window Replacement**: Uses the existing `replace_window` option in
`workspace::OpenOptions`
- **Window Selection**: Reuses the first available local workspace
window
- **Fallback Behavior**: When no existing windows are found, creates a
new window
- **Test Coverage**: Added comprehensive test for the reuse
functionality
### Behavior
- `zed -r file.txt` - Replaces the workspace in an available window with
`file.txt`
- If no windows are open, creates a new window (same as default
behavior)
- Mutually exclusive with `-a/--add` and `-n/--new` flags
- Works with multiple files and directories
### Files Changed
- `crates/cli/src/cli.rs` - Added `reuse` field to `CliRequest::Open`
- `crates/cli/src/main.rs` - Added CLI argument definition and parsing
- `crates/zed/src/zed/open_listener.rs` - Implemented reuse logic and
added tests
- `crates/zed/src/zed/windows_only_instance.rs` - Updated for Windows
compatibility
### Testing
- ✅ Unit tests pass
- ✅ Manual testing confirms expected behavior:
- Works when no windows are open
- Replaces workspace in existing window
- Maintains compatibility with existing `-a` and `-n` flags
- Proper help text display
## Manual testing
#### In this first video we do a couple of tests:
* **1**: What happens if we use the -r flag when there are no windows
open?
- works as expected. It opens the files in a new window.
* **2**: Does it work as expected if there is already a window open.
Does it overrides the workspace?
- yes it does. When opening a different file it overrides the current
window instead of creating a new one.
* **3**: Does the -n flag still works as expected?
- yes, it creates the project in a new window
* **4**: What about the -a flag?
- yes, on the last accessed page
* **5**: we do the replace command. It overrides the first opened
window, do we want this behavior?
- It is good enough that it overrides one of the opened windows with the
new project. It still makes the user automatically go to the window with
the specified files
* **6**: we use the -r command again replacing the workspace with a new
one.
- this indeed worked as expected
https://github.com/user-attachments/assets/f1cd7f4b-f4af-4da2-a755-c0be7ce96c0d
#### In here the we check how the --help flag now displays the new
command. (Description was later updated)
https://github.com/user-attachments/assets/a8a7a288-d926-431b-a9f9-a8c3d909a2ec
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>
This is needed for #38914 and seems generally useful to have for
contextual keybindings.
Release Notes:
- N/A
---------
Co-authored-by: David Kleingeld <davidsk@zed.dev>
Changes that I made:
- add "scrollbar.thumb.active_background" to all themes
- for dark themes: scrollbar.thumb.background is darker than hover (fg4
from palette for background and fg0 for hover)
- for light themes: scrollbar.thumb.background is lighter than hover
(fg4 for background and fg0 for hover like in dark theme case)
Those changes is consistent with VSCode gruvbox theme and other
applications.
For active_background I chose orange color, but we can use cyan color to
match vscode theme.
UPDATE: decided to use blue for active scrollbar as this color is used
as accent in other parts of gruvbox themes
Release Notes:
- Improved scrollbar colors for Gruvbox theme
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
## 🎯 Description
Adds configurable window control buttons (minimize, maximize, close)
positioning for Linux, allowing users to choose between macOS-style
(left side) or Windows-style (right side) placement.
## ✨ Features
- New `title_bar.window_controls_position` setting with `"left"` and
`"right"` options
- Left positioning: macOS style (Close → Minimize → Maximize)
- Right positioning: Windows style (Minimize → Maximize → Close)
- Fixed transparent background issues for window controls
- Maintains consistent styling with Zed's theme
## 🔧 Technical Changes
### Settings System
- Added `WindowControlsPosition` enum in `settings_content.rs`
- Extended `TitleBarSettingsContent` with `window_controls_position`
field
- Updated `TitleBarSettings` to include the new configuration
### Title Bar Layout
- Modified `platform_title_bar.rs` to use setting for layout positioning
- Added conditional logic for `justify_start()` vs `justify_between()`
based on position
- Fixed transparent container background by adding `bg(titlebar_color)`
### Window Controls
- Updated `platform_linux.rs` to reorder buttons based on position
setting
- Changed button background from `ghost_element_background` to
`title_bar_background`
- Implemented proper button sequencing for both positions
## 🧪 How to Test
1. Add to your Zed settings:
```json
{
"title_bar": {
"window_controls_position": "left"
}
}
```
or
```json
{
"title_bar": {
"window_controls_position": "right"
}
}
```
2. Restart Zed
3. Verify buttons are positioned correctly
4. Check that background is not transparent
5. Test button functionality (minimize, maximize, close)
## �� Expected Behavior
- **Left position**: Buttons appear on the left side of the title bar in
Close → Minimize → Maximize order
- **Right position**: Buttons appear on the right side of the title bar
in Minimize → Maximize → Close order
- **Background**: Solid background matching Zed's theme (no
transparency)
## 🔍 Files Changed
- `crates/settings/src/settings_content.rs` - Added enum and setting
- `crates/title_bar/src/title_bar_settings.rs` - Updated settings struct
- `crates/title_bar/src/platform_title_bar.rs` - Modified layout logic
- `crates/title_bar/src/platforms/platform_linux.rs` - Updated button
ordering and styling
## 🎨 Design Rationale
This feature provides Linux users with the flexibility to choose their
preferred window control button layout, improving the user experience by
allowing them to match their desktop environment's conventions or
personal preferences.
## ✅ Checklist
- [x] Code compiles without errors
- [x] Settings are properly serialized/deserialized
- [x] Background transparency issues resolved
- [x] Button ordering works correctly for both positions
- [x] Layout adapts properly based on configuration
- [x] No breaking changes to existing functionality
## 🔗 Related
This addresses the need for customizable window control positioning on
Linux, providing consistency with user expectations from different
desktop environments.
Closes#40608
This fixes tabbing in both the settings ui nav bar and page content
going off screen instead of scrolling the focused element into a visible
view.
The bug occurred because `gpui::list` and `gpui::uniform_list` only
render visible elements, preventing non visible elements in a view from
having their focus handle added to the element tree. Thus making the tab
stop map skip over those elements because they weren't present.
The fix for this is scrolling to reveal non visible elements and then
focus the selected element on the next frame.
Release Notes:
- settings ui: Auto scroll to reveal items in navigation bar and window
when tabbing
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
A cherry-pick of
f5188d55fb
This fixes a hard-to-reproduce crash caused excerpts removal not
updating previous snapshot data after corresponding inlay data was
removed.
Same branch has a test:
8783a9eb4f
that does not fail on `main` due to different way inlays are queried, it
will be merged later.
Release Notes:
- N/A
Closes#5294
This PR adds a line ending indicator to the status bar, hidden by
default as discussed in
https://github.com/zed-industries/zed/issues/5294.
### Changes
- 8b063a22d8700bed9c93989b9e0f6a064b2e86cf add the indicator and
`status_bar.line_endings_button` setting.
- ~~9926237b709dd4e25ce58d558fd385d63b405f3b changes
`status_bar.line_endings_button` from a boolean to an enum:~~
<details> <summary> show details </summary>
- `always` Always show line endings indicator.
- `non_native` Indicate when line endings do not match the current
platform.
- `lf_only` Indicate when using unix-style (LF) line endings only.
- `crlf_only` Indicate when using windows-style (CRLF) line endings
only.
- `never` Do not show line endings indicator.
I know this many options might be overdoing it, but I was torn between
the pleasant default of `non_native` and the simplicity of `lf_only` /
`crlf_only`.
My thinking was if one is developing on a project which exclusively uses
one line-ending style or the other, it would be nice to be able to
configure no-indicator-in-the-happy-case behavior regardless of the
platform zed is running on. But I'm not really familiar with any
projects that use exclusively CRLF line endings in practice. Is this a
scenario worth supporting or just something I dreamed up?
</details>
- 01174191e4cf337069e7a31b0f0432ae94c52515 rename the action context for
`line ending: Toggle` -> `line ending selector: Toggle`.
When running the action in the command palette with the old name I felt
surprised to be greeted with an additional menu, with the new name it
feels more predictable (plus now it matches
`language_selector::Toggle`!)
### Future work
Hidden status bar items still get padding, creating inconsistent spacing
(and it kind of stands out where I placed the line-endings button):
<img alt="the gap after the indicator is larger than for other buttons"
src="https://github.com/user-attachments/assets/24a346d4-3ff6-4f7f-bd87-64d453c2441a"
/>
I started a new follow-up PR to address that:
https://github.com/zed-industries/zed/pull/39992
Release Notes:
- Added line ending indicator to the status bar (disabled by default;
enabled by setting `status_bar.line_endings_button` to `true`)
We very frequently move this in and out of the windows slot map on
`update_window_id` calls (and we call this a lot!). This alone showed up
as `memmove`s at roughly 1% perf in Instruments when scrolling a buffer
which makes sense, `Window` itself is 4kb in size. The fix is simple,
just box the `Window` instances, moving a pointer is cheap in
comparison.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
I noticed that branch picker doesn't close until the checkout operation
is completed.
While normally it's not an issue, it becomes obvious if there are longer
running post checkout hooks. In that case selecting a branch makes it
feel like nothing has happened (there's a small indicator in the footer)
so it's possible to click it multiple times. Closing the modal before
the operation completes leads to the error modal saying `Failed to
change branch. entity released. Please try again.` even though the
checkout was successful.
The new behavior is to close the branch picker as soon as the branch is
selected. This also aligns with the existing behavior in `create_branch`
where `cx.emit(DismissEvent);` is called without waiting for
`repo.update`.
And as I mentioned before there an indicator in the footer saying `git
switch <branch_name>` with a spinner thingy.
I also added a check in the picker's `open` function where it first
checks if there's currently an active job and does not show the picker
in that case.
If this generally makes sense I can add the tests as well if needed.
P.S I checked how it works in VSCode and yes it also closes the branch
picker as soon as the branch is selected. The only difference is that
they show the loading indicator right next to the branch name (with a
new branch) but in our case the current branch and activity indicator
are located in different places.
<details><summary>Before</summary>
https://github.com/user-attachments/assets/adf08967-d908-45fa-b3f6-96f73d321262
</details>
<details><summary>After</summary>
https://github.com/user-attachments/assets/88c7ca41-7b39-42d6-a98b-3ad19da9317c
</details>
Release Notes:
- The branch picker now closes immediately after a branch is selected,
instead of waiting for the branch switch to complete.
Closes#39865
Release Notes:
- Fixed file finder display when searching for files in history if you
had several worktrees opened in a workspace. It now displays the
worktree root name to avoid confusion if you have several files with
same name in different worktrees.
---------
Signed-off-by: Benjamin <5719034+bnjjj@users.noreply.github.com>
Closes #ISSUE
Adds a `Maybe<T>` type to `settings_content`, that makes the distinction
between `null` and omitted settings values explicit. This unlocks a few
more settings in the settings UI
Release Notes:
- N/A *or* Added/Fixed/Improved ...
We were dropping the entities once we created the buffers, so the weak
entities could never be upgraded. This treats new locations we see the
same as we would for a read/write call and stores the entity so that we
can follow like we normally would.
Release Notes:
- acp: Fix following not working with certain tool calls.
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
Reduces peak stack usage in these functions and should generally be a
bit performant.
Display map benchmark results
```
To tab point/to_tab_point/1024
time: [531.40 ns 532.10 ns 532.97 ns]
change: [-2.1824% -2.0054% -1.8125%] (p = 0.00 < 0.05)
Performance has improved.
Found 1 outliers among 100 measurements (1.00%)
1 (1.00%) high severe
To fold point/to_fold_point/1024
time: [530.81 ns 531.30 ns 531.80 ns]
change: [-2.0295% -1.9054% -1.7716%] (p = 0.00 < 0.05)
Performance has improved.
Found 3 outliers among 100 measurements (3.00%)
2 (2.00%) high mild
1 (1.00%) high severe
```
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Continues the work from #35927 to add a git diff view for stash entries.
[Screencast From 2025-09-17
19-46-01.webm](https://github.com/user-attachments/assets/ded33782-adef-4696-8e34-3665911c09c7)
Stash entries are [represented as
commits](https://git-scm.com/docs/git-stash#_discussion) except they
have up to 3 parents:
```
.----W (this is the stash entry)
/ /|
-----H----I |
\|
U
```
Where `H` is the `HEAD` commit, `I` is a commit that records the state
of the index, and `U` is another commit that records untracked files
(when using `git stash -u`).
Given this, I modified the existing commit view struct to allow loading
stash and commits entries with git sha identifier so that we can get a
similar git diff view for both of them.
The stash diff is generated by comparing the stash commit with its
parent (`<commit>^` or `H` in the diagram) which generates the same diff
as doing `git stash show -p <stash entry>`. This *can* be
counter-intuitive since a user may expect the comparison to be made
between the stash commit and the current commit (`HEAD`), but given that
the default behavior in git cli is to compare with the stash parent, I
went for that approach.
Hoping to get some feedback from a Zed team member to see if they agree
with this approach.
Release Notes:
- Add git diff view for stash entries
- Add toolbar on git diff view for stash entries
- Prompt before executing a destructive stash action on diff view
- Fix commit view for merge commits (see #38289)
Add new `workspace::NewFileSplit` action which expects a
`SplitDirection` argument, allowing users to programmatically control
the direction of the split in keymaps, for example:
```json
{
"context": "Editor",
"bindings": {
"ctrl-s ctrl-h": ["workspace::NewFileSplit", "left"],
"ctrl-s ctrl-j": ["workspace::NewFileSplit", "down"],
"ctrl-s ctrl-k": ["workspace::NewFileSplit", "up"],
"ctrl-s ctrl-l": ["workspace::NewFileSplit", "right"]
}
}
```
Release Notes:
- Added `workspace::NewFileSplit` action, which can be used to
programmatically split the editor in the provided direction.
Co-authored-by: Rian Drake <rian.drake@rocketwerkz.com>
Co-authored-by: dino <dinojoaocosta@gmail.com>
This is an in-progress work on changing how task scheduler affects
performance of project search. Instead of relying on tasks being
executed at a discretion of the task scheduler, we want to experiment
with having a set of "agents" that prioritize driving in-progress
project search matches to completion over pushing the whole thing to
completion. This should hopefully significantly improve throughput &
latency of project search.
Release Notes:
- Improved project search performance
---------
Co-authored-by: Smit Barmase <smit@zed.dev>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Release Notes:
- Added comment language injections for builtin languages. This enables
highlighting of `TODO`s and similar notes with the comment extension
installed.
Signed-off-by: Donnie Adams <donnie@thedadams.com>
Related to #9461, inspired by #39683
`await` and `yield` both seem somewhat debatable on whether they should
be considered the be control flow keywords.
For now I went with:
- `await`: no – The control flow effect of `await` is at a level does
not seem relevant for syntax highlighting.
- `yield`: yes – `yield` directly affects the output of a generator, and
is also included for consistency with Rust (#39683).
Happy to change these either direction.
<img width="1151" height="730" alt="SCR-20251008-izus"
src="https://github.com/user-attachments/assets/533ea670-863a-4c5c-aaa5-4a9bfa0bf0dd"
/>
---
Release Notes:
- Improved granularity of keyword highlighting for JS/TS/TSX: Themes can
now specify `keyword.control` for control flow keywords like `if`,
`else`, `return`, etc.
Adding this content after seeing people ask about how to make MCP
servers installed from Zed be picked up by external agents. At the
moment, this varies depending on the agent, and felt relevant to be
documented.
Release Notes:
- N/A
- Notable change is the use of a newtype for `ReplicaId`
- Fixes `WorktreeStore::create_remote_worktree` creating a remote
worktree with the local replica id, though this is not currently used
- Fixes observing the `Agent` (that is following the agent) causing
global clocks to allocate 65535 elements
- Shrinks the size of `Global` a bit. In a local or non-collab remote
session it won't ever allocate still.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Let's say you run this:
```
cd ~/proj-a
zed ~/proj-b
```
The `zed` process will execute with `current_dir() = ~/proj-a`, but a
`worktree_root_path() = ~/proj-b`. The old detection was then checking
if the Yarn SDK was installed in `proj-a` to decide whether to set the
tsdk value or not. This was incorrect, as we should instead check for
the SDK presence inside `proj-b`.
Release Notes:
- Fixed the Yarn SDK detection when the Zed pwd is different from the
opened folder.
The page about PHP in the docs doesn’t explain how to use Xdebug. I had
a lof of trouble setting it up the first time, then recently had another
headache trying to get it to work again, because the value for `adapter`
had changed from `PHP` to `Xdebug`.
It’s likely that my example config isn’t perfect or has redundant stuff
or whatever, feel free to amend it.
I also took the liberty to set the Phpactor and Intelephense headings to
level 3 because I felt like they were part of "Choosing a language
server."
Release Notes:
- N/A
