Custom typable commands

[the-mikedavis]

Regular commands can be rebound but typable commands (anything entered in command mode, :) can't be modified in any way.

You might use custom typable commands to implement file operations in conjunction with #3134 for example. You might define :mv as :sh mv $file $1 or :rm as :sh rm $1. (The syntax to use for variables, or whether to use variables at all should be discussed.)

Custom typable commands could also be used to create custom abbreviations for commands.

[kendfss]

Does the editor already support custom commands and just not typables?

I was thinking it would be nice to have something like:

[custom.commands]
bring_line_up = {
  cmds = [ 'push_register', 'extend_line', 'delete_selection', 'move_line_up', 'paste_before', 'pop_register' ] # semicolon separates operations' names from parameters' arguments. 
  desc = "swap line with above"
  mode = editor || prompt || both
}

[kendfss]

or set the mode via - vs _. I think that would be a more cumbersome implementation to maintain though.

[the-mikedavis]

You can already map keys to lists of commands (https://docs.helix-editor.com/master/remapping.html) to create custom non-typable commands. You can also rebind the normal_mode, insert_mode and select_mode commands to - (minus when configuring this in config.toml) and/or _. This issue is only about creating typable commands: ones entered in command mode with : that optionally take arguments.

[kendfss]

Could separate func name from params with ;
Though, I was/am assuming what you wanted could be reproduced by sequence(s) of the builtin ones. Sorry if not.

[the-mikedavis]

Combining sequences of typable commands is covered by this. For example #6857 might be written as:

# Note: this is not implemented.
[commands]
":wcb" = [":write", ":buffer-close"]

Handling the arguments of the commands is also important for the design of this feature though. If you wanted :wcb to take the filename to write, you would need a syntax for where to place the argument (in :write's arguments rather than :buffer-close). Maybe this could be expressed as [":write %arg{1}", ":buffer-close"] (using syntax like in #3393).

There are nuances to this though (optional arguments, aliases, command names / docs) so maybe this issue is better handled by plugins once the plugin system exists instead. We don't want to create new programming languages in the config TOML.

[kendfss]

That looks so sick! Imagine if we could define all key remaps like that! We could just escape for "\\space"
What about using an environment-variable-like syntax for those sorts of things. Just $FILE/\\$PWD to escape to pass literals to terminal (or vice versa/option for that)?
I think a great thing about helix is not needing plugins, lol. That said, I do think, it would be good to have a way to share snippets.

edit:
I've not yet read on the state of helix plugins, so forgive this ramble:
Like if we get imports working, we can separate public things from private things. Just publish everything in a designated file to some server which keeps a database of usernames and commands. we could have something like ":fetch user.cmd" then you just use my_remap = "user.cmd" in your config. we could just have packages :fetch package.cmd or :fetch package. Could also be cool to have :share command|file_aka_package
It could also be set up in a more distributed way using repository hosts, in which case you might have :fetch host.user.cmd and use git to clone (or just scrape the relevant file; if designated) and extract the desired command. I guess :fetch host.user would be a convenient option too for working through ssh. Git could probably handle authentication and whatnot.

That's all to say, plugin systems can get really hairy. They're complex, and easy to break on user-side. Just save ourselves time and keep it snippety, lol.

[rcorre]

What about using an environment-variable-like syntax for those sorts of things. Just $FILE/\$PWD to escape to pass literals to terminal (or vice versa/option for that)?

#3134