Command aliases

[sxyazi]

This proposal aims to introduce the concept of command aliases to simplify existing shell and plugin commands.

Alias commands are treated as special command markers, with everything following the marker considered parameters for the actual command. This allows:

{ on = "<C-t>", run = """
  shell 'echo "Hello world"' --confirm
""" }

to be rewritten as:

{ on = "<C-t>", run = '; echo "Hello world"' }

Here, the ; marker represents shell '...' --confirm. Similarly, it enables:

{ on = "<C-t>", run = """
  plugin --sync my-plugin --args='--foo "bar baz"'
""" }

to be written as:

{ on = "<C-t>", run = '! my-plugin --foo "bar baz"' }

In this case, the ! marker stands for plugin --sync ... --args='...', greatly simplifying command writing.

Note that the ; and ! markers are not final and require further discussion — such as whether to use ;; or !! instead of a single character. Also, we need to determine which marker to use for commands like shell --confirm 'ya pub dds-cd --str "/tmp"', one possible way is:

{ on = "<C-t>", run = "@ dds-cd /tmp" }

We also need to consider a separate marker for async plugins, i.e., just plugin without --sync.

[AnirudhG07]

For the shell command, how would you go about using $0, $@?

[sxyazi]

I don't really like this idea - but still thanks for your input @boydaihungst! Here's my reason:

It takes a problem that only affects two commands (shell, plugin) and spreads it across the entire keymap rules, making the whole keymap more complex.

To achieve this, we'd have to introduce these extra new fields (run_shell, run_plugin) and corresponding ones like (block, orphan, interactive, sync, etc.) to the keymap rule.

Since these fields are at the same level, it becomes hard to understand their meanings out of context. For example, consider these combinations:

• { on = "x", run = "open", block = true } – semantically, this seems reasonable, “open the current file in block mode,” but it doesn't do anything because block only available to run_shell not run.
• { on = "x", run = "open", orphan = true } – same issue as above.
• { on = "x", run = "open", run_shell = "xdg-open ..." } – since run and run_shell are at the same level, the user could write this, but it behaves incorrectly. To fix this, we'd have to introduce the concept of priority (like when run_shell exists, run should be ignored, or vice versa), which would increase the complexity of the keymap.

Also, it's hard to explain the behavior of these fields in the documentation because each field has its own context. If the same options appear in different commands in the future, it would be even more complicated. In one context, option foo does one thing, but in another context, it does something completely different.

In the original proposal, for example, I only introduced an ! alias for the plugin command, which means I could mention it specifically next to the command (plugin), without having to carry that mental burden across the entire keymap or all commands. Also, aliases are a common concept — almost every shell has them.

Another advantage of command aliases is that they're still just strings, which means they can be used elsewhere. For example, for the future ya emit subcommand mentioned in #1610 (comment), which allows remote calls to a command in Yazi, you could use it like this:

ya emit "! my-plugin --foo"
# Equivalent to:
ya emit "plugin my-plugin --args='--foo'"

[boydaihungst]

You're right. 👍