feat: allow quitting the app with escape when there's no selection

[janbuchar]

This allows making a key binding that first cancels visual mode, search, selections, etc., and if there is no such thing, it quits Yazi.

I use Yazi in neovim inside a floating window and my other tools can be closed with escape as well, so this is nice for me usability-wise, and should be opt-in.

How can I update the docs, do I just submit another PR to the website repo?

[janbuchar]

This is to make it possible to explicitly invoke the default behavior (what happened previously when opt was empty)

[sxyazi]

Sorry, I'm afraid I can't accept this PR.

I prefer to keep each command as simple as possible, and this new escape --quit command is essentially a combination of the escape and quit commands, which leads to overlapping functionality.

I prefer each command to do only one thing. If you want to implement exiting by pressing Esc, I suggest implementing it through a simple plugin:

-- ~/.config/yazi/plugins/smart-escape.yazi/init.lua
return {
  entry = function()
    local active = cx.active
    local current = active.current

    local esc = active.mode.is_visual or #active.selected > 0 or current.files.filter or current.cwd.is_search
    ya.manager_emit(esc and "escape" or "quit", {})
  end,
}

Then bind it to your <Esc> key:

[[manager.prepend_keymap]]
on  = [ "<Esc>" ]
run = "plugin --sync smart-escape"

Note: There's a missing check for escape_find because finder is currently not exposed to the Lua API, but I can add it if you need.

[janbuchar]

I prefer to keep each command as simple as possible, and this new escape --quit command is essentially a combination of the escape and quit commands, which leads to overlapping functionality.

Fair enough.

I prefer each command to do only one thing. If you want to implement exiting by pressing Esc, I suggest implementing it through a simple plugin:

Thanks for the snippet! Can I find a detailed reference for the plugin api anywhere? When I checked, it was hard for me to find out what functionality is exposed through the context.

Note: There's a missing check for escape_find because finder is currently not exposed to the Lua API, but I can add it if you need.

Well, I'm not sure if I need it now. However, it seems wrong to me to duplicate (and keep in sync) internals of the escape command in a plugin. Could we expose the return value of the command to the plugin API? Or is it already there?

[sxyazi]

Can I find a detailed reference for the plugin api anywhere?

Here it is https://yazi-rs.github.io/docs/plugins/types#app-data

it seems wrong to me to duplicate (and keep in sync) internals of the escape command in a plugin

I didn't quite understand this, could you explain it in more detail?

Could we expose the return value of the command to the plugin API? Or is it already there?

Not supported at the moment, but it may be added in the future.

I still need to think it through carefully because currently, all commands do not return a value, including the escape command here. Its function signature is:

pub fn escape(&mut self, opt: impl Into<Opt>) {

Instead of something like:

pub fn escape(&mut self, opt: impl Into<Opt>) -> bool {

This would be a large change to the event system.

[janbuchar]

it seems wrong to me to duplicate (and keep in sync) internals of the escape command in a plugin

I didn't quite understand this, could you explain it in more detail?

Well, in the plugin, we basically rewrite a part of the escape command in lua. If a new UI element that is controlled with the escape key is added, I will have to reflect that in the plugin. That doesn't seem ideal.

Could we expose the return value of the command to the plugin API? Or is it already there?

Not supported at the moment, but it may be added in the future.

I still need to think it through carefully because currently, all commands do not return a value, including the escape command here.
This would be a large change to the event system.

I understand, and it may be too much of a niche use case anyway. Still, it would make it trivial to "extend" the escape command.

[sxyazi]

If a new UI element that is controlled with the escape key is added, I will have to reflect that in the plugin

Yes, this is currently a problem with the plugin system. However, it's unlikely that the behavior of the escape key will be changed because I consistently refuse to add new behaviors to it. An example is the 'unyank' command, which was added as a new command rather than being integrated into the 'escape' sequence.

Adding too many behaviors would cause inconvenience. Currently, some actions require pressing Esc twice in a row to reach the desired state, and adding more behaviors might increase this to three presses, which is not good for user experience.

it would make it trivial to "extend" the escape command

I plan to add a method parallel to ya.manager_emit in the future called ya.manager_exec. This method will allow for obtaining the return value of commands (if any). However, this involves redesigning the event and plugin system, so it's not a priority right now. The current priority is to ensure the stability of the plugin API.

---

I am going to close this PR. If you have any other questions, feel free to reply.

[janbuchar]

I plan to add a method parallel to ya.manager_emit in the future called ya.manager_exec. This method will allow for obtaining the return value of commands (if any). However, this involves redesigning the event and plugin system, so it's not a priority right now. The current priority is to ensure the stability of the plugin API.

Okay, sounds good!