Feature: Confirm on quit

[lilyball]

If I have multiple panes/tabs open, quitting loses my layout. Similarly, if I have running processes, quitting terminates them. This is also true for closing tabs or panes.

By contrast, tmux prompts for all of these (when invoked via default keybinds). It also doesn't even have a default bind for kill-session (instead offering a bind for "detach"). This makes it very hard to accidentally lose work in tmux. And the easiest way to kill panes in tmux is to exit the process running in it (and killing windows is typically done by killing all panes).

I think zellij has the opportunity to strike a middle ground here. Here's my suggestions:

1. Like macOS Terminal.app, Zellij could have a notion of "processes that are okay to close without confirmation". Terminal.app always includes your login shell in that list, and by default includes "screen" and "tmux" (presumably because those can detach and resume later). Zellij would preferably have a config entry for processes to use.

   Until such time as Zellij has a way to override preferences on a per-preference basis, it should probably omit screen/tmux from the list (and the login shell would always be included even with an empty list).

2. When using a default keybind to close a pane, it should prompt if the pane includes processes other than what's in step 1.
3. When using a default keybind to close a tab, it should prompt if any pane in the tab would need a prompt.
4. When using a default keybind to quit zellij, it should prompt if any tab would need a prompt.

The close prompts would ideally identify any processes that are the reason for the prompt (again, this is something that Terminal.app does), though just saying it will "close running processes" is acceptable.

Zellij should support also actions to bypass the confirm prompt, for use in custom keybinds for people who want it. A few suggestions, ordered by my aesthetic preference:

- action: [SkipConfirm: Quit,] # or [SkipConfirm: [Quit]]
- action: [QuitWithoutConfirm]
- action: [Quit: NoConfirm]

There's also the inverse, e.g. ConfirmBeforeQuit as the default, but this means anyone who's already customized their keybinds won't get the confirmations.

Additional thoughts

Experimentally, I believe macOS Terminal.app's notion of "login shell" is "any entry in /etc/shells that is the direct child of the root login instance for the tab" (meaning running exec login -f $USER from the shell requires a prompt before closing as the process list is now login > login > shell).

One possible way to override preferences on a per-preference basis is to have a special entry for "the default value". Something like ${default} or ${inherited} (inherited would make sense if zellij ever supports including one config file in another, because then you can build your config in layers). This way the config could be something like skipClosePromptForProcesses: ["${inherited}", myCustomShell].

[a-kenji]

Thank you for taking the time writing this down. This is a pain point of many people and I like many of the solutions you proposed!

By contrast, tmux prompts for all of these (when invoked via default keybinds).

We do run into cases more frequently where a unified prompt system could be an elegant answer, I am sure at some point this will be a reality.

Until such time as Zellij has a way to override preferences on a per-preference basis, it should probably omit screen/tmux from the list (and the login shell would always be included even with an empty list).

I thought it is probably hard to maintain such a list, but I think having people optionally specify safe processes to quit from in a list is a good way around that.

- action: [SkipConfirm: Quit,] # or [SkipConfirm: [Quit]]

This is also by far my most favorite solution, since it could support other commands, that would ask for some form of confirmation - in a rather elegant way.

[khs26]

Agreed on this proposal - another risk zellij has at the moment is the same as vim in normal mode. If you don't realise what mode you're in and you e.g. paste text or just start typing, then you have the potential to cause havoc in your session.

[lilyball]

@khs26 I just filed this as https://github.com/zellij-org/zellij/issues/491

[jovandeginste]

Also on other "terminating" operations, like "tab close" and "pane close".

I keep forgetting to switch modes, and start typing in pane mode (or tab mode), at some point hit "x" and boom all is gone ...

[colemickens]

Huge +1 from me, my silly brain keeps seeing the Quit option and choosing it when I really almost always just want to detach.

Is it feasible to "detect" if the user has stuff running or not? It seems like if it's just the default shell running in a single pane/tab, it could still just exit.

[jovandeginste]

The only time this is really useful, is when a process is hanging inside a pane. In all other scenarios, I just terminate the process/shell (ctrl+d) and repeat over all tabs and panes until the last one is closed.

I understand this is my personal view on things, but I would appreciate it to be harder to accidentally kill processes by default. I did this by remapping all destructive bindings to include the Ctrl modifier.

[jovandeginste]

I also believe an "Are you sure?" modal for destructive operations is warranted, where anything but captital Y means "no" and cancels the destruction.

[matthiasbeyer]

where anything but captital Y means "no" and cancels the destruction.

Nit: I think we shouldn't differ from normal CLI usage, where [yN] or [y/N] is a pseudo standard. That would mean that no answer would default to "no", and y or Y would mean yes. Only allowing uppercase Y for "yes" would differ from that pseudo standard and only confuse users.

But besides this very small nit, I agree that zellij should add confirmation messages for all destructive operations (and options to turn them off, possibly on a per-action level).

[a-kenji]

This is the state of a current draft:

[jovandeginste]

This is the state of a current draft:

Good enough to start; it's not clear from your demo what happens when other keys but y or n are used?

[telatin]

I just started using zellij, and I love it, thanks! My problem here is that if I open an editor whose exit shortcut is Ctrl+Q, zellij exit instead (without warning as OP)

I hope I'm in the right thread to add my 2 cents, but because I use screen/tmux (and not zellij of course) exactly to keep my session alive, I think an exit shortcut should be unambiguously mapped (like Ctrl+A,D in screen), and not something so common like Ctrl+Q.

[t18n]

Please support this, I mistakenly hit Ctrl + Q it all the time. :D

[wholegrainloaf]

It's 2024 and this still isn't a feature 😭 Can we please get this soon? The screencap earlier in this thread would be lovely!

[kekkoudesu]

I keep accidentally (somehow?) closing my Zellij session when I have a vertical split open in Vim and hit CTRL+W+Q to quit one of the splits; for some reason it takes down my entire session despite there being both more tabs open in Zellij and in Vim. This feature would help guard against that.

Edit: Ah, I must have accidentally hit CTRL+Q in my haste. This fixed my problem:

shared_except "locked" {
        unbind "Ctrl q"
}

[cristiand391]

just wrote this in ~1hr so the UI is very simple but it works:

download the wasm build from here: https://github.com/cristiand391/zj-quit/releases

and set a keybing to launch it in a floating window:

    bind "Alt q" {
      LaunchOrFocusPlugin "file:/path/to/zj-quit.wasm" {
        floating true
      }
    }

https://github.com/cristiand391/zj-quit

I'll update the readme latter today.