Keymap discussion

[pickfire]

Since we take some keys from both vim and kakoune, we want to reduce the issues of taking the worse of both worse.

Currently I dumped some idea in https://github.com/helix-editor/helix/wiki/Keymap-brainstorm and will continue to update that for some time, putting in some painful edit operations in vim or kakoune or both. Then we may want to try addressing them in helix by picking the best of both worlds.

Maybe our next step is to move towards implementing some of the missing keys and re-iterate and see if we have any painful points while working with helix.

[rieger-jared]

I've been using helix for a day now, and I'm finding some bindings or lack of bindings a bit frustrating. I guess what I think would be valuable to know is if this project is aiming to augment the vim mappings or is planning to write its own set of mappings. Furthermore, I think that this quite important for the adoption of the project that the key mapping interface is clear whether it's copying the vim interface or making its own as vim mappings for vim users are second nature to most.

I personally would hope that the project adopts the majority of the basic vim interface. I also understand that the project also has the potential to change some features where it's desirable for UX. By that I am referring to the multi cursor support.

However, perhaps we could also implement options for users? For example, Emacs users could set a configuration setting to select an Emacs key mapping. Likewise for vim. I would imagine that would be quite time-consuming to implement.

Does Helix want to be a post-modern vim? Or its own editor like atom or VS Code with its own key bindings? I personally believe building on top of vim is the better option as it would maintain portability in the keybinding interface for users.

[archseer]

We're basing the keymappings quite heavily on Kakoune, so you might find this helpful: https://github.com/mawww/kakoune/wiki/Migrating-from-Vim

The idea is that you always start by making a selection first (that way it's interactive and you see that you selected the right thing), then you operate on it.

We're currently diverging from kakoune by introducing a selection mode (I've also called it the "extend mode") which is similar to vim's visual mode: In this mode movements extend the selection instead of moving it. So wWW in Kakoune is vwww in Helix. This means that "reverse" bindings (eg. F instead of f in vim) can now live on shift again, instead of alt.

