feat: suspend process (Ctrl-Z)

[sxyazi]

New Feature: You can press Ctrl-Z to suspend Yazi in the background, and then use fg to resume it

An implementation of the feature request: #105

Close #105

---

1.mp4

[teto]

that's weird, I've recompiled from scratch 230362d and I cant suspend (nixos). Would be curious if someone else can try

[sxyazi]

@teto Hey, this is a new command, if you're not using the default config, you'll need to add it to your config file:

yazi/config/preset/keymap.toml

Line 7 in 230362d

{ on = [ "<C-z>" ], exec = "suspend", desc = "Suspend the process" },

[teto]

ha I see. I am not familiar with how it is implemented usually but this mapping works for 99% of the software out of the box, I feel like this should be maybe a (compiled) default.

BTW: it worked.

[sxyazi]

I feel like this should be maybe a (compiled) default

It is already included in the default config of Yazi, so this is the default behavior.

For users who were using their own config files before this feature was introduced, they will need to add it themselves. I want to clarify -- this is based on Yazi's conservative expectation of user config, rather than bringing uncertain "surprises" to users, it seems better to let users find and add them when they truly need them.

---

I am not familiar with how it is implemented usually but this mapping works for 99% of the software out of the box

Regarding the implementation details, Yazi and similar TUI apps run in raw mode, accepting all user input. Therefore, Ctrl-Z cannot be handled by bash/zsh, and can only be listened to and processed by Yazi when users press it.

[teto]

Thank you very much for the explanation, I supposed that yazi was catching everything; I guess in most cases, zsh catches the Ctrl-Z and is the one sending the signal.

this is based on Yazi's conservative expectation of user config, rather than bringing uncertain "surprises" to users

I dont really mind either way but in this case the uncertain surprise is to have "Ctrl-Z" not working IMO. The number of times I had a misfunctioning program that I stopped with Ctrl-C is huge. Let's say for some reason yazi goes into an infinite loop, having Ctrl-C registered automatically makes sense

[sxyazi]

I supposed that yazi was catching everything; I guess in most cases, zsh catches the Ctrl-Z and is the one sending the signal

Yes, when a TUI app is running in raw mode, it needs to handle all user keypresses by itself. However, when running in cooked mode, keys like Ctrl-Z and Ctrl-C are typically handled by the shell.

Let's say for some reason yazi goes into an infinite loop, having Ctrl-C registered automatically makes sense

Given the reasons mentioned above, this doesn't seem to hold true. Since Ctrl-C needs to be handled by the TUI app, not the shell, there might not be an opportunity to process Ctrl-C when the app is consuming 100% CPU.

in this case the uncertain surprise is to have "Ctrl-Z" not working IMO

Are you meaning hardcoding the registration of Ctrl-Z for all users in the code? If that's the case, it seems like an impact on potential user keybindings. Some users (like me) may not frequently use the "suspend" and could have Ctrl-Z bound to other actions, considering that this key is close to Ctrl :)

[teto]

Are you meaning hardcoding the registration of Ctrl-Z for all users in the code? If that's the case, it seems like an impact on potential user keybindings. Some users (like me) may not frequently use the "suspend" and could have Ctrl-Z bound to other actions, considering that this key is close to Ctrl :)

since yazi doesn't merge the default config with user's config, what I suggest is something we do in neovim too: when the program starts, it maps Ctrl-z to suspend before loading the system/user configuration: users are thus free to remap Ctrl-Z.