Suggestion: tab/shift-tab as ergonomic alias for alt+right/left arrow

[aral]

The select previous and next adjacent sibling key bindings are very useful for quickly navigating your code.

It feels like tab (for next adjacent sibling) and shifttab for (previous adjacent sibling) would make ergonomic and semantically intuitive aliases for alt→ and alt←.

[the-mikedavis]

This can be bound in a custom keymap:

# ~/.config/helix/config.toml
[keys.normal]
tab = "select_next_sibling"
S-tab = "select_prev_sibling"

But the sibling selection commands are already duplicated in the default keymap between A-poin and Alt + arrow keys. IMO the default keymap should be lean and if anything I think we should remove Alt + arrow keys from the keymap since the directionality can be confusing/unintuitive: #2202

[aral]

@the-mikedavis Do you know what the logic for the A-poin keymaps is? Wouldn’t it at least make sense to map them to A-hjkl since they’re the movement keys?

[the-mikedavis]

Yeah, A-poin is setup mainly to use A-p as previous and A-n as next sibling which are very unambiguous and probably easier to remember. A-o for expand_selection and A-i for shrink_selection are a little less clear but kinda mimic the jumplist.

The point in not using hjkl or arrow keys for the bindings is that using A-l/A-Right can move you down in the document if you're up high in the tree where nodes are split across lines, like in:

function_call(
  some_long_arg1,
  some_long_arg2,
  some_long_arg3
)

For example if you had some_long_arg2 selected and hit A-l or A-Right, you would most likely (depending on how the syntax tree gets parsed) end up on some_long_arg3 which is downwards in the document.

Elsewhere in the keymap, l always moves you right (window management keys for example). So it can be confusing that l may move you down in the document in some cases.

See also #2202 (comment)