We're copying kakoune's goto mode (It's a lot easier to memorize gt than H) and moving the view mode under z (similar to vim) to make space for v. This will also help with discoverability by introducing kakoune's auto-info popups (e.g. g would show a menu).

Are there any specific keymaps you're missing?

[bczsalba]

I heavily rely on the ci and vi bindings from vim, but if I'm reading you correctly they go against the "always start by making a selection first" policy. Are there any good alternatives to them in helix?

[archseer]

Yeah so the equivalent of vim's textobjects would be an object selection mode. Something like si{d for "select inside { delete", but with a different key than s since we're using it for other things.

This still needs to be implemented but it's important so I'd like to focus on it soon.

We're also looking at structural matching via tree-sitter so that you'd be able to select / move entire functions, etc. In the same vein as https://github.com/nvim-treesitter/nvim-treesitter-textobjects and similar libraries.

[pickfire]

@rieger-jared Maybe you should try out kakoune first to understand some of the concepts helix is based on.

Helix currently is in a very weird keybinding state I would say, some is there some is not there, which I start writing and updating the wiki for stuff I find difficult.

One issue I see helix have is we don't have the <operation> <movement> method like in vim but at the same time we only partially taken kakoune <movement> <operation> so in certain situations may be more troublesome to type it out.

[CBenoit]

Quick opinion on x/X. On kakoune the behavior is a bit weird (https://github.com/mawww/kakoune/issues/2590). I think we could just remove it because it's superseded by the "extend mode". V being the line-wise extend mode, pressing it would be roughly equivalent to pressing x selection-wise (in current helix and kakoune if line is not empty). To delete a line: Vd instead of xd. I think the kakoune x exists because of lack of post-movement (dd) combined to lack of extend mode.

And we get x for text object selection mode: xi{d.

[ashkitten]

discussed on matrix (edited slightly to depend less on context):

here's an interesting edge case i encounter in kakoune a lot: say you have a word, and you want to select to the end of the word and extend that backwards to the beginning of the line. you intuitively want to do evgi, right? but that doesn't work because when you use e the anchor of the selection is at the beginning of the word, and vgi doesn't modify the anchor... you end up selecting from the first character of the word to the beginning of the line, so instead you have to do e;vgi. i find myself using ; in a lot of places i feel are unintuitive with kakoune because of the anchor position. i feel like there has to be a better way than to treat ; as an escape hatch for unintuitive behavior... (and of course the same movement works fine in vim, with ev0... it's only because of normal-mode e selecting the word that this is a problem) hmm, i wonder if we could treat e, b, w, etc. as "temporary" selections that don't actually affect a visual selection? so if you do evgi the anchor gets reset when you enter visual mode but ed still works that's essentially how they already work, since ee overwrites the first e selection without extending it it would make vwwd different than wvwd but i think that's probably okay i'm trying to think if it would be valuable to treat movement selections as a special-cased temporary type of selection, or if v should just reset the anchor... i think it becomes more important when you get into multiple selections, and i'm not sure what the right answer is

[pickfire]

I think we could just remove it because it's superseded by the "extend mode".

No, we can't really do that. x/X is one of the most used keys. Try check the wiki on the examples, I think most of them I put need to use x, if we removed that try and see if it could be replaced by V, I think most of the case we can't. Usually X is used on extend, we can't do V since we are already in visual mode, if we remove X, we need to do jgl to extend a full line.

[CBenoit]

I think we could just remove it because it's superseded by the "extend mode".

No, we can't really do that. x/X is one of the most used keys. Try check the wiki on the examples, I think most of them I put need to use x, if we removed that try and see if it could be replaced by V, I think most of the case we can't. Usually X is used on extend, we can't do V since we are already in visual mode, if we remove X, we need to do jgl to extend a full line.

In line-wise extend mode you should not use gl and gh stuff. You don't need to extend a full line, since you're always on a full line (same as vim's V). I updated the wiki examples with what I think V should be.

[ashkitten]

i'd like to add that in my week or so using kakoune i've definitely missed <c-v> in a lot of places (like commenting out a block of code, for instance... though i know :comment-line exists). i think helix would do well to have a real rectangle selection mode and not depend solely on multiple cursors like kakoune

[DrZingo]

I would like to see a plan for keybindings. To change editor is a big time investment, and adopters need to see if it is worth it in the end.

[cessen]

@DrZingo

I would like to see a plan for keybindings. To change editor is a big time investment, and adopters need to see if it is worth it in the end.

Can you expand on your concerns about the keymap in more detail? You had a lot to say in the matrix chat, and I think it would be good to capture those specific concerns here.

[DrZingo]

@DrZingo

I would like to see a plan for keybindings. To change editor is a big time investment, and adopters need to see if it is worth it in the end.

Can you expand on your concerns about the keymap in more detail? You had a lot to say in the matrix chat, and I think it would be good to capture those specific concerns here.

It all boils down to: I (and other adopters) want to know how all extra object bindings will end up without involving non intuitive non mnemonic characters and or alt/ctrl. If early adopters end up with bad bindings along the road, time and effort will be a bit wasted. There are already binding clashes according to the keymap docs, and feature wise an estimate of 10-20% is implemented fully or to some degree. Together with "We don't want alt/ctrl", "I think we will...", is not reassuring that the object->verb is the way to go. Especially as some verbs anyway will end up as first (Add, add, Insert, insert, paste, Paste etc.)

[CBenoit]

If it's alright for you, I would really appreciate if you could provide additional samples and use cases on the wiki page. Especially, as you appears to be advocating for vim keybindings, I'm interested in samples where you think kakoune performs badly and VIM is good.

[pickfire]

I have an idea. What if we can make use of 0 and 1 as inner and outer like kakoune alt-i and alt-a, since currently the count 0 and 1 will be useless anyway, but to do this we need to know if user pressed any number and if the number is 0 or 1 then we do stuff differently. Example, 0w select inner word. The downside is it's a bit further. The upside is it is just a single key and we repurpose the count to do it, we then get a lower key count compared to vim and kakoune for this frequent key (and don't need to hold any key). What do you all think? thums up or down?

[sudormrfbin]

That's a very clever way to do it; the main issue I see with it is that they are harder to reach and selecting inside and around are very common operations.

[CBenoit]

While not a bad alternative, I'm not very happy with 0 ad 1. Several reasons :

• as mentioned, harder to reach
• on french layouts (azerty, bépo), shift is used to type numbers
• when pressing 0 if no other number has been entered before, we know for sure this is text object inner selection mode. However, 1 could be either the beginning of a bigger number (e.g.: 10) or the text object outer selection mode. This is not cool if we intend to show help windows like in kakoune because we can't be sure whether help should be displayed or not
• no mnemonic for it

I may repeat myself, but I would map x to inner (text object) and X to outer (text object "more") assuming V is line-wise extend mode and we don't need current x/X anymore.

[DrZingo]

These are quite similar in action, how about have them on the same keybinding, as they are in different modes. If they are frequently used - on m - otherwise something less short. (I don't use matching bracket particularly often myself, and flip selection I don't know yet).

m | Jump to matching bracket Alt-; | Flip selection cursor and anchor

[CBenoit]

Alternatives to my text object inner x and text object outer X mapping suggestion from matrix:

@teenjuna

Why not si/sa for select inner / select around? As I understand, it will be used from normal mode, so s.. is free. Correct me if I'm wrong. I can see how [current] s may be replaced with ss for select inside selections

@CBenoit

xi / xa for text object inner and text object around would be fine as well

[pickfire]

I just realized that helix is hard to change till end of line. C or c$ in vim and alt-lc or Glc in kakoune but in helix we need to vglhc. I wish gl can exclude the newline so we can just Glc in helix.

[DrZingo]

It may be of interest to take a look at different keyboard layouts before deciding on a particular key. As an example the ; key is located to the left of 1 on some layouts, and is shifted on many European and Spanish-writing languages. This results in Alt-Shift-; for these. Maybe a peek at this page before can justify/stop a choice of key: https://keyshorts.com/blogs/blog/44712961-how-to-identify-laptop-keyboard-localization

[valpackett]

As someone who switched from vim to kakoune, my config includes a "vim habits" section that includes: $ to go to end of line, 0 to go to beginning of line, ^ to go to non-whitespace beginning of the line, and most importantly bare { } for paragraph navigation.

One pain point in kakoune is that binding 0 like that means you can't even enter e.g. a 10 prefix anymore, as that zero would trigger the binding. There are workarounds for this, but this really shouldn't require workarounds. Hopefully helix can avoid this problem.

[pickfire]

One pain point in kakoune is that binding 0 like that means you can't even enter e.g. a 10 prefix anymore, as that zero would trigger the binding. There are workarounds for this, but this really shouldn't require workarounds. Hopefully helix can avoid this problem.

I think plugin should have the ability to fix this if the keymap and commands is part of the plugin. I just add a tag for plugin because I think it is slightly related to plugin.

[python128]

I think keeping the visual mode is good. We can change our helix configuration if we would like Kakoune-like config. Also, I think x is a good start for line selection. Though, if you want, you can change x to object selection, and X to line selection. Or, we can just add whatever config we would like to our config.toml file.

[mankinskin]

Would be cool if we could have some kind of community vote about which keymap to use and how commands should behave. Would also be nice to be able to remap keys completely. So I guess the question is more about how which commands should behave and then which keys should trigger them by default.

[cessen]

Would be cool if we could have some kind of community vote about which keymap to use and how commands should behave.

Voting works well for a lot of things, but I don't think design is one of them. I'd rather defer to @archseer for the final keymap design. Discussion and ideas, as well as prototype keymaps to play with those ideas, are absolutely valuable. And I myself hope to participate in that once keymaps are more fully customizable. But ultimately I think we'll get a better editor if there's a single person with a coherent vision deciding how and what to integrate together in the end.

That doesn't mean that everyone should be stuck using that default keymap, of course. One of my own hopes/goals is for Helix to be super customizable (custom keymaps, custom modes, etc.) so that people can always choose to create their own setup if they prefer.

[mankinskin]

@cessen People could be voting on coherent design options. I just noticed while reading this conversation that it is very hard to collect all of the current suggestions and how popular they are. I also don't mean to say that these votes should have the final say, but it would be useful to know which designs are most requested.

But I can see how that might not produce the best results, because some people might not have thought about their vision extensively.

[pickfire]

@mankinskin I think if we want some ideas to be implemented, can just send a pull request to discuss or can discuss the keys here before sending the pull request. We could do vote but I don't think vote is gonna suffice, vote would be a good idea on how useful one feature is but that might hinder changes, otherwise kakoune and helix wouldn't be the way it is today. So I think better let @archseer decide even after a vote.

[cessen]

@mankinskin

I also don't mean to say that these votes should have the final say, but it would be useful to know which designs are most requested.

Ah, got it. Yeah, that seems fine then. Just another form of feedback, then, basically.

[yerlaser]

v-mode can actually be useful. However, currently, it persists after yanking. This is counter-intuitive. I would expect it to reset to normal mode after yanking.

[yerlaser]

Just as @CBenoit suggested, I would suggest to reconsider to have V to be "extend_to_line_bounds" I know, I can now do it in custom mappings. But, why make it unnecessarily more difficult for people migrating from VIM (or in my case, people who occasionally need to use VIM)?

[pickfire]

v-mode can actually be useful. However, currently, it persists after yanking. This is counter-intuitive. I would expect it to reset to normal mode after yanking.

I don't see why we need to keep extend on after yanking, maybe you can send a pull request to stop extend after yanking (but keep the selection).

[cessen]

maybe you can send a pull request to stop extend after yanking (but keep the selection).

Personally, I would rather deal with this stuff on the keymap level rather than the command level. In this case, if we add support for sequences of commands per hotkey, then the hotkey can be assigned the command sequence [yank, enter_normal_mode].

That way the core commands themselves can stay clean, each doing just one thing, and more complex behaviors with cross-cutting concerns can be built in the keymap.

[pickfire]

Personally, I would rather deal with this stuff on the keymap level rather than the command level. In this case, if we add support for sequences of commands per hotkey, then the hotkey can be assigned the command sequence [yank, enter_normal_mode].

I don't agree with that. We shouldn't complicate the command level just for this case. I rather we tune the command or have a new command that merges both yank and enter_command_mode to keep things simpler.

[mankinskin]

Is there some documentation on the command model? It sounds pretty cool to be able to build your own commands from command sequences like [yank, enter_command_mode].

[CBenoit]

Personally, I would rather deal with this stuff on the keymap level rather than the command level. In this case, if we add support for sequences of commands per hotkey, then the hotkey can be assigned the command sequence [yank, enter_normal_mode].

I don't agree with that. We shouldn't complicate the command level just for this case. I rather we tune the command or have a new command that merges both yank and enter_command_mode to keep things simpler.

Actually, that’s likely how it will work with user config done using the plugins system anyway. Just create a new function calling the two others commands, and then map the function to a key.

[cessen]

Actually, that’s likely how it will work with user config done using the plugins system anyway.

Yeah, the more I think about it, the more I like the idea of aiming for commands to be maximally composable rather than maximally individually powerful. That makes things a lot more flexible for customization.

There are plenty of other commands that I'd personally prefer to work differently, but because they compose well I can get the behavior I want by chaining commands together, and I think that's a good place to be. Just need to support command sequences in the keymap. :-)

@pickfire

We shouldn't complicate the command level just for this case. I rather we tune the command or have a new command that merges both yank and enter_command_mode to keep things simpler.

Thinking about it more, I'm not opposed to that at all. I just want to make sure we also keep the more composable versions so that custom behaviors are easy for people (like myself) to build in their configs.

[pickfire]

Thinking about it more, I'm not opposed to that at all. I just want to make sure we also keep the more composable versions so that custom behaviors are easy for people (like myself) to build in their configs.

Yes, so in the meantime I think we can just create a new command that uses both join and enter_command_mode so user can easily swap one out.

Creating new functions do make it composable already. I think rather than doing a sequence an easier way is just let users have new functions which does a sequence of stuff. In case some functions requires some logic then it won't work with the sequence way, creating new functions can be way more flexible.

There are plenty of other commands that I'd personally prefer to work differently, but because they compose well I can get the behavior I want by chaining commands together, and I think that's a good place to be. Just need to support command sequences in the keymap. :-)

