this pr enables opening a specific line in a diff using zed's cli
Release Notes:
- refactor: add possibility to open specific line in a diff using the
cli
---------
Co-authored-by: Cole Miller <cole@zed.dev>
# Objective
Fix error shown when attempting to undo/redo operations on excluded
files, for example, undoing a creation of a file in an excluded path.
## Solution
Since `worktree::Snapshot::entry_for_path` always returns `None` for
excluded files, these changes will simply avoid calling
`UndoManager::record` in `ProjectPanel::confirm_edit` if the created
entry is excluded. This can be confusing if the user is renaming a file
to another path that is excluded, as that will not be recorded and can't
be undone but we accept it as a limitation for now and will document
that.
In the future we can potentially support undoing of operations for
excluded file paths but that would mean not only introducing new methods
that operate directly on the absolute path instead of the entry id, as
well as changes to the proto messages, in order to ensure it's also
fixed in remote and collab.
## Testing
Tested manually, as shown in the "Showcase" section below and also
introduced a test for this –
`project_panel::tests::undo::excluded_create_is_not_recorded` .
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
## Showcase
<details>
<summary>Before</summary>
https://github.com/user-attachments/assets/7f8fca3e-2716-40bb-95db-c7119bb39b83
</details>
<details>
<summary>After</summary>
https://github.com/user-attachments/assets/47b0322e-a323-4648-8a56-6e96266888d3
</details>
---
Release Notes:
- N/A
# Objective
Users in a read-only project should have no permission to create,
rename, move, trash or delete files, as such, they should also have no
way to undo or redo these actions. These changes ensure that the
listeners for both `project_panel::Undo` and `project_panel::Redo` are
only registered if the project is not read-only.
## Solution
The `ProjectPanel` listeners for both the `Undo` and `Redo` actions were
not gated behind the existing `!Project::is_read_only` call, on
`ProjectPanel::render`, so these changes move the listeners inside that
check.
## Testing
Currently, there isn't an easy way to manually test this, as these
actions were already disabled in collab and the easiest way to get into
a read-only project is connect as a collab guest. However, in order to
ensure this continues being asserted once we remove the collab
restriction, the
`project_panel::tests::undo::undo_redo_unavailable_for_read_only_collab_guest`
test has been added.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
---
Release Notes:
- N/A
# Objective
Add remote (SSH) and collaboration support for trashing and restoring
files in the project panel, which in turn enables undo/redo of trash
operations against remote and collab projects.
Relates to #5039.
## Solution
- Updated the project panel undo system to carry `TrashId` instead of
`TrashedEntry`.
- Using `TrashedEntry` could get hairy, as it includes paths, which
wouldn't play too nicely when using, for exapmle, macOS as the client
and Windows as the host. Using a simple identifier is much easier in
this regard and simplifies implementation.
- Enabled the Trash action and context-menu entry on remote projects,
and removed the command palette filter in `ProjectPanel::new` that was
still hiding the action on remote.
- As far as I can tell, there isn't a reliable way to detect whether a
given remote actually supports the OS trash, so we expose the action
everywhere rather than guessing. On a remote without trash support the
action will fail when invoked but this is a conscious tradeoff until we
find a better way to handle this.
- `fs` now tracks trashed files in a `SlotMap<TrashId, TrashedEntry>` on
each `Fs` implementation. Trashed files are referenced by an opaque
`TrashId` instead of passing a `TrashedEntry` around, which avoids
serializing filesystem paths in remote messages.
- Split the old `delete_entry(trash: bool)` API into distinct
`trash_entry`/`trash_file` (returning a `TrashId`) and
`delete_entry`/`delete_file` across `Project`, `Worktree`,
`LocalWorktree` and `RemoteWorktree`.
- This lets us drop the optional trash result (`Option<TrashedEntry>`)
from the delete path and require a `TrashId` from the trash path.
- Added new proto messages (`TrashProjectEntry`,
`TrashProjectEntryResponse`, `RestoreProjectEntry`,
`RestoreProjectEntryResponse`) to let clients request the host to trash
or restore entries.
- This deprecates `DeleteProjectEntry::use_trash`, but the host still
honors it. An older collab peer may request trashing via that flag
instead of the newer `TrashProjectEntry`. If the host ignored it, a
newer host would permanently delete a file the user meant to send to the
trash. The field will be removed in a later PR once all supported peers
use `TrashProjectEntry`.
## Testing
The following tests were introduced to ensure the new behavior is
correctly tested:
* `remote_server::remote_editing_tests::test_remote_trash_restore` –
Tests trashing a project entry in remote
*
`remote_server::remote_editing_tests::test_remote_delete_project_entry_with_trash`
– Test to ensure we continue respecting `DeleteProjectEntry::use_trash`
until it is fully removed
* `project_panel::tests::undo::trash_directory_undo_redo` – Not related
to these changes but a nice to have as we were missing a test ensuring
that trashing and then undoing and redoing it for a directory works as
expected
Besides these, the following scenarios were manually tested against a
remote session on the same machine (macOS):
- Trashing → Undo (Restore) → Redo (Trashing)
- Batch Trashing → Undo (Batch Restore) → Redo (Batch Trashing)
- Rename → Undo (Rename) → Redo (Rename)
- Move → Undo (Move) → Redo (Move)
- Batch Move → Undo (Batch Move) → Redo (Batch Move)
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [ ] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Release Notes:
- N/A
---------
Co-authored-by: Yara <git@yara.blue>
This is necessary to remove some `util` dependencies from crates, as
well as better sharing for our projects. This also includes the WIP
AbsPath abstraction as well as some bug fixes from internal tooling.
Release Notes:
- N/A or Added/Fixed/Improved ...
Reordering worktree roots by drag-and-drop had silently broken: a
worktree-root filter added to `disjoint_entries` for delete-safety
stripped roots before the drop handler could see them, so root-to-root
drops never reached the existing `move_worktree` reorder path.
This PR is the minimal regression fix:
- Move the worktree-root filter out of `disjoint_entries` and into
`disjoint_effective_entries` (used by cut/copy/delete), so drag-and-drop
keeps seeing roots and single-root reorder works again via the existing
`move_worktree` path.
- Filter worktree roots out of `drag_onto`'s copy branch, so holding the
copy modifier over a drag that contains a root no longer returns `None`
from `create_paste_path` and silently cancels the whole copy.
- Add `test_drag_worktree_root_reorders_worktrees` exercising the
drag-onto reorder flow end to end.
The larger feature work (multi-root group reordering, blank-area "send
to end", copy-mode drag feedback, and syncing worktree order to
collaborators) has been split into a separate follow-up PR so this fix
can land quickly. Note that worktree order was intentionally not synced
during collaboration, so that change is discussed separately.
Closes#46699
Release Notes:
- Fixed drag and drop to reorder worktrees
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
# Objective
Provide a means of quickly opening a permanent tab from project panel
instead of a preview tab.
Implements #51866 (_Middle click to open file in a new tab_ with 18×↑)
which is also part of #31822 (_Middle Click Improvments_) titled "middle
clicking on a file in the project panel should open the file in a
non-transient state".
With `preview_tabs.enable_preview_from_project_panel` enabled, a click
in the project panel opens a preview tab, and there's no easy gesture to
open a permanent one instead, simplest one currently being a double
click. VS Code and VSCode-based editors recognize middle mouse click as
a way to open a permanent tab since 2016 (microsoft/vscode#14453).
## Solution
Wired up an `on_aux_click` handler for project panel entries:
middle-clicking a file opens it in a permanent tab and focuses it,
regardless of the preview tabs setting.
Added a line to `docs/src/project-panel.md` to reflect the behavior.
## Testing
- Manually tested on Windows: middle click opens a permanent tab,
promotes an existing preview tab to a permanent one if already open,
does nothing for directories
- Haven't tested on macOS/Linux
## Self-Review Checklist:
- [ ] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
<details>
<summary>Click to view showcase</summary>
https://github.com/user-attachments/assets/2de5f23d-637f-4ffc-8d03-02dc11714af4
</details>
---
Release Notes:
- Added support for middle-clicking a file in the project panel to open
it in a permanent tab instead of a preview tab
This PR adds adjustments to the tree view, making it more consistent
with all other tree view displays in the app (e.g., displaying indent
guides, removing chevron toggle, etc.), and also fixes an issue where
the commit message scrollbar was scrolling up with the message.
Release Notes:
- N/A
Release Notes:
- Fixed clear drag overlay when external drag ends outside window
When dragging files from macOS Finder over the project panel and then
dragging back to Finder, the drag overlay remained visible because the
drag state was not properly cleaned up.
The root cause was that only `draggingExited:` was handled, but not
`draggingEnded:`. On macOS:
- `draggingExited:` is called when the drag leaves the window area
- `draggingEnded:` is called when the drag operation ends entirely
When a user drags a file back to Finder and drops it there,
`draggingEnded:` is called but was not being handled.
---------
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
## Summary
On Windows, `trash::delete_with_info` can return an error even when the
file was successfully moved to the Recycle Bin.
This is caused by a race condition in the `trash` crate: after
`IFileOperation::PerformOperations` completes, it re-binds the trashed
item via `SHCreateItemFromParsingName` to read its metadata, but the
shell's virtual namespace cache may not yet reflect the new item,
producing an error. Previously, the delete loop propagated this error
and aborted the entire batch. The outer `detach_and_log_err` swallowed
the error, so the user received no feedback.
This PR handles each entry independently: entries that fail to delete
are skipped, the loop continues, and undo history is recorded for the
entries that succeeded.
The upstream root cause (the post-operation re-bind race in
`zed-industries/trash-rs`) will be addressed separately.
Before:
https://github.com/user-attachments/assets/59a95ac5-098b-42dc-bffb-f3240c6b966d
After:
https://github.com/user-attachments/assets/0cd6c0b3-2ee3-4bf2-a243-3e8a83d05dd7
## Test plan
- [ ] Select multiple files in the project panel on Windows
- [ ] Trash them (right-click > Move to Trash, or `Delete` key)
- [ ] Confirm all selected files are deleted, even if one triggers the
trash-crate race
- [ ] Undo restores the files that were successfully trashed
Release Notes:
- Improved handling of failed trash or delete operations in the Project
Panel in order to display a toast informing the user that some files
could not be trashed or deleted
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Add `ExpandAllEntries` action, keybinding, and right-click context menu
entries for expand/collapse all in the project panel.
- Add `ExpandAllEntries` action + handler + `expand_all_entries()`
method
- Add `cmd-right` / `ctrl-right` keybinding for `ExpandAllEntries`,
mirroring
the existing `cmd-left` for `CollapseAllEntries`
- Add "Expand All" to root-entry and folder right-click context menus
- Add keybinding hint to root-entry "Collapse All" context menu entry
- Per-worktree behavior: context menu actions affect only the selected
worktree,
subfolder "Expand All" expands from that folder down
# Objective
The project panel had no discoverable way to expand or collapse all
entries. The only ways were keyboard shortcuts (`cmd-left` for collapse
all)
or the right-click context menu. The global `ExpandAllEntries` shortcut
(`cmd-right`) was also missing. This PR adds that shortcut and exposes
both actions in the context menu so users learn the keybindings while
keeping the UI minimal.
## Solution
- Add `ExpandAllEntries` action + handler + `expand_all_entries()`
method
- Add `cmd-right` / `ctrl-right` keybinding for `ExpandAllEntries`
(global),
mirroring the existing `cmd-left` for `CollapseAllEntries`
- Add "Expand All" to the right-click context menu for both root entries
and
subfolder entries
- Update root-entry "Collapse All" to show its keybinding hint via
`.action(Box::new(CollapseAllEntries))`
- **Per-worktree behavior**: each root entry's context menu actions
affect
only that worktree, subfolder "Expand All" expands from that folder down
## Testing
- Added 6 GPUI tests in `project_panel_tests.rs`:
- `test_expand_all_entries`: single worktree
- `test_expand_all_entries_multiple_worktrees`: global expand across
worktrees
- `test_expand_all_entries_via_window_dispatch`: action dispatch path
- `test_per_worktree_expand`: expand only the clicked worktree
- `test_per_worktree_collapse`: collapse only the clicked worktree, keep
root visible
- `test_expand_all_entries_with_auto_fold`: expand with auto_fold_dirs
- Ran `cargo test -p project_panel`: 106 pass
**Manual testing for reviewers:**
1. Open a project with nested directories and open the Project Panel
2. Right-click a root entry, confirm "Expand All" and "Collapse All"
appear
with their keybinding hints (`⌘→` / `⌘←`)
3. Right-click a subfolder, confirm "Expand All" and "Collapse All"
appear
4. Click "Expand All" on a subfolder, confirm only that folder's subtree
expands
5. Click "Collapse All", confirm children collapse but the root stays
visible
6. Open a multi-folder workspace. Right-click the second root and click
"Expand All", confirm only that folder expands
7. Press `cmd-right` (or `ctrl-right`), confirm all worktrees expand
globally
Tested on macOS only. Linux and Windows should behave the same since
there
is no platform-specific code.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
https://github.com/user-attachments/assets/adc501d7-8e3a-4687-aef0-dc00426d232d
---
Release Notes:
- Added `Expand All` and `Collapse All` to the project panel right-click
context menu with keybinding hints.
- Added `cmd-right` / `ctrl-right` keybinding to expand all entries.
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Opening a markdown file from the project panel used to require four
steps:
- click the file (opens raw editor)
- right-click the editor tab
- select "Open Markdown Preview"
- then close the raw editor tab
This PR shortcuts that to a single right-click (or keypress) from the
project panel.
Right-clicking a markdown file in the project panel now shows an **Open
Markdown Preview** option. Selecting it opens the rendered markdown
preview directly — no raw editor tab is left behind. The same shortcut
used in the editor (Cmd+Shift+V on macOS, Ctrl+Shift+V on Windows/Linux)
also works when focus is in the project panel.
## How it works
- **Context menu**: `OpenMarkdownPreview` action is registered and
surfaced in the right-click menu only for `.md`/`.markdown` files.
- **Keybinding**: `cmd-shift-v` / `ctrl-shift-v` bound to
`project_panel::OpenMarkdownPreview` in the `ProjectPanel` context,
mirroring the existing editor binding.
- **Loading**: The file is opened via `open_path_preview` with
`focus_item: false, activate: false`, so the raw editor is loaded into
the buffer system but never becomes the visible tab.
- **Preview construction**: `MarkdownPreviewView::create_markdown_view`
is called directly (no `dispatch_action` indirection, which would have
been deferred and caused a race). The preview is added to the active
pane and the raw editor tab is removed atomically in one synchronous
pane update.
- **Pre-existing tabs**: Before loading, all panes are checked for an
existing item at the file's project path. If the file is already open in
raw mode, `remove_item` is skipped — the existing tab is left untouched.
Release Notes:
- Added "Open Markdown Preview" context menu item to Project Panel
markdown entries.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Co-authored-by: Tom Houlé <tom@tomhoule.com>
Share marked selections across rendered project panel entries and defer
drag-related path cloning until drag and drop rendering is enabled. Also
defer symlink path string conversion until tooltip creation.
Release Notes:
- N/A or Added/Fixed/Improved ...
# Objective
- Renaming a folder whose name contains a dot pre-selects only the text
before
the last dot, treating the suffix as if it were a file extension.
- Fixes#59294
## Solution
- `ProjectPanel::rename_impl` computed the rename editor's initial
selection with
`Path::file_stem().len()` for every entry. For a directory such as
`my.folder`,
`file_stem()` returns `my`, so only `my` was selected.
- Directories have no extension, so select the whole name for them.
Files keep
the existing behavior (the last extension is left unselected for quick
renames).
## Testing
- Added `test_rename_folder_with_dot_selects_whole_name` in
`project_panel_tests.rs`.
It fails before the change (folder selection ends at offset 2 of
`my.folder`) and
passes after (offset 9, the whole name); it also asserts a file still
leaves the
last extension unselected.
- `cargo test -p project_panel` — all 100 tests pass.
- `cargo clippy -p project_panel --all-targets --all-features -- --deny
warnings` and
`cargo fmt -p project_panel -- --check` are clean.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards (UX/UI and icon
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed renaming a folder with a dot in its name selecting only the part
before the dot.
---------
Co-authored-by: Finn Evers <finn.evers@outlook.de>
The implementation for this is just below and the comment should have
been long removed.
At least one TODO less in the 100 existing ones 🎉
Release Notes:
- N/A
This is an unsolicited contribution, I hope that's ok. The feature is
small and I didn't want to open a discussion just for this.
There was no way to write to `.git/info/exclude` from Zed, so I added
one.
The "Add to .gitignore" action in the project panel and git panel
context menus is now grouped under a "Git" submenu, with a new "Add to
.git/info/exclude" action next to it.
Both actions:
- skip the write if the pattern is already there
- make sure there's a trailing newline
- show an error toast if something goes wrong
- fail gracefully on remote repositories
In the git panel both entries are disabled unless the file is untracked,
same as the gitignore action was before.
The write logic is shared via a small private helper, covered by two
unit tests.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Added `Add to .git/info/exclude` option under a new `Git` submenu in
the project panel and git panel context menus, alongside the existing
`Add to .gitignore` action.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
When handling click events on entries in project panel, we were
returning early if the click was the one that brought the Zed window
into focus. This effectively ignored the click action on the item. This
leads to two clicks being required to act on an item in the project
panel if the Zed window is out of focus. The existing behaviour is also
inconsistent with other UI controls, where clicking on them when the
window is out of focus actually acts upon them.
This behaviour was introduced in
https://github.com/zed-industries/zed/pull/9553.
This PR fixes the click handler on the entries so that events with
`first_focus() == true` are no longer ignored.
Before:
https://github.com/user-attachments/assets/d51ec11d-c47a-4ea3-af6d-63bf6daf3c44
After:
https://github.com/user-attachments/assets/87b9e6a8-9ef0-463f-8557-e15d25b519ca
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Closes#58261
Release Notes:
- Fixed project panel needing a second click to change the file if the
window is not in focus
cc @Anthony-Eid
## Why
This is the first step in moving the Git Graph work into the Git UI
crate before continuing with follow-up refactors and feature work. The
goal is for Git UI components and shared Git UI helpers to live in one
crate, so future changes to the Git Graph can reuse existing `git_ui`
code instead of duplicating it.
This PR is not only a filesystem move. While moving `git_graph` into
`git_ui`, a few small dependency and helper boundaries had to change:
- `git_graph` and `git_ui` both needed the same remote parsing and
commit tooltip construction behavior, so those pieces are now shared
from `git_ui`.
- `git_graph` previously depended on `project_panel` to resolve
file-history actions from the project panel selection. After moving
`git_graph` into `git_ui`, keeping that dependency would create an
undesirable `git_ui` -> `project_panel` relationship. The
project-panel-specific action forwarding now lives in `project_panel`,
and calls into exported `git_ui::git_graph` helpers instead.
- `git_graph` initialization now happens through `git_ui::init`, so
downstream crates only need to initialize `git_ui`.
This prepares the codebase for the next planned PRs: splitting the large
`git_graph.rs` implementation into smaller pieces, then adding Git Graph
features such as keeping the main branch lane at index `0`.
## License removal
The removed `crates/git_graph/LICENSE-GPL` file was a symlink to the
repository root `LICENSE-GPL`. The moved code is now inside `git_ui`,
which is also licensed as `GPL-3.0-or-later` and has its own
`LICENSE-GPL` symlink to the same root license file. The code did not
move to a differently licensed crate; it remains covered by the same GPL
license.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
---------
Co-authored-by: Anthony Eid <anthony@zed.dev>
I use the One Dark theme, so to actually test if my fix worked, I had to
also do:
```jsonc
"experimental.theme_overrides": {
"warning": "#ff0000",
"modified": "#00ff00",
},
```
| Before | After |
|--------|--------|
| <img width="676" height="254" alt="image"
src="https://github.com/user-attachments/assets/a2831667-1113-49ac-b6aa-1221c71bf997"
/> | <img width="299" height="137" alt="image"
src="https://github.com/user-attachments/assets/ad6e85aa-ba24-47ad-b69d-6d0c3aa3a407"
/> |
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Closes#57443.
Release Notes:
- Fixed Project Panel git status indicator showing modified files with a
warning color instead of the modified color
A bit brute force, but it works.
<img width="1106" height="988" alt="image"
src="https://github.com/user-attachments/assets/d23f9a80-01c5-4ad3-a280-faf8b8bc9dbe"
/>
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
## Summary
Filenames containing md syntax (e.g. `__somefile__`, `*somefile*`) were
being rendered as markdown text in the file deletion confirmation
dialog.
Fixes#55651
## Changes
Wrapped file paths with `MarkdownEscaped` in the single and multi-file
deletion confirmation dialogs in `project_panel.rs`, so special md chars
like `_`, `*`, and `[` are escaped before being rendered.
## Testing
Created a file named `__somefile__` and tried to delete it, the name now
displays literally in the confirmation dialog instead of being rendered
as bold text:
<img width="339" height="206" alt="img"
src="https://github.com/user-attachments/assets/93e4e7d1-d5dc-45bb-9c08-2fe83c75aad2"
/>
Also added `test_delete_prompt_escapes_markdown_in_file_name` in
`project_panel_tests.rs` that verifies filenames with markdown special
characters render literally in the confirmation dialog.
Release Notes:
- Fixed file names containing markdown special characters (e.g.
`__somefile__`)
being rendered as formatted text in the file deletion confirmation
dialog.
Allows using the "View history" functionality also on folders and the
project root, and not only on files.
Renamed "View file history" to "View history" in the context menu to
make it consistent.
<img width="1740" height="769" alt="project_history"
src="https://github.com/user-attachments/assets/7f7f8115-6160-44f5-868f-69ac942df8e4"
/>
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Added git history for folders and whole project
---------
Co-authored-by: Anthony Eid <anthony@zed.dev>
## Summary
This PR replaces the git file history view with the git graph view that
doesn't render the graph canvas. This has several advantages
1. Benefits from the graphs performance and lazy loading
2. Gets the graph's search for free
3. Resizable columns
4. The commit information panel
5. Is persistent
6. Cleans up a lot of code
The one con of this change is the graph doesn't have support
remote/collab support yet, but that is a WIP and should be merged within
a week.
Also, the git graph now propagates errors to the UI, which is the last
thing on the graph's stable launch todo list!
Before you mark this PR as ready for review, make sure that you have:
- [x] Added a solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
- [x] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Co-authored-by: Joseph T. Lyons <JosephTLyons@gmail.com>
This PR adds a "Add to .gitignore" action to the project panel's
right-click context menu. Similar to the "Restore File" action that I
previously added, I frequently find myself wanting this in the project
panel.
<img width="380" height="391" alt="image"
src="https://github.com/user-attachments/assets/e4438fbe-b070-40c8-9e57-84b003fa5c15"
/>
With the restore file option:
<img width="382" height="408" alt="image"
src="https://github.com/user-attachments/assets/84425de8-04e5-4969-8991-edc46e6420dc"
/>
Notes:
- **Implementation**: The `add_to_gitignore` function is essentially
copy-pasted from `git_panel.rs`.
- **Error handling**: Added toast notification on error, which is
consistent with `restore_file` in project_panel and `perform_checkout`
in git_panel.
Note that `add_to_gitignore` in git_panel does NOT show a toast (just
uses `detach_and_log_err`). I don't know if this is on purpose.
To follow up, I can either: match the project_panel implementation to
the git_panel one (no toast), or update the git_panel implementation to
also show a toast on error.
- **Menu grouping**: Previously "Restore File" and "View File History"
were in separate sections, but both relate to git. With this third git
action, I grouped all three together under a single separator (see
screenshot).
We could also keep "View File History" separate and only group "Restore
File" + "Add to .gitignore" together (both modify the working tree state
in some way), if we don't want to alter the existing UI too much.
Release Notes:
- Added "Add to .gitignore" option to the project panel context menu for
files in git repositories.
---------
Co-authored-by: Chris Biscardi <chris@christopherbiscardi.com>
This fixes#53869.
Creating a new file from the project panel background menu failed when a
single local project was empty and its root was hidden. In that state
there are no visible entries to seed `expanded_dir_ids`, so the action
returned early before opening the filename editor.
This initializes that state lazily from the root entry when creating a
new item, and adds a regression test for the empty hidden-root path.
Release Notes:
- Fixed creating a new file from the project panel context menu in empty
local projects
- Adds a status toast to the announcement banner for surfacing the
layout revert option
- Removes the agent panel banner
A good chunk of the diff here was because I touched up the status toast
component API a little bit.
Release Notes:
- N/A
Update the way `pane::RevealInProjectPanel` is handled to ensure that,
regardless of whether the file belongs to any open project, the project
panel is always activated and focused.
This refactor is a result of some internal feedback after changing its
handling so as to show a notification stating that the item that the
user was trying to reveal didn't belong to an open project
– https://github.com/zed-industries/zed/pull/51246 .
We feel users are probably already used to relying on `cmd-shift-e` (on
macOS), in pretty much every context, in order to open the project
panel, and so having situations where it doesn't actually happen seems
like a bad user experience.
Relates to #23967
Release Notes:
- Improved `pane: reveal in project panel` to open the project panel,
even if working with an unsaved buffer.
- Introduce `project_panel::Redo` action
- Update all platform keymaps in order to map
`redo`/`ctrl-shift-z`/`cmd-shift-z` to the `project_panel::Redo` action
### Restore Entry Support
- Update both `Project::delete_entry` and `Worktree::delete_entry` to
return the resulting `fs::TrashedEntry`
- Introduce both `Project::restore_entry` and `Worktree::restore_entry`
to allow restoring an entry in a worktree, given the `fs::TrashedEntry`
- Worth pointing out that support for restoring is not yet implemented
for remote worktrees, as that will be dealt with in a separate pull
request
### Undo Manager
- Split `ProjectPanelOperation` into two different enums, `Change` and
`Operation`
- While thinking through this, we noticed that simply recording the
operation that user was performing was not enough, specifically in the
case where undoing would restore the file, as in that specific case, we
needed the `trash::TrashedEntry` in order to be able to restore, so we
actually needed the result of executing the operation.
- Having that in mind, we decided to separate the operation (intent)
from the change (result), and record the change instead. With the change
being recorded, we can easily building the operation that needs to be
executed in order to invert that change.
- For example, if an user creates a new file, we record the
`ProjectPath` where the file was created, so that undoing can be a
matter of trashing that file. When undoing, we keep track of the
`trash::TrashedEntry` resulting from trashing the originally created
file, such that, redoing is a matter of restoring the
`trash::TrashedEntry`.
- Refer to the documentation in the `project_panel::undo` module for a
better breakdown on how this is implemented/handled.
- Introduce a task queue for dealing with recording changes, as well as
undo and redo requests in a sequential manner
- This meant moving some of the details in `UndoManager` to a
`project_panel::undo::Inner` implementation, and `UndoManager` now
serves as a simple wrapper/client around the inner implementation,
simply communicating with it to record changes and handle undo/redo
requests
- Callers that depend on the `UndoManager` now simply record which
changes they wish to track, which are then sent to the undo manager's
inner implementation
- Same for the undo and redo requests, those are simply sent to the undo
manager's inner implementation, which then deals with picking the
correct change from the history and executing its inverse operation
- Introduce support for tracking restore changes and operations
- `project_panel::undo::Change::Restored` – Keeps track that the
file/directory associated with the `ProjectPath` was a result of
restoring a trashed entry, for which we now that reverting is simply a
matter of trashing the path again
- `project_panel::undo::Operation::Restore` – Keeps track of both the
worktree id and the `TrashedEntry`, from which we can build the original
`ProjectPath` where the trashed entry needs to be restored
- Move project panel's undo tests to a separate module
`project_panel::tests::undo` to avoid growing the
`project::project_panel_tests` module into a monolithic test module
- Some of the functions in `project::project_panel_tests` were made
`pub(crate)` in order for us to be able to call those from
`project_panel::tests::undo`
### FS Changes
- Refactored the `Fs::trash_file` and `Fs::trash_dir` methods into a
single `Fs::trash` method
- This can now be done because `RealFs::trash_dir` and
`RealFs::trash_file` were simply calling `trash::delete_with_info`, so
we can simplify the trait
- Tests have also been simplified to reflect this new change, so we no
longer need a separate test for trashing a file and trashing a directory
- Update `Fs::trash` and `Fs::restore` to be async
- On the `RealFs` implementation we're now spawning a thread to perform
the trash/restore operation
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Relates to #5039
Release Notes:
- N/A
---------
Co-authored-by: Yara <git@yara.blue>
Co-authored-by: Miguel Raz Guzmán Macedo <miguel@zed.dev>
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes#53116
Video
[Screencast from 2026-04-04
19-14-55.webm](https://github.com/user-attachments/assets/d17945d6-b17c-435d-8155-648cd7ba574b)
Release Notes:
- Fixed: File duplication rename now selects the entire filename stem
instead of just the " copy" suffix, allowing users to type a new name
without manually clearing text
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
_(Feature Requests #24962)_
_"Before you mark this PR as ready for review, make sure that you
have:"_
* [x] Added a solid test coverage and/or screenshots from doing manual
testing
* [x] Done a self-review taking into account security and performance
aspects
* [x] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- Added a `sort_order` to `project_panel` settings which dictates how
files and directories are sorted relative to each other in a
`sort_mode`.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Update how `workspace::pane::Pane` handles the `RevealInProjectPanel`
action so as to display a notification when the user attempts to reveal
an unsaved buffer or a file that does not belong to any of the open
projects.
Closes#23967
Release Notes:
- Update `pane: reveal in project panel` to display a notification when
the user attempts to use it with an unsaved buffer or a file that is not
part of the open projects
---------
Signed-off-by: Pratik Karki <pratik@prertik.com>
Co-authored-by: dino <dinojoaocosta@gmail.com>
This PR adds tracking of project groups to the MultiWorkspace and
serialization/restoration of them. This will later be used by the
sidebar to provide reliable reloading of threads across Zed reloads.
Release Notes:
- N/A
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
## Context
TODO
## Self-Review Checklist
<!-- Check before requesting review: -->
- [ ] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Release Notes:
- N/A
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
- **Remove some of the settings types from ui**
- **drag settings-less ui across the line**
Self-Review Checklist:
- [ ] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A
---------
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
Self-Review Checklist:
- [ ] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A
## Context
This adds a setting for controlling the sidebar side
## Self-Review Checklist
<!-- Check before requesting review: -->
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
---------
Co-authored-by: Eric <eric@zed.dev>
This PR adds Git status badges next to file names in the Project Panel,
following my older PR #49802
These are enabled by having "git_status" true.
Screenshot
<img width="343" height="320" alt="image"
src="https://github.com/user-attachments/assets/b2c208bf-5027-4947-a5ee-eeb74fadb02b"
/>
I'd love to hear feedback about any of this :)
Especially feedback on these:
- File name colour is determined only by Git status, the diagnostic
badges remain separate. Should diagnostics also affect the filename
colour?
- (Unstaged) Modified files and staged modifications share the same
colour, in vscode staged modifications use a brownish colour by default
which I could not find the colours. I think differentiating them is
definetely something to add.
Release Notes
- Added git status indicators in Project Panel. It can be enabled by
setting `git_status_indicator` to `true` in `project_panel` settings.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Closes#48765
Release Notes:
- Fixed appends copy marker for copied file in the wrong position of
filename
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
- Add `project_panel::undo::UndoManager` with a bounded operation stack
to track and revert project panel operations
- Support undoing file and directory creation, renaming, moving, pasting
and drag-and-drop operations
- Revert batch operations sequentially in reverse order to handle
dependencies between them
- Show an error notification when one or more undo operations fail
- Add "Undo" entry to the project panel context menu, disabled when
there is nothing to undo
- Gate the feature behind the `project-panel-undo-redo` feature flag
Ref: #5039
Release Notes:
- N/A
---------
Signed-off-by: Marco Mihai Condrache <52580954+marcocondrache@users.noreply.github.com>
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: dino <dinojoaocosta@gmail.com>
The tab context menu has "Copy Path", "Open in Terminal", and "Reveal In
Project Panel" but no way to reveal the file in the system file manager.
This action already exists in three other context menus (editor
right-click, project panel, outline panel) but was missing from tab
right-click.
## Changes
Adds a platform-specific entry to the tab context menu:
- **macOS:** "Reveal in Finder"
- **Windows:** "Reveal in File Explorer"
- **Linux:** "Reveal in File Manager"
Placed after "Copy Relative Path" and before "Pin Tab". Gated behind
`is_local` (including WSL with host interop) to match the project
panel's behavior. Uses the existing `project.reveal_path()`
infrastructure, which handles platform-specific file manager invocation
and WSL path conversion.
## Prior art
Every major editor has this in the tab context menu:
- VS Code: "Reveal in Finder" (macOS) / "Reveal in File Explorer"
(Windows)
- JetBrains IDEs: Right-click tab -> "Open in" -> "Finder"
- Sublime Text: Right-click tab -> "Reveal in Finder"
Zed already has this in the editor body right-click menu (`Cmd-K R`),
project panel (`Alt-Cmd-R`), and outline panel. The tab context menu was
the only place it was missing.
This contribution was developed with AI assistance (Claude Code).
Release Notes:
- Added "Reveal in Finder" to the tab context menu
## Screenshot
---------
Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Part of #29026
## Summary
https://github.com/user-attachments/assets/35b4f969-1fcf-45f4-88cd-cbc27ad9696e
macOS Finder places file paths on the system pasteboard using
`NSFilenamesPboardType` when files are copied. Previously, the project
panel only supported its own internal clipboard for copy/cut/paste
operations and ignored system clipboard content entirely. This meant
that copying files in Finder and pasting them in Zed's project panel did
nothing.
This PR adds support for reading file paths from the macOS system
pasteboard, enabling a natural workflow where users can copy files in
Finder (or other file managers) and paste them directly into Zed's
project panel.
> **Note:** Pasting files from a system file manager currently only
works on macOS. The project panel changes are cross-platform, but the
clipboard reading of file paths (`ExternalPaths`) is only implemented in
the macOS pasteboard. Windows and Linux would need equivalent changes in
their respective platform clipboard implementations to support this.
Copying/cutting files from the project panel to the system clipboard as
plain text works on all platforms.
### Changes
**`crates/gpui/src/platform/mac/pasteboard.rs`**
- Read `NSFilenamesPboardType` from the system pasteboard and surface
file paths as `ClipboardEntry::ExternalPaths`
- Check for file paths before plain text, since Finder puts both types
on the pasteboard (without this priority, file paths would be returned
as plain text strings)
- Extract the string-reading logic into `read_string_from_pasteboard()`
to allow reuse
**`crates/project_panel/src/project_panel.rs`**
- On paste, check the system clipboard for external file paths and use
the existing `drop_external_files` mechanism to copy them into the
project
- On copy/cut, write the selected entries' absolute paths to the system
clipboard so other apps can consume them
- Update the "Paste" context menu item to also be enabled when the
system clipboard contains file paths, not just when the internal
clipboard has entries
## Test plan
- [ ] Copy one or more files in Finder, paste in the project panel —
files should be copied into the selected directory
- [ ] Copy files within the project panel, paste — existing internal
copy/paste behavior is preserved
- [ ] Cut files within the project panel, paste — existing internal
cut/paste behavior is preserved
- [ ] Copy files in the project panel, paste in Finder or another app —
paths are available as plain text
- [ ] Right-click context menu shows "Paste" enabled when system
clipboard has file paths
- [ ] Right-click context menu shows "Paste" disabled when both internal
and system clipboards are empty
Release Notes:
- Added support for pasting files from Finder (and other file managers)
into the project panel via the system clipboard (macOS only). Copying or
cutting files in the project panel now also writes their paths to the
system clipboard for use in other apps.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
