Add "Close Folder" option in menu#45274
Conversation
cla-bot
bot
added
the
cla-signed
|
Hey, thanks for the PR! I tested this change and discussed internally with some colleagues and we were a bit unsure what problem this is solving. If you run this action, it just leaves you with an empty, no-project window. How is this useful? And how is this different from simply opening a new blank window? |
|
Thanks for looking into it. Well, when I need to close current project and open a new one, I have to close the old project window manually. That works obviously. As I am used to vscode and vscode has this option I often open project in the same window (it says in the layout position in the desktop so i don't have to adjust it's position again) |
|
Oh I see... well, if you open the project picker and just hit enter to open a new project, it just resues the current window and sort of solves your use case? Screenshot.2025-12-18.at.5.04.mov |
|
Yes. But for new projects, to clone a remote repo, I need to open new window. For existing projects. It works fine. Maybe I need to explore Zed more and move out from vscode memories.😬 |
|
Another related one: #45345
Seems that overall, people need this a lot for ssh projects to "disconnect", and they do not understand that they can open the new window or do not want this. |
My usage scenario: I use Zed as my go-to text editor for quick note-taking. I need to jot things down immediately upon opening it. However, if I previously had a project open, reopening Zed will automatically load that same project again. In this case, I need a 'Close Folder'/'Close Project' feature to close the currently open project, allowing me to take standalone notes. |
|
Simple answer is "I just want to close current project". And it's very common option in menus. You can have "Close Editor", "Close Window" option, but not the "Close Folder". I never user those other two in my coding life. Only thing I use often is missing. |
|
I don't get it why the question even comes to validate the necessity of this simple option. I have to open a lot of new projects. I don't want to see my previous code each time I open the editor after I am done. Hope Zed team will merge this. |
There was a problem hiding this comment.
Pull request overview
This pull request adds a "Close Folder" action that allows users to close all open project folders in their workspace via keyboard shortcuts or the application menu. The feature is properly restricted to prevent usage in collaborative projects where closing folders would be inappropriate.
Changes:
- Added a new
CloseFolderworkspace action with implementation to close all visible worktrees - Integrated keyboard shortcuts across all platforms (ctrl-k f / cmd-k f)
- Added menu item in File menu between "Close Editor" and "Close Window"
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| crates/workspace/src/workspace.rs | Added CloseFolder action definition, implementation method, and action listener registration |
| crates/zed/src/zed/app_menus.rs | Added "Close Folder" menu item in File menu |
| assets/keymaps/default-windows.json | Added ctrl-k f keyboard shortcut |
| assets/keymaps/default-macos.json | Added cmd-k f keyboard shortcut |
| assets/keymaps/default-linux.json | Added ctrl-k f keyboard shortcut |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if worktree_ids.is_empty() { | ||
| return; | ||
| } | ||
|
|
There was a problem hiding this comment.
For clarity and to make the borrow scope explicit, consider dropping the project read lock before the update loop. While Rust's borrow checker should handle this correctly, adding an explicit drop(project); after line 3136 would make it clearer that the read lock is intentionally released before attempting to mutate the project. This follows defensive programming practices and makes the code's intent more obvious to readers.
| } | ||
|
|
||
| fn close_folder(&mut self, _: &CloseFolder, _window: &mut Window, cx: &mut Context<Self>) { | ||
|
|
There was a problem hiding this comment.
There's an extra blank line at the beginning of the function. This should be removed for consistency with other function implementations in the codebase.
| cx, | ||
| ); | ||
| return; | ||
| } |
There was a problem hiding this comment.
The check for collaborative projects only validates is_via_collab(), but the similar add_folder_to_project function also checks for remote server projects. Consider whether remote server projects should also be restricted from closing folders. If closing folders should be allowed in remote server projects, this is fine. However, consistency with add_folder_to_project should be considered - if users cannot add folders in collab projects, they likely shouldn't be able to close them either, and the same logic may apply to remote server scenarios.
| } | |
| } | |
| if project.is_remote_server() { | |
| self.show_error( | |
| &anyhow!("You cannot close folders in a remote project"), | |
| cx, | |
| ); | |
| return; | |
| } |
| fn close_folder(&mut self, _: &CloseFolder, _window: &mut Window, cx: &mut Context<Self>) { | ||
|
|
||
| let project = self.project.read(cx); | ||
| if project.is_via_collab() { | ||
| self.show_error( | ||
| &anyhow!("You cannot close folders in someone else's project"), | ||
| cx, | ||
| ); | ||
| return; | ||
| } | ||
|
|
||
| let worktree_ids: Vec<WorktreeId> = project | ||
| .visible_worktrees(cx) | ||
| .map(|worktree| worktree.read(cx).id()) | ||
| .collect(); | ||
|
|
||
| if worktree_ids.is_empty() { | ||
| return; | ||
| } | ||
|
|
||
| for worktree_id in worktree_ids { | ||
| self.project | ||
| .update(cx, |project, cx| project.remove_worktree(worktree_id, cx)); | ||
| } | ||
| cx.notify(); | ||
| } |
There was a problem hiding this comment.
This new action lacks test coverage. The workspace module has comprehensive tests (as seen in the #[cfg(test)] section), and similar actions like close_window have test coverage. Consider adding a test that verifies: 1) folders are successfully closed when not in a collaborative project, 2) an error is shown when attempting to close folders in a collaborative project, and 3) the action is a no-op when there are no folders open.
|
@itsfuad @danilo-leal I can see the use case here, though it is very niche. We tend to err on the side of less is more when it comes to dialogs, but how do we feel about something like this from IntelliJ? I often find myself opening a new project and then going back to close the old one. 
|
|
#47365 had been merged, hence wonder if there's anything left to do here. |
This pull request introduces a new "Close Folder" action to the workspace, enabling users to close all open project folders via keyboard shortcuts or the application menu. The implementation ensures that folders cannot be closed in collaborative (shared) projects and updates keymaps for all major platforms.
Workspace functionality:
CloseFolderaction to the workspace actions, allowing users to close all open project folders in the current workspace. This action is disabled for collaborative projects and provides an error message if attempted in such a context. (crates/workspace/src/workspace.rs) [1] [2]Keymap updates:
ctrl-k fcmd-k f(
assets/keymaps/default-linux.json,assets/keymaps/default-windows.json,assets/keymaps/default-macos.json) [1] [2] [3]Menu integration:
crates/zed/src/zed/app_menus.rs)Internal plumbing:
close_folderhandler in the workspace's action listeners to ensure the action is recognized and processed. (crates/workspace/src/workspace.rs)crates/workspace/src/workspace.rs)Closes #45247 & #39660