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.