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 (mawww/kakoune#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