Alternative "zxcv" keymap

[eugenesvk]

I'd like to share a draft of a Helix keymap ZXCV (for lack of a better name) in an attempt to fix some of the vim design issues I didn't like and also match some of the common operations of the zxcv keys that I'm used to in other apps, or more specifically:

• Fix the age-old vim design flaw that required you to shift fingers from home row for cursor movement
  hjkl → jkl;
• Differentiate between repeatable and single-press paired keybinds (left/right, back/forward, earlier/later etc.)
  • Repeatable keybinds should be on separate adjacent keys (just like ←→) instead of being on the same key with the second operation behind a Shift'ed status. This greatly simplifies going back and forth and is way more important than mnemonics¹, so:
    • q/w to move by word move_prev_word_start/move_next_word_end instead of b/e
    • z/b does undo/redo instead of u/Shiftu
    • similarly, Shift+z/b does earlier/later instead of Alt+u/Shiftu
    • Ctrl+,/. to increment/decrement instead of Ctrl+a/x
    • buffer ←→ navigation to Alt1/2 (goto_previous_buffer/goto_next_buffer)
      (using this method to navigate tabs in all other apps, and Alt is a more convenient thumb-vs-palm/pinky modifier vs. Ctrl)
    • jumplist ←→ navigation to Alt3/4 (jump_backward/jump_forward)
      (or swap this with the above, 1/2 might be more convenient, but it breaks with the convention in other apps for me)
  • Single-press keybinds can remain as is — with the opposite direction Shift'ed (e.g., open_below/open_above as you only press it once)
• Map Undo/Cut/Copy/Paste to the more usual (to some) zxcv and redo to the somewhat paired b²
• Ok to use Alt when you don't need the word-jump functions (that are useful in the Extend/Select mode), so the multi-cursor mode uses Alt+cursor:
  • Altk/l to select down/up (copy_selection_on_next_line/copy_selection_on_prev_line)
  • Altj/; to shift selection back/forward (rotate_selections_backward/rotate_selections_forward)
  • bonus: quick selection correction without releasing the modifier with Altz (backup u) (remove_primary_selection)
  • AltShift/z (backup Alti) to undo all selection (keep_primary_selection)
  • unrelated bonus: extend by word without entering the Extend/Select mode with Alt+q/w/e (extend_prev_word_start,extend_next_word_end,extend_next_word_start)
• Group various inserts together (insert_mode/prepend_to_line to i, append_mode/append_to_line to o, open_below/open_above to u /+Shift)
• Add free-standing half_page_up/half_page_down to h/n
• Add goto_line_start/goto_line_end to Shift+h/n
• Add a few keybinds to make it similar to non-modal editors to help with transition
  • Shift+/Enter Insert a new line (open_below/open_above)
  • Ctrla Select all (select_all)
  • Ctrls Save (:write)
  • Ctrlz Undo (undo)
  • Ctrly Redo (redo)
  • Ctrlo Open (file_picker)
  • Ctrlx Cut (yank_main_selection_to_clipboard, delete_selection)
  • Ctrlc Copy (yank_main_selection_to_clipboard)
  • Ctrlv Paste (paste_clipboard_after)
  • Alt/Ctrl+⌫/⌦ to delete a w/Word left/right (e.g., move_next_word_end,delete_selection)
  • CtrlPageUp/PageDown to navigate files (goto_previous_buffer/goto_next_buffer)

Below are the 3 layouts — the new ZXCV along with the current default and the proposed default refactoring ( from this comment) — pasted as images, though it might be more convenient to view them in an html format in a dedicated repo page:

• ZXCV
  @KeyboardLayoutEditor, image, config
  
• Default
  @KeyboardLayoutEditor, image; original without icons: @KeyboardLayoutEditor, image, source
  
• Refactor
  @KeyboardLayoutEditor, image; original without icons: @KeyboardLayoutEditor, image, source
  

Footnotes

