Keymap consistency (semantics and ergonomics)

[aral]

Hey folks, loving Helix so far but I do have a couple of pain points regarding inconsistency in some of the key bindings.

As I see it, keybindings should, whenever possible (in roughly decreasing order of importance):

1. Build upon previous knowledge: If you know that h is left, then alth should be something related to the concept of “left” or (at least in Western culture), “before” / “previous”.

2. Be ergonomic: commonly used actions should be close to one another and not require large or uncomfortable movements of the fingers.

3. Have spatial semantics: If the action of a command is to increase something at its located above the key to decreate something, this leads to intuitive spatial semantics. Now keyboard layouts are different, of course, but if there is a general layout that’s being taken as a baseline, it would make sense to try and maintain spatial semantics whenever possible.

I know that a lot of the bindings do exhibit the sorts of consistency I outlined here but not all do. I feel it might benefit the tool we all love to perhaps document any inconsistencies or ideas for first-principles-based improvement here (instead of opening separate issues for them).

I’ll start with some that I’ve been thinking of:

Window splitting

The binding to split vertically is spacewv. Which makes perfect sense. So my intuition would be that to split horizontally is spacewh but it’s spacews.

Now I know that h has the meaning of “left” in the normal mode but since this is a sub-mode I feel internal consistency and “guessability” is more important.

Movement between siblings

Currently the bindings are alt + p/o/i/n. Since the alternate bindings are the arrow keys, I wonder if it wouldn’t make more sense to bind them to the home-row equivalents of the arrow keys: alt + h/j/k/l.

Personally, I feel tab and shifttab would make good semantic aliases for the next/previous adjacent sibling navigation bindings. (It looks like tab is already being used for Jump forward on jumplist.)

Issue: #2561

Auto-complete inconsistency

To add the first item in the auto-complete menu, you press tab.

To add any other item in the menu, have to use the down arrow key at least once, after which you can use tab also to navigate between the options and press enter.

However, if you press enter on the first item shown (without making a selection), you create a newline.

Issue + backstory about why this is currently implemented in this way: #2549

Jump forward/backward on jump list

Jump forward on jump list is tab. Why is jump backward not shifttab (which would be intuitive and consistent with the use of shift elsewhere, eg., n vs N) but ctrlo?

Thoughts? Suggestions? Do you have any others you can think of?

[archseer]

Now I know that h has the meaning of “left” in the normal mode but since this is a sub-mode I feel internal consistency and “guessability” is more important.

I think we left hjkl free so that these can be used to move between panes in that direction, similar to C-w hjkl in vim.

Currently the bindings are alt + p/o/i/n. Since the alternate bindings are the arrow keys, I wonder if it wouldn’t make more sense to bind them to the home-row equivalents of the arrow keys: alt + h/j/k/l.

This was actually the case, but it was changed because those bindings were confusing, see #2202 and #2205

To add any other item in the menu, have to use the down arrow key at least once, after which you can use tab also to navigate between the options and press enter.

Hmm it should be possible to just tab through the options then press enter to select your preferred option?

Jump forward on jump list is tab

I think this is incidental, tab and Ctrl-i probably share the same terminal keycode, which is why tab has this behaviour too? The mappings we create are Ctrl-i and Ctrl-o (mnemonic is "in" and "out")

[aral]

Jump list

I’ve settled on using the following custom configuration for the jump list:

• ': (single quotation mark) save current selection to jump list (“mark my position”)
• tab: jump forward in jump list
• shifttab: jump backward in jump list

That also freed me to remap ctrls to Save.

(I also added ctrlq as Quit.)

In ~/.config/helix/config.toml:

[keys.normal]
C-s = ":write"
C-q = ":quit"
"'" = "save_selection"
S-tab = "jump_backward"

[adsick]

I want some of the keymaps being consistent between normal and insert mode.
E.g. I want C-s to be write in both normal and insert mode, but for some reason I can't get it to work in insert mode(

my config:

theme = "monokai_pro_spectrum"

[keys.normal]
C-s = ":w"
C-S-s = ":wa"
C-A-s = ":wqa"

C-z = "undo"
C-S-z = "redo"

"S-esc" = ":wqa" #doesn't work
D = ["extend_line", "delete_selection_noyank"]
"C-/" = ["toggle_comments"] #does nothing

H = "goto_previous_buffer"
L = "goto_next_buffer"

[keys.insert]
C-s = ["normal_mode", ":w", "insert_mode"] # doesn't work
C-c = "toggle_comments"
"C-space" = "completion" # way of completion I used to

"C-z" = "undo"
"C-S-z" = "redo"

[editor.file-picker]
hidden = false
max-depth = 4

[editor.lsp]
display-messages = true

[editor.cursor-shape]
insert = "bar"
select = "underline"

[aral]

I recently realised this after thinking I was going mad (I’m so sure I hit C-s!) So, yes, N enthusiastic +1 from me :)

[trojkat]

Sorry for jumping on the topic so late but if Helix wants to be a post-modern editor then maybe it's time to move from h j k l to j k l ; as there is no point in keeping the current non-ergonomic approach just because in 1976 there was a computer with such a keyboard that had arrow keys there.

[adsick]

You are god damn right

[russell-holgate]

Regarding pane/window splitting, why limit it to vertical or horizontal? The direction paradigm can be kept with space + W + h/j/k/l which would place the pane in the same place space + w + h/j/k/l is needed to navigate to.

Here's a mapping to try it out. I think it feels quite natural and intuitive:

[keys.normal.space.W]
h = ["vsplit", "swap_view_left"]
j = "hsplit"
k = ["hsplit", "swap_view_up"]
l = "vsplit"