nushell/reedline

Feature Vision Discussion: Keybindings

sholderbach opened this issue ยท 9 comments

This issue is part of the larger vision discussion managed in #63 to brainstorm and prioritize ideas around features that would make reedline as a line editor for you both viable as well as pleasant to use. Feel free to up-vote features you depend on in other tools/shells as well as suggest new ideas!

Keybinding Features

  • All major functionality should be exposed via keybindings
  • Ability to have multiple keybindings
    • VI Mode
    • Emacs Mode
    • JT Mode (the ability to code like JT)
    • Other
  • Ability to load keybindings from file
  • Ability to execute previously defined code or externals via keybindings
  • Ability to have keybinding chords (multiple keyboard shortcuts in succession execute a particular internal or external command)

Current voting

Vote for the topic(s) you care about by selecting the corresponding emoji. (No judgement based on the emojis sentiment!)

  • ๐Ÿ‘ All major functionality should be exposed via keybindings
  • ๐Ÿ‘Ž Ability to have multiple keybindings (see above)
  • ๐Ÿ˜„ Ability to load keybindings from file
  • ๐ŸŽ‰ Ability to execute previously defined code or externals via keybindings
  • ๐Ÿ˜• Ability to have keybinding chords (see above)

I would like to suggest a Sublime Text (/VS Code/micro) mode with GUI-like keyboard shortcuts, and ideally mouse support.

One suggestion is to include a Kakoune-like mode. I find the interactivity in Kakoune to make more sense and be more conducive to faster navigation and editing flow than how it works in vi.

what syntax should this keybinding file should have?

In nushell it's a yaml file but I'd guess that json, yml, toml, some structured file may work. I'm also guessing that if reedline is already using one of these crates somewhere that we'd want to use whichever one that is in order to keep dependencies down. thoughts?

I think it wouldn't be too hard to create this dictionary. If we use EditCommands and ReedlineEvents you can describe any command

we might want to take a look at rustyline's issues regarding keybinding to make sure we can support the functionality. one thing that comes to mind is attaching arbitrary internal or external commands to keybindings. like maybe ctrl-shift-h runs htop or something like that.

as I recall, we created a few issues on rustyline's repo about keybindings. of course, this type of functionality can come later but we want to be sure our deserialization handles such things up front. i.e. start with the end in mind.

It is very useful to expose Vi hard-coded keybinding to support other keyboard layout.

I like how Helix editor handles the config in nested way to represent mode. Maybe kind of abstracting major modes ("emacs", "vi insert", and "vi normal") into a single state combined with nested keybindings to support Vi actions. This way, we can put ChangeMode in ReedlineEvents and vi command into a nested one.

keybindings: {
  { name: goto_minor, modifier: null, keycode: char_t, modes: [ vi_normal ], event: { send: ChangeMode, mode: v_insert } }
  { name: goto_minor, modifier: null, keycode: char_g, modes: [ vi_normal ], subs: [
    { modifier: control, keycode: char_h, event: { edit: movetostart } }
    { modifier: null, keycode: char_h, event: { edit: movewordleft, count: numarg } }
  ] }
}

I think a helix-mode would go a long way into making the reedline experience more complete, now targeting the three major modal editors.

Helix's philosophy is a bit like this (a small excerpt from their vision page on github):

Selection -> Action, not Verb -> Object. Interaction models aren't linguistics, and "selection first" lets you see what you're doing (among other benefits).
We aren't playing code golf. It's more important for the keymap to be consistent and easy to memorize than it is to save a key stroke or two when editing.

helix also has multi-cursors but we could add it later.

Also important to note that helix is heavily inspired by kakoune, so this would be satisfying for that group of users too.