1. re. mnemonics: in such a complex keybind system such as Helix's I don't find them all that useful as they don't offer intuitive predictability due to said complexity since there are several alternatives to most of the keys, e.g., should c stand for Cut/Copy/Change/Collapse/Comment/Char/Command/Case/...? ↩

2. this breaks the 'sticky' select_mode as I don't know how to pass the 'sticky' option it via config, seems to be hardcoded in keymap.rs ↩

[NNBnh]

Fantastic work! I'm so glad that there is someone out there that interesting in key binding and also have many similar thought with me.
Its seem like we are in a competition because I'm also working on a alternative keymap design for Helix call bmap-helix (KLE link) which it's in a family of keymap system name Bkey (KLE link, this define each keys with its own meaning and the goal is to be similar to the standard keymap from popular softwares and make keymap for as many programs as possible, even games) that I have been working on for 2 year.

You should definitely check out XahLee blog about keybinding design:

• Xah Fly Keys and it's fork call ErgoEmacs is a keymap design for Emacs that also use ZXCV like in your design.
• HJKL vs IJKL.

XahLee blog is a great resource. It's the one that inspire me to create Bmap and it might help you learn a lot about keyboard ergonomic too!

[eugenesvk]

Thanks!

alternative keymap design for Helix call bmap-helix (KLE link) which it's in a family of keymap system name Bkey (KLE link

The two KLE links are the same and the Bkey repo is blank, did you mean some other link?

You should definitely check out XahLee blog about keybinding design:

Read a couple of his articles (and definitely agree with his main critical vibe re. the abysmal default state of keyboard affairs), but not the more comprehensive ones with a full layout. This layout could definitely benefit more in its future iterations from departing from mnemonics even further toward more of a "frequent should be easy" principle

• given the huge frequency of the insert_mode command, it should definitely be on the home row (d?) rather than on the mnemonic insert, let the I signify a line in a geometrical mnemonic and move extend_line/extend_to_line_bounds there!
• in a similar vein, I've been thinking about mirroring ←→ word movements with a/f just like j/; is ←→ for a char movement, that would avoid some pinky moves to q
• or the 1/2 are great for when you're not typing much, so I'm using that to navigate tabs in all apps, including non-editor ones, but otherwise these are in the "pinky territory", so might be best avoided in an editor

Though I think a better solution to many of such issues with pinky-distant modifiers would be an introduction of "on hold" key modifiers on regular keys, e.g., you could hold b and press j/; to navigate buffers (and this would even work in Insert mode, though it's tricky to achieve this level of convenience without breaking regular typing flow of bj; like the currently possible in Helix a similar chord modification of "j"={k="normal_mode"} doesn't achieve that as it prevents j from being seen right away (the next key is needed), and also shows an annoying window useful only the first few times to help you remember)
(for an example of this design system-wide, check this blog out, it describes "how to make all of my QWERTY keyboard (minus some letters and delete/return keys because those are too far from the hjkl hand position) into custom hyper keys." on a Mac)

• Xah Fly Keys and it's fork call ErgoEmacs is a keymap design for Emacs that also use ZXCV like in your design.

Thanks for the tips, will need to see what they've done to try some further improvements (the ErgoEmacs would also benefit from using a keymap design more like the one above with colors coding a type and position coding modifiers 😜)

• HJKL vs IJKL.

