Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configurable keybindings #107

Open
msirringhaus opened this issue Jun 24, 2019 · 8 comments
Open

Configurable keybindings #107

msirringhaus opened this issue Jun 24, 2019 · 8 comments

Comments

@msirringhaus
Copy link

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
Copy link
Contributor

fominok commented Jun 24, 2019

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
Copy link
Author

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
Copy link
Contributor

fominok commented Jun 25, 2019

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

@msirringhaus
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

little-dude commented Jul 1, 2019

@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
Copy link
Author

open

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants