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 #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: