Flexible keymap (hotkeys / shortcut)

[iamstarkov]

the important key to achieve it in flexible and reliable way is to have two things:

• list of possible events to rpc.emit ¹
• one place to bind keys to those events

¹ Note: rpc bus should be the only way to broadcast key events).

Initial array of events can be collected from lib/index.js#L38-L129: like split request vertical or split request horizontal, etc.

Then in config we can do smth like this:

keymap: {
 "CmdOrCtrl+Alt+Left": "prev pane req",
}

where keys are electron accelerators and values are those events for rpc to emit/receive.

After that, we need to modify attachKeyListeners() lib/containers/hyper.js#L38-L76 to not bind hardcoded keys, but instead to pick up keys and events from keymap:

// mousetrapify needs to be more advanced, for sure, but this is enough for now
const mousetrapify = key => key.replace('CmdOrCtrl', 'mod').toLowerCase();
Object.keys(this.config.keymap).map(item => {
  const accelerator = item;
  const event = this.config.keys[key];
  keys.bind(
    mousetrapify(accelerator),
    () => {
      if (focusedWindow) {
          focusedWindow.rpc.emit(event);
      }
    }
 );
})

Also, Hyper needs to verify that this.config is merged object similar toObject.assign({}, defaultConfig, ...[pluginsAndThemesConfigs], userConfig)

Thats it.

---

One interesting benefit of proposed approach is that you can update menu accelerators very easy and smooth. just needs to write a function which will lookup desired accelerator by key event relevant to that menu item. ², ³

• ² because right now keeping hotkeys in a menu relevant is a fragile mess
• ³ findAccelerator is pretty simple function:

const findAccelerator = event => Object.keys(this.config)
  .map(key => { key, value: this.config[key] })
  .find({ value } => value === event)
  .key

Result

• widely commons keymap sets can be distributed via plugins
• always relevant hotkeys in menu to briefly lookup forgotten keybindings
• with list of events and keymap to them it will be possible to "view all keyboard shortcuts" (fix Add ability to view all keyboard shortcuts #814)
• user gets fully customizable key bindings 🎉 (fix Keyboard shortcut manager plugin #251 and make keyboard shortcuts configurable #657)

what do you think?

[iamstarkov]

i want to discuss this approach before i will start implementation, so any feedback is welcomed: ideas, questions, concerns, problems, etc

[iamstarkov]

@leo @codetheory @ekmartin @rauchg what do you think?

[ekmartin]

I'm not sure if it's a good idea to bind keybindings to rpc directly. Far from all combinations have an rpc event connected to them at the moment, so not sure if that's a good direction to go.

Why not have a separate keymap file that maps a string key to a combination? I.e. 'split-vertical': 'Cmd+D'. That way the keymap config could be used both in the menu decorator and in the hyper container.
We could then expose the keymap to plugins in the same way we do with a regular config.

Example would be: keys.bind(keyMap['move-right'], moveRight).

[iamstarkov]

I'm not sure if it's a good idea to bind keybindings to rpc directly.

maybe its not a good idea, but rpc as a central piece of code for key bindings — is the best point i could think of. To be honest, in the end it can be not a rpc, but any central broadcast communication api. It just happens, that rpc is what we have now.

---

Far from all combinations have an rpc event connected to them at the moment, so not sure if that's a good direction to go.

We can add them later, once proposed changes will be in place, it should be easy.

---

Why not have a separate keymap file that maps a string key to a combination?

main reason against two files over one, is simplicity: harder to show/sync your settings with two configuration files You may think that configuration file with a whole keymap will be too hard to read, though to cure this problem we need to think careful about sane default keymap.

---

I.e. 'split-vertical': 'Cmd+D'. That way the keymap config could be used both in the menu decorator and in the hyper container.

Exactly! I'm all for that as i mentioned in proposal.

Need to note, that keybinding: rpcEvent have to be reversed, because relation is not one keybinding to multiply rpcEvents, but quite opposite — one rpcEvent to many keybindings. And hey, its how its done in Atom, which i cant blame for blame for bad keymap decisions.

---

We could then expose the keymap to plugins in the same way we do with a regular config.

Yep!

---

Example would be: keys.bind(keyMap['move-right'], moveRight).

Kinda, as far as pairs are revered you have to do smth like this:

Object.keys(this.config.keymap).map(accelerator => {
  const event = this.config.keys[key];
  keys.bind(
    mousetrapify(accelerator),
    () => { rpc.emit(event); } // kinda
 );
})

[iamstarkov]

tldr:

• one file is simpler than two
• for this feature to work we need broadcast mechanism, lets start with rpc for now
• pair should be keybinding: event

[jwhitley]

I'll argue for an approach to keybindings that guarantees sensible rebinding and/or unbinding. A concrete example:

When using iTerm2, I rebind the ⌘1 through ⌘9 keys globally (across all profiles). Instead of their normal function of switching the first nine iTerm2 tabs, they instead are bound to emit <prefix>-<num> which switches between tmux windows. I.e. I use tmux so heavily that I prefer the normal Command bindings to treat tmux windows like tabs.

Another frustration of some keybinding systems (vim, I'm lookin' at you) is that not all bindings are first-class and/or introspectable. I.e. there's no command or API that can ask such questions as:

1. What are all the currently active keybindings?
2. What key(s) are bound to operation <foo>?
3. What operation(s) are bound to key-sequence <bar>?
4. (Bonus points) Where did a given binding come from? (e.g. user config, plugin baz, etc.)

These operations aid both config debugging and discoverability.

[iamstarkov]

@jwhitley After and if proposed change will land in master. All keybindings will be declared in one keymap object, and it will be possible to redefine them in your config.keymap

[iamstarkov]

bad news everyone, Hyper has two rpc, one for Electron and one for Renderer processes, and you cant share them. problem here is that key bindings in ./lib/containers/hyper.js can be used to emit event only to to Renderer's rpc, while actual rpc responsible for hotkeys is Electron's one

[iamstarkov]

on the other note, there is another way

[iamstarkov]

This PR #925 is another approach, i was talking about

[iamstarkov]

@rauchg can i ask you to move labels from #925 PR into this original issue? Priority: High, Status: Community feedback wanted, Status: In Progress. And pls share your thoughts about last one

[ppot]

@iamstarkov I switched the label

[ppot]

Plz add request inside issue: ppot#11

[andrroy]

Referring to the label "In progress", is this issue actively being worked on? All i could find was @iamstarkov closed PR.

[iamstarkov]

@andrroy look at ppot#11

[iamstarkov]

and yes it is in progress

[iamstarkov]

here #1509

[ppot]

close in #1876