If we do that then later I wouldn't be surprised to see someone requesting for [filter_a, filter_b, filter_c, function_a, filter_d, loop, filter_e, action_a, end_loop] and it will be messy. Then heh, helix lang. :P

[cessen]

I think rather than doing a sequence an easier way is just let users have new functions which does a sequence of stuff.

You mean via the plugin system? I don't think that's easier from the user's perspective--quite the opposite. You need to learn the APIs, compile to wasm, etc. I think the plugin system will be great for things that involve conditional logic or more sophisticated functionality. Or in other words, when you're actually building new functionality for Helix.

But for just binding macros to hotkeys?

Then heh, helix lang. :P

Is that your main concern, that it's a slippery slope to a crappy Helix lang?

I mean, I definitely agree that I don't want it to turn into any kind of programming/scripting language. I guess I'm just not concerned about that happening. If people started suggesting adding if statements, loops, etc. I would be against that as well. That's what the plugin system is for.

[blaggacao]

Side stepping a bit the main thread of the discussion, I want to suggest the following read: https://discuss.kakoune.com/t/key-maps-as-key-locations/1414 (disclaimer: I'm the author)

TL; DR;

• Suggesting an alternative locate mechanism
• Define key coordinates relative to each finger's rest position on the home row
• Enable "define by muscle memory" rather than "define by mnemonics"
• Represent keys internally by the keyboard's keycodes (invariants across language setting)

keycode 47 for spanish (ñ) & english (;)

KeyPress event, serial 38, synthetic NO, window 0x400001,
    root 0x39f, subw 0x0, time 3176346, (90,570), root:(1372,1697),
    state 0x0, keycode 47 (keysym 0x3b, semicolon), same_screen YES,
    XLookupString gives 1 bytes: (3b) ";"
    XmbLookupString gives 1 bytes: (3b) ";"
    XFilterEvent returns: False
KeyPress event, serial 38, synthetic NO, window 0x400001,
    root 0x39f, subw 0x0, time 3180682, (90,570), root:(1372,1697),
    state 0x2000, keycode 47 (keysym 0xf1, ntilde), same_screen YES,
    XLookupString gives 2 bytes: (c3 b1) "ñ"
    XmbLookupString gives 2 bytes: (c3 b1) "ñ"
    XFilterEvent returns: False

→ Yeay! keycode 47 is invariant between switching the keyboard layout from spanish to english

Form what I can see that would translate to something like:

# At most one section each of 'keys.normal', 'keys.insert' and 'keys.select'
[keys.normal]
38 = "move_char_left" # Maps the 'a' key to the move_char_left command
25 = "move_line_up" # Maps the 'w' key move_line_up
C-S-9 = "extend_line" # Maps Control-Shift-Escape to extend_line
# or this ?:
37-50-9 = ...

[keys.insert]
A-53 = "normal_mode" # Maps Alt-X to enter normal mode
# or this ?
64-53 = ...

Implementing a wizard that knows how to construe such (language independent) config would be trivial:

Move the index one key up from the home position and press the resulting key: ...
...

# or maybe better
Press key(s) for `move_char_left` command: ...

Ambiguous key combinations, could be encoded using CSIu for the terminal that is used.

[archseer]

This is what #133 discusses, I think it's not as easy to get access to scancodes in a terminal, since they're already translated by the kernel into keycodes.

[blaggacao]

On my current workman (with blank keycaps), I have to do something like this:

# home row
n = "move_char_left"    #           r'index
N = "extend_char_left"  # l'pinky + r'index
e = "move_line_down"    #           r'middle
o = "move_line_up"      #           r'ring
i = "move_char_right"   #           r'pinky
I = "extend_char_right" # l'pinky + r'pinky

It's really annoying to configure. See also a possible aliviation

[pickfire]

Side stepping a bit the main thread of the discussion, I want to suggest the following read: https://discuss.kakoune.com/t/key-maps-as-key-locations/1414 (disclaimer: I'm the author)

Applications yes, terminal hard. Games like dota have an option to allow that. Do you have an idea how we can do that?

[cessen]

This is what #133 discusses, I think it's not as easy to get access to scancodes in a terminal, since they're already translated by the kernel into keycodes.

We might be able to get the scancode for each key via a non-terminal library, and then build our own map from temrinal-keycodes -> scancodes and use that.

I'm not sure how reliable that would be, though.

[blaggacao]

I'm not sure how reliable that would be, though.

I think (keymap-) "disintermediation" where we need it (modal commands, not normal typing) an thereby reclaiming full control for the core driver of a modal text editor (= muscle memory), should give us the power to make it extremely reliable.

[cessen]

I meant reliable as in "works correctly and gives the same keycodes on all supported platforms".

I agree that having the option to configure hotkeys by keycode would be good. But it also needs to work reliably, rather than being a hack that sometimes fails unpredictably.

[EpocSquadron]

I want to surface some really thoughtful commentary on the power of kakoune's editing model, along with some more profound things it could do better. It's a longer read, but opened my mind to kakoune's editing model in ways that didn't cross my mind in two years of dedicated usage. Helix stands to gain much from looking at the deeper lessons of it's inspiration.

https://discuss.kakoune.com/t/array-iterator-and-looping-behaviour-in-kak-script/1287/12

[NNBnh]

Hi guy, I created a keyboard visualization for the current keymap, I also added it to the Keymap brainstorm wiki page. Hope you guy found it useful!

Keyboard layout editor link.

[NNBnh]

I have always looking for a modal terminal editor that use caret style cursors, Helix currently has implement Gap indexing #376 which mean the caret cursor dream is not far from becoming the reality.

So as @cessen said:

I'll switch Helix to gap indexing, but keep all current behavior the same and enforce a minimum-1-width range.

Behavioral changes can be a separate discussion...

Let's discuss about refactor the keymap to take advantages of it (and more). Here is my attempt:

Keymap refactor

Because of a defined Helix's goal from vision.md:

• 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.

I feel more confident making some brave decision that focus way more on consistency.

Also i found a lot of my idea have been implemented on Pepper editor so some keys are take inspiration from it's key bindings:

Pepper is heavily inspired by Kakoune's selection based workflow and multiple cursors. However its cursors behave like caret ranges instead of block selections. That is, the cursor is not a one-char selection but only a visual cue to indicate the caret location.

The final results will look like this:

Keyboard layout editor link.

Current keymap

I thinks the movement will stay pretty much the same except for moving to the end of an object:

Because the implement Gap indexing, moving to the end of an object (e.g: a word) will place the cursor to the right of the last character of the object.

When there is only one cursur with no selection (call it WHEN1), base on each oporation, it will have an effect to the whole line or just a charater that it's stand on.

Charater WHEN1 oporations:

• replace
• switch_case
• switch_to_lowercase
• switch_to_uppercase

Whole line WHEN1 oporations:

• yank
• delete_selection
• format_selections
• toggle_comments

Text inserts

For consistency, any actions that insert text to the cursor will have the following behaviors:

1. Insert text will replace the selections.
2. If a cursor doesn't have a selection, insert text will be place to the left of that cursor.
3. If a \<n> number is assigned, the text will be insert \<n> times.
4. Inserted text will be selected (work with number assign).

Because insert text will replace the selection:

• Remove change_selection from c
• Remove replace_with_yanked from R.
  • Move copy_selection_on_next_line, copy_selection_on_prev_line from C, A-c to c, C.

Because of the same reason, users don't need to different "insert" and "append" anymore:

• Remove append_mode from a.
  • Unmap prepend_to_line from I.
  • Move append_to_line from A to I.
• Remove paste_before from P.
  • Rename paste_after to paste.
  • Move yank from y to Y.
  • Move paste from p to y.

    Is might seem stupid to place yank and paste on the same key, i don't like it too but please hear me out: we need a key to place move_search_prev and move_search_prev, p is the only one fitting for the function. therefore i make the hardest decision in my life

    (I place paste to y instead Y of because we paste more that yank.)

• Remove shell_append_output from A-!.

TODO	Improve append_to_line and prepend_to_line.

Word movement key

Although most people have somewhat agree that #500. Under this new system, word movement keys like w, b and e (and almost all movement key) should not also create a selection because "insert text will replace the selection", it will become very annoying.

I also found that move_next_word_start is just a legacy key that people get used to from Vi. Where move_next_word_end is much more superior in this navigation system, not to mention it's behavior is consistent with move_prev_word_start. I know this is a controversial decision but Pepper and literally all non Vim-like editors agree with me on this one:

• Unmap move_next_word_start, move_next_long_word_start from w, W.
• Move move_next_word_end, move_next_long_word_end from e, E to w, W.

No Alt-based keys

I have remap nearly every keys on Vim, Kakoune, Emacs (lost config) and i alway include a feature: a "normal" mod key in insert mode (which i explain in more detail at #1064).

To achieve this, we mustn't have any Alt-based keys by defaults.

Plus as mentioned in keymap brainstorm wiki:

we prefer not to hold keys (shift, ctrl, alt)

• Move flip_selections from A-; to F.

• Move shell_pipe_to from A-| to \.

• Move split_selection_on_newline from A-s to C-s.

• Move switch_to_uppercase from A-` to ^.

• Move rotate_selections_forward, rotate_selections_backward from ), ( to C-n, C-p.

  • Move rotate_selection_contents_forward, rotate_selection_contents_backward from A-), A-( to ), (.

• Move indent, unindent from >, \< to ], [.

• Move keep_primary_selection from , to e.

• Move remove_primary_selection from A-, to E.

• Move repeat_last_motion from A-. to ,.

Future keymap

TODO.md

The following keymaps are in TODO.md:

1. Align selections:
   • Add align to &.
2. Macros:
   • Add play_macro to q.
   • Add record_macro to Q.

3. Marks:

   This is currently being discussed in #703 and #943.

   Maybe move Match-mode to a then add Mark to m.

Search

The following keymaps are mark as TODO in Helix's keymap document:

• Rename search_next to move_search_next.
• Rename search to search_next.
• Add search_prev to ?.
• Add move_search_prev to p.
• Add extend_search_prev to P.

Remove selections matching the regex

As explained in #1062:

• Add remove_selections to R.

Paragraph

As explained in #753:

• Add paragraph_next to }.
• Add paragraph_prev to {.

Jump mode

As discussed in #274 #510, we will have a much more fast and convenient way to navigate the code. In contrast find and till keys will just be a slow clumsy unpredict legacy ways to navigate that took space on keyboard. The only advantage of the find and till keys is they can be use when there is multiple cursor, but then user can just use the search key which way more powerful and consistent:

• Unmap find_next_char, find_prev_char from f, F.
• Unmap find_till_char, till_prev_char from t, T.
• Add jump_mode to f.

Replace values

As explained in #967:

• Add value_next to >.
• Add value_prev to \<.

[raphCode]

I would love to try this, can we throw together a mapping to easily test it in real-life scenarios? At least some of the ideas, since not everything can be remapped without code changes I guess...

I really like reducing the number of word-based jump commands in your proposal. Three commands as currenty (w, b, and e) feels wasteful.

I actually find a keymap where the selection is started explictly more intuitive, since at the moment some movement commands create selections (w, b, e, f, t), and some do not (h, j, k, l, g). I find this not very consistent and also, for me, the automatic selections seldom do the thing I want:

• I almost never need to delete only a single word, so I need to switch to selection/extend mode anyways
• When I just want to move to insert text somewhere, I don't need a (potential distraction) selection (see also #500)

The action-selection order of vim elegantly does not require an explicit selection since issuing a command is an indicator for interpreting the next movement as selection to operate on. Nevertheless I find a visual selection helpful, and one can also shape the selection with multiple/different movements.

Please consider keeping f, F since I use these often to jump into the middle of a word with a typo (especially german words can be pretty long). Alternatively, the jump mode could incorporate this workflow by offering multiple jump targets in longer words.