-
-
Notifications
You must be signed in to change notification settings - Fork 634
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Confirm on quit #467
Comments
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!
We do run into cases more frequently where a unified prompt system
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.
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. |
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. |
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 ... |
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. |
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. |
I also believe an "Are you sure?" modal for destructive operations is warranted, where anything but captital |
Nit: I think we shouldn't differ from normal CLI usage, where 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). |
Good enough to start; it's not clear from your demo what happens when other keys but |
I just started using zellij, and I love it, thanks! 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. |
Please support this, I mistakenly hit |
It's 2024 and this still isn't a feature 😭 |
I keep accidentally (somehow?) closing my Zellij session when I have a vertical split open in Vim and hit Edit: Ah, I must have accidentally hit
|
just wrote this in ~1hr so the UI is very simple but it works: download the wasm build from here: and set a keybing to launch it in a floating window:
https://github.com/cristiand391/zj-quit I'll update the readme latter today. |
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:
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).
When using a default keybind to close a pane, it should prompt if the pane includes processes other than what's in step 1.
When using a default keybind to close a tab, it should prompt if any pane in the tab would need a prompt.
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:
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 runningexec 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 likeskipClosePromptForProcesses: ["${inherited}", myCustomShell]
.The text was updated successfully, but these errors were encountered: