Some VI compatibility suggestions

[yerlaser]

Since we live in an imperfect world even developers, but especially system admins often need to SSH to remote hosts or use containers where your loved editor and/or personal config is missing. This makes it very awkward to use VI as muscle memory dictates different bindings.

Therefore, while using Kakoune I developed a few workarounds for myself to have at least a basic set of features (greatest commond divisor) to be the same on both. So, when in basic VI, I trained myself to always press "v" before changing commands. So, 'vd'='d', 'vwd'='wd' etc. However, that alone doesn't solve all the problems, so I identified the following mappings that need to be the same:

1) I found that deleting a line is a very common operation that needs to be done while editing config files. Since 'dd' cannot be made compatible on both editors, I retrained myself to use 'Vd' instead. For this purpose, 'V' needs to mapped to 'x' (select whole line). 2) ';' is also pretty useful to repeat a character search. So, I would suggest to remap 'collapse to character' to 'Tab' or 'Enter' instead, which are still pretty accessible and don't have destructive mappings in VI. 3) '%' would be good to be the same 'move to matching bracket', while select entire buffer can be put on 'S-Tab', e.g. 4) I would suggest to add Ctrl-R (or replace 'U') as a binding for redo operation. 5) Finally, 'G' is indespensable to go to the end of file (can also select along the way in helix).

I did not want to suggest such changes to Kakoune developers because that would perhaps insult them as the workflow is already well established. Therefore, I have above mappings in my custom config. However, since you're a new project, I thought that you might want to consider these as I think these changes could benefit all users.

[CBenoit]

(I'm not sure "C-bug" label is appropriate here)

We're currently in the process of thinking a lot of things about key mapping, configuration etc, so I'm not sure this issue will be addressed before and I don't know if this should be the default. Maybe we could add various CLI arguments similar to VIM's -v for "vi" mode for this kind of use cases?

[yerlaser]

Hi CBenoit, Thanks for the response. Yes, sure, feel free to change the label to something more appropriate (I can't do it myself as I don't have permission to do so).

[CBenoit]

Oh, I see we can only open "bug reports" when creating a new issue. @pickfire do you know about this? EDIT: there is a button "open a blank issue", but we should maybe add more options.

[pickfire]

I don't have control over the repository settings. I have suggested that it could looks like clap new issue for better experience. But @archseer have the final say on that. Only he can touch that, right now the only option is opening a blank issue or the maintainers manually amend it.

helix is not meant to be vi-compatible from what I know but ideally we could have configuration to be able to change that, but it's current mode system is very kakoune-based so we can't possibly change delete to take a movement key. It's only possible if we have everything as configuration based, even the core model and keys. That still depends on how @CBenoit thinks we should do the plugin, I haven't investigated that but I think it would be better if we pull out the helix-term and helix-core subset of movement and models related stuff into a single separate crate for the plugin system to be flexible.

But yeah, although not vi-compatible we can do the tasks in a different way. It may not be a good idea for newcomers so ideally having a vi-compatible keys via plugin is a better option I believe.

I found that deleting a line is a very common operation that needs to be done while editing config files. Since 'dd' cannot be made compatible on both editors, I retrained myself to use 'Vd' instead. For this purpose, 'V' needs to mapped to 'x' (select whole line).

We can do xd but someone suggested in removing that but I don't think it's a good idea to do Vd instead.

';' is also pretty useful to repeat a character search. So, I would suggest to remap 'collapse to character' to 'Tab' or 'Enter' instead, which are still pretty accessible and don't have destructive mappings in VI.

I don't know if we can use n for that or not, I think in our case we can follow kakoune and do alt-; maybe, not sure. But switching to Tab is not possible since it will break ctrl-i jumping forward. Enter I don't think we require a big enough button for it. I think maybe the best way is alt-; not sure what others would say.

'%' would be good to be the same 'move to matching bracket', while select entire buffer can be put on 'S-Tab', e.g.

We have m for that.

I would suggest to add Ctrl-R (or replace 'U') as a binding for redo operation.

U is more intuitive which is probably the reason why kakoune use that key. I believe we favor intuition and learnability over backward compatibility as of now.

Finally, 'G' is indespensable to go to the end of file (can also select along the way in helix).

We have gs for that. After I do the info box you will find it easy to use like kakoune.

Not that our keys still differs from kakoune since we want to solve some pain points we have in kakoune as well as vi.

Most of the issue I can see is not needing to learn a new set of keybindings. So I suggest rather than replacing the existing helix keys, we can provide a compatible plugin based just for vi emulation with minimum extra keys to let users easily try out helix.

[yerlaser]

Hi, thanks for your extensive answer.

Just to be clear, I don't suggest full VI compatibility. I am a happy long time Kakoune user and I value the overall binding structure. However, at work I need to connect to hosts that I don't control and thus kakoune isn't preinstalled. In that case, I have two choices: vi or nano. I really don't want to go all the way back to non-modal editors so I attempt VI. But, when I am used to the default Kakoune binding, I immediately feel handicapped. 'xd' is a good example here. In VI x deletes a single character under the cursor and d changes to delete mode and awaits a movement key. Now, if I press j or k I'd delete two lines instead of one. Then I have to undo and start over. As you can imagine it gets very cumbersome.

This is why I suggest only a "basic" compatibility level which with the technique I described in the original post (i.e. pressing 'v' before any movement and change command while editing in VI) makes this possible. And it requires only a few changes in the bindings of Helix.

[CBenoit]

Sorry, I misunderstood your initial question. You want to use helix on your workstation with keys similar to vi's so you don't feel impaired when working with vi remotely. I think a plugin / configuration for vi-like keys is the best here. Hopes are you can fully configure all the keys with a keys → command mapping (a different approach than vim and kakoune), at this point you'll just write or grab a key configuration close enough to vi. A few default profiles will likely be hosted, but we're not there yet.

[yerlaser]

OK. Thank you! I'll look forward to the future releases of Helix.

[archseer]

I don't think we want to provide something like this out of the box, but it should be possible to use the key remapping config that was recently added.

[pickfire]

Someone could add a file under contrib/ to have keybindings for vi-compatibility but I don't think we want to provide something like this by default.

[yerlaser]

OK. Thank you. I understand. Maybe in discussions I'll raise a different option in the same direction.