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

Feature Vision Discussion: Keybindings #69

Open
5 of 9 tasks
sholderbach opened this issue Jun 18, 2021 · 9 comments
Open
5 of 9 tasks

Feature Vision Discussion: Keybindings #69

sholderbach opened this issue Jun 18, 2021 · 9 comments
Labels
A-KeybindingEmacs Area: Handling of default (Emacs style) keybindings A-ViKeybinding Area: Vi(m) keybinding support

Comments

@sholderbach
Copy link
Member

sholderbach commented Jun 18, 2021

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)
@sholderbach sholderbach added this to the Vision to Roadmap milestone Jun 18, 2021
@fdncred
Copy link
Collaborator

fdncred commented Jun 20, 2021

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)

@nicoburns
Copy link

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

@nothingnesses
Copy link

nothingnesses commented Jul 15, 2021

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.

@sholderbach sholderbach added A-Multiline Area: Support for multiline editing (Validation and interaction with `A-Display`) A-KeybindingEmacs Area: Handling of default (Emacs style) keybindings A-ViKeybinding Area: Vi(m) keybinding support and removed A-Multiline Area: Support for multiline editing (Validation and interaction with `A-Display`) labels Nov 28, 2021
@elferherrera
Copy link
Contributor

what syntax should this keybinding file should have?

@fdncred
Copy link
Collaborator

fdncred commented Dec 26, 2021

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?

@elferherrera
Copy link
Contributor

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

@fdncred
Copy link
Collaborator

fdncred commented Dec 27, 2021

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.

@Abdillah
Copy link
Contributor

Abdillah commented Jul 20, 2023

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 } }
  ] }
}

@luccahuguet
Copy link

luccahuguet commented Sep 26, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-KeybindingEmacs Area: Handling of default (Emacs style) keybindings A-ViKeybinding Area: Vi(m) keybinding support
Projects
None yet
Development

No branches or pull requests

7 participants