Knew about this one, though decided that moving to i while definitely more intuitive at first is ultimately worse vs. a no-movement-required keymap, and that if you are anyway deep down the rabbit hole of complex text editors/keymaps, the longer term benefit is more important (and in general I'm a bit surprised that once the traditional h is off the table the more logical ; is not even considered in a blog post such as the one you linked)

[NNBnh]

The two KLE links are the same and the Bkey repo is blank, did you mean some other link?

My bad, here is the Bmap KLE. Yeah the repo is empty because I'm currently busy doing college stuff, I even forgot that I have rebrand the project from Bkey to Bmap... Hope that I can finish the project this month.

[pickfire]

I use dvorak and I think it's good that hjkl is not on the home row dvorak so I had to unlearn pressing hjkl and use more efficient keys like wbe instead.

[eugenesvk]

Wouldn't the proper solution to that be to promote more efficient keys to the home row instead of hoping for some random layout-dependent shift to match your efficiency preferences? (why is w and e so far apart when they do a similar job?)

[pickfire]

I think it does not matter that much since I can't think that fast compared to when I type, at least I don't think it needs to be that in home row to make it matter, unlike typing my hands can't keep up with my eyes yet.

Before going to making it home row, I rather reduce key presses first like reduce the use of shift and such.

[blaggacao]

I would add to the thought process the following:

Instead of aliasing finger positions by their key cap values on any particular reified physical layout, one could natively locate the five fingers of each hand by their ordinal positions on the x-axes of a standard coordinate system:
RH: R1 / R2 / R3 / R4 / R5
LH: L1 / L2 / L3 / L4 / L5

Then, place your fingers on a rounded surface (e.g. a basketball) in the most natural arm position and fingers in (most natural) "home row" position - they probably won't land in a row, though. That position is our base line:
RH: R10 / R20 / R30 / R40 / R50
LH: L10 / L20 / L30 / L40 / L50

Then make abductor&flexor movements with each finger that roughly step with the size of an idealized keycap.

You might find out, like I did, that depending on the finger, you only got +-1 abductor/reflexor steps up and down, while the thumb has more like +-3, and since our thumbs are opposed, that would translate in horizontal movement, not vertical. Nevertheless, we stick with e.g R11 & R1-2 for the thumb, alongsode the other fingers eg. R31 or R2-1 , etc.

If you had bathed your fingers in color, you'd now have your ideal health-preserving, ergonomic keyboard painted on that basketball.

For my hand, that renders a total of no more than 34 keys, and that includes stretching my pinky at times and diagonal-strech my pointer, while stripping one position from my thumb. But it's enough to cover the entire latin alphabet + commodities (space, esc, etc.).

Now, from there, without the mental bias of any mnemonics, it is clear that everything that is concerned with movement must lay on the home row:

• left-right-up-down
• home-end-pgup-pgdown
• and all derivatives thereof, including selections.

Fortunately, positions RL21 RL31 RL41 are almost as comfortable as the home row with only a very slight ergonomic penalty. But how many Mod keys do we usually have? 3, exactly!

So we can symmetrically organize these mod-keys on these positions for R&L in such a way that each home row hand's direction key has a superposition of 3!+2 combination. Important detail: as trigger keys that only fire special meaning after XYZ ms, I think it's ~200ms on my keyboard (?). That, however, is largely enough to cover all the direction derivatives there are, including (most) selections.

The trick is to use CSIu encoding to expand on the constraints of legacy to really get the full 3!+2 (=8) instead of only roughly 4 total combinations. (cTRL+O & related problems)

Now we have 34-10 keys left to encode all the other commands with a power of 3!+2 on each key. Let's say we take out 2 less ergonomic positions (streched pinky & diagonal digit in my case), and we reserve the thumb positions for shifting keyboard layouts (e.g. numbers & punctuation layouts) we still get 3!+2x19 = 152 positions of highly ergonomic estate for all the other commands.

In my opinion, this method, completely unbias by mnemonic legacy, is the best, most ergonomic, and hence most health-preserving method of thinking about keyboard layouts.

If the luxury of a basketballshaped keyboard, ideally sliced at the symmetry point to be mounted on your chair's armrests, is not upon you, the next best thing really is to try to fit your body's ergonomics somewhat similar onto a regular keyboard. No mnemonics incolved.

[eugenesvk]

Thanks for an interesting perspective

34 keys .. it's enough to cover the entire latin alphabet + commodities (space, esc, etc.).

Or you could just fit one extra space in a non-Latin alphabet :)

Now, from there, without the mental bias of any mnemonics, it is clear that everything that is concerned with movement must lay on the home row:

