Option to Automatically Close Window on Last Tab Closed

[donatj]

Check for existing issues

• Completed

Describe the feature

So I have Zed set as my git EDITOR, explicitly zed -n --wait

When I run $ git commit or $ git rebase -i or such it pops open Zed.

I'd really like an option for a window with no open tabs and no open directory to auto-close.

When I save and close the window with CMD+S, CMD-W though I am left with this little window with nothing going on

It'd be great if the whole window just closed. I could see this being a configurable option.

[notpeter]

Here's how you configure this for other editors (source):

code --wait
subl -n -w
mate -w
open -Wn

We could conceivably add a similar -w or --wait

Edit: Zed has the same:

  -w, --wait
          Wait for all of the given paths to be opened/closed before exiting

  -n, --new
          Create a new workspace

[donatj]

That's not the problem. You already have a --wait that waits.

I've got in my gitconfig

[core]
        editor = zed -n --wait

It waits fine. It works fine. The process closes when I close the tab, as you'd want for a git EDITOR. That all works fine.

The problem is just I'm left with this empty window afterwards.

Update: Reworded my original ticket a little to hopefully make the issue clearer.

[notpeter]

Gotcha. When launched via zed --new --wait {FILE} closing the single file should cause the workspace to exit -- matching vscode behavior for code --wait {FILE}.

[notDavid]

I assume adding an option is still considered? Because the solution mentioned by @notpeter only works in this specific situation;

Personally i'd prefer a config option, so it works in all situations.
Like how Sublime Text has close_windows_when_empty = "If true and no folder is open in the active window, the window will be closed when the last file is closed."

[notpeter]

@notDavid I think that's reasonable. VSCode has it as window.closeWhenEmpty too.

p.s. nice username

[neur0manc]

I think the editor should go back to the terminal as well, as soon as the newly created buffer is saved and closed. The usual workflow, at least for me, is

• you trigger the external editor, let's say by issuing the command git commit
• edit your commit message in the editor
• save and "close", signalling that you're done with the commit message
• then you return to the terminal, and this is an important thing to emphasise. on macOS with sublime text for example, the window focus is returned to the terminal that was used to call the external editor.

So when the last pane in the active window closes, Zed should also close the current window and then return the application focus back to the calling application (even should there exist other zed windows).

This might even make sense to have as a command line option.

[notpeter]

My gut feeling is that the default behavior should be:

• opened with --wait: close the workspace on last tab close
• otherwise: don't close the workspace on last tab close

And then close_windows_when_empty should overide the above behavior in either circumstance.

As for returning focus to the calling application, I have no idea how to do this when there is an existing workspace open. My current workaround is to use Zed stable for my commit messages and Zed Preview for everything else, but I understand that is generally impractical. VSCode does not support this behavior. If you open code --wait filename with project2 open, closing the filename toggles focus to project2 just like the current Zed behavior.

SublimeText on the other hand is out there making us all look bad and is somehow how returning focus to the Terminal window from whence it was spawned, even when it has other projects open. I'm not positive how this works -- perhaps it walks up the process parentage until it finds a GUI app to which it can redirect focus? I have no idea. But now I want this for Zed. Thanks for raising the bar @neur0manc.

Unless someone has a POC of how to do that, I would consider it out of scope for this issue -- we can create a dedicated enhancement request if the rest of this is implemented without that.

[neur0manc]

@notpeter I'm not at all eloquent in Rust but I have a lot of time on my hands, so I'd at least take a look. Do you have an idea where in the codebase this would have to be implemented? I also want so this for Zed :)

Also I just think it is nice that discussion has not been automatically closed by a stalebot ❤

EDIT: Diving into https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#birds-eye-view-of-zed , should clear up a thing or two.

[notpeter]

Look here:

zed/crates/workspace/src/pane.rs

Lines 1211 to 1218 in 2e7a89c

	pub fn close_active_item(
	&mut self,
	action: &CloseActiveItem,
	window: &mut Window,
	cx: &mut Context<Self>,
	) -> Option<Task<Result<()>>> {
	if self.items.is_empty() {
	// Close the window when there's no active items to close, if configured

[mikayla-maki]

FYI, there is a setting that controls this at all times:

  // Whether the window should be closed when using 'close active item' on a window with no tabs.
  // May take 3 values:
  //  1. Use the current platform's convention
  //         "when_closing_with_no_tabs": "platform_default"
  //  2. Always close the window:
  //         "when_closing_with_no_tabs": "close_window",
  //  3. Never close the window
  //         "when_closing_with_no_tabs": "keep_window_open",
  "when_closing_with_no_tabs": "platform_default",

with platform_default, on macOS, this causes the window to close when the last tab is closed for all windows, and to not do that on Linux and Windows. Maybe a new setting here for "auto", that uses platform_default unless you're in the --wait case?

[notpeter]

@mikayla-maki Related, but slightly different, when_closing_with_no_tabs is whether the workspace closes when you press cmd-w with no open tabs, but the behavior here is looking for the workspace to auto-close when the last tab is closed if under --wait.

I don't know whether we would need to store some additional state whether we were started via wait to facilitate that check, perhaps added to OpenOptions:

zed/crates/workspace/src/workspace.rs

Lines 5956 to 5960 in 2e7a89c

	pub struct OpenOptions {
	pub open_new_workspace: Option<bool>,
	pub replace_window: Option<WindowHandle<Workspace>>,
	pub env: Option<HashMap<String, String>>,
	}

When it's created in open_local_workspace:

zed/crates/zed/src/zed/open_listener.rs

Lines 408 to 411 in 2e7a89c

	async fn open_local_workspace(
	workspace_paths: Vec<String>,
	open_new_workspace: Option<bool>,
	wait: bool,

[mikayla-maki]

Ahhh I see, sorry I forgot how it worked 😅 . Thanks for the clarification @notpeter

[Write]

I'm interested too for that feature / enhancement.