Configurable keybindings

[msirringhaus]

I would love to have a more sublime-text like terminal editor. This project seems to drift more towards vim. It might be possible to get both, if keybindings where completely user-configurable with a config-file like sublime does it. Would you be interested in a pull request for something like this?

Goals:

1. Be able to simply copy&paste a sublime-keybindings file (of course most actions are not yet supported).
2. Generate one for the current state as well and make default
3. Safe those and user-defined overwrites (future step) under XDG-paths
4. Make all possible commands available via keybindings or Command prompt

Rough overview

Simple keybinding

	{ "keys": ["ctrl+q"], "command": "exit" },

More complex keybinding

	{ "keys": ["left"], "command": "move", "args": {"by": "characters", "forward": false} },
	{ "keys": ["ctrl+left"], "command": "move", "args": {"by": "words", "forward": false} },
	{ "keys": ["shift+left"], "command": "move", "args": {"by": "characters", "forward": false, "extend": true} },
	{ "keys": ["ctrl+shift+left"], "command": "move", "args": {"by": "words", "forward": false, "extend": true} },

This seems to be very flexible and I think would allow for a vim-like binding as well as sublime-like or maybe even emacs.

Code changes

For now, I would stick with the simple bindings first (although args is not hard to do with rust Enums):

1. Have a function that parses the value of "keys" to map to Event::Key(...)
2. Have a function that parses the value of "command" to enum Command
3. Enhance Command to encompass all possible commands
4. Create a global HashMap<Event::Key, Command> out of steps 1 and 2.
5. Rewrite the match-statements in Tui, Editor and Command to all map to the same functions

This might not be the direction you want to go, which is fine. If so, I would simply create a hard fork and diverge, if thats ok with you.

[fominok]

Looking at the suggested config I see that the only input is key/shortcut, while for modal editors it should also be a mode and some previous info like 2dd. Maybe it would be ok to have a context as an argument for this config to be flexible enough. Anyway, having a command pallete with an ability to control editor without any shortcuts is a must, I think this is the direction, where it should go.

[msirringhaus]

Modal editing can be done (sublime has a Vintage mode for vi-keybindings, based on this keymap and some (don't know enough here) smaller plugins). But it is definitely not a first-class citizen for this kind of config.

Lets do it like this: I currently work on a fork (https://github.com/msirringhaus/xi-term). I pack all keymap-related changes in a separate branch. You can then take a look at it and decide for yourself.

[fominok]

Anyway, the best approach is to have this in xi-core itself

[msirringhaus]

Just fyi: My fork now has support for undo/redo, copy+paste, moving around + selections, and multiple cursors. It is not modal, but I think you could take 90% as is, if you want.

[little-dude]

My fork now has support for undo/redo, copy+paste, moving around + selections, and multiple cursors

@msirringhaus woah that's awesome!

Lets do it like this: I currently work on a fork (msirringhaus/xi-term). I pack all keymap-related changes in a separate branch. You can then take a look at it and decide for yourself.

I'll take a look at your branch as soon as possible (which should be Monday).

[msirringhaus]

Well, that branch has now "long" been merged into master. I think you can just look at HEAD and take what you like.

Most of the really sublime-specific stuff happens in core/config.rs, core/default_keybindings.rs (which is a stupid hack for devel-purposes) and a bit in core/cmd.rs. In core/cmd.rs mostly the naming of things is taken from sublimes keymap file. And, obviously, serde-derives make sense only for those files.

In those files all the parsing from user-input (be it prompt or keyboard shortcuts) to rust enum "Command" happens. Everything below that doesn't care how the commands are derived.

But again, that editor has no modes (which is exactly what I want), so if you want to go in the direction of vim, you need to restructure of course.

[little-dude]

@msirringhaus would you mind opening a PR so we can discuss the changes easily? I have your branch checked out locally already but I can't comment directly on the code.

[msirringhaus]

open