That matches my intuition and I thought about moving the word-based movements to the left "cursor" row of asdf (at least to the ←→ part of a/f similar to the right "cursor" row of jkl;) or use that for selection, though not sure it's really the best way, wouldn't the non-mnemonic thing also depend on the frequency of using those and other commands rather than on a simple functional consistency move => @home row?

But how many Mod keys do we usually have? 3, exactly!

Usually 4 (⇧^⊞⌥), though in an ideal design you'd be able to use any key as an on-hold modifier since hold-to-repeat isn't that useful, and that power blows the 3 mods out of the water and allows you to fit anything you want in a more convenient fashion

Important detail: as trigger keys that only fire special meaning after XYZ ms, I think it's ~200ms on my keyboard (?).

Yeah, this is in general a rather useful ability to be able to differentiate between short press/long press/hold, though not without its own challenges in setting up (e.g. the delay might depend on the finger)

In my opinion, this method, completely unbias by mnemonic legacy, is the best, most ergonomic, and hence most health-preserving method of thinking about keyboard layouts.

Do you have a keymap picture and a helix config modeled after that unbiased greatness?

[blaggacao]

simple functional consistency move => @home row?

good point, I'm kind of still training myself, but for example in my tiling window manager I use the left hand directionals for all kinds of windows movement. After all, it's probably better to have that estate & the symmetry (!) and avoid one or the other mod chording if possible. At least in principle, for the editor I use that estate quite differently, since the RHS directionals in 3!+2 hold enough estate for all movement needs. Note, that within editor, switching to navigation keyboard layer is thankfully optional (see also keymap below).

though not without its own challenges in setting up (e.g. the delay might depend on the finger)

I can report, that it was really annoying at first, but my brain did adapt within a month or so and learned to unconsciously use the right delay. It's amazing.

Do you have a keymap picture and a helix config modeled after that unbiased greatness?

I ended up just rebuilding with: blaggacao@2089b29 but it's still a bit incomplete and I currently still use my hard earned kakoune spaghetti-mapping (in kakoune)

I use this keyboard layout (WORKMAN): http://www.keyboard-layout-editor.com/#/gists/98d6ae294c3b51ac434747ce87788b0f

• Holding either bksp or del gets me into the "navigation layer" (on home row)
  • Holding one down and than the other does repeated actuation of the other (del/bksp)
• Holding either of esc, tab, space, enter gets me into the punctuation layer
  • just noticed, I still miss the above escape hatch for these 😄
• Holding any 2 of esc,tab,space,enter gets me into the number layer. (it's handy since one thumb can actuate both keys at once comfortably - inspired by stenotype machines)
• The green line on all layers are magic mod keys, the pinky and ring can both actuate Shift. Pinky for legacy reasons (and since I had the estate and also to make some wiered combos more ergonomic when unergonomically skewing the digit is involved at RL2+1-1)
• I use the windows key (RL2+1-1 = digits-up-left/right) for tiling manager stuff only (hence my analysis only contemplated 3 mods above).

[blaggacao]

Usually 4 (⇧^⊞⌥), though in an ideal design you'd be able to use any key as an on-hold modifier since hold-to-repeat isn't that useful, and that power blows the 3 mods out of the water and allows you to fit anything you want in a more convenient fashion

An afterthought on this one, althought that aftherthought might also be path-dependent reasoning:
In my layout, I would want to voluntarily give up some of that power, for consistency, so that on every layer, I've got a supraluminecent mod setup that "shines" throught all layers. At least at the navigation layer, I want to preserve repeatability. But that's just a minor concern and shows that consistency considerations probably are the only valid design constraints, second to ergonomics. (ergonomics-informed consisency, that is — not: mnemonics-informed consistency 😄 )

PS: I might believe symmetry is good for your brain? -- But I might be ill-informed.

[eugenesvk]

FYI posted the better frequency-based layout here #6665
(forgot to post it in due time, so using the update to the latest 23.03 helix version to do so)