Are you happy with helix's keybinding model? [User Opinions]

[txtyash]

I'm experiencing inconsistency with helix's keybindings. I wish it mostly followed vim's model or kakoune's alone or both available to choose from. For me the keybindings seem not so efficient comparing them straight with kakoune or vim. I experience more mental overhead and inconvenient keystrokes as compared to kakoune or vim but I love having more inbuilt capabilities and features with blazing fast performance.

This is just my opinion and I'm probably inexperienced to think the helix way.

I want to know what other users think of the keybinding model?

I'm interested to know what other users think of helix's key binding model?

[pickfire]

Not all keys are good yet, there are some changes that I would like to do but haven't go to do it yet, like getting visual mode to be more consistent, having goto extend by default and such.

Quite a few things mentioned here can be implemented, I did tried asking in the chat and seemed like people do agree to some of the suggestions mentioned. #165 Also, if you have suggestion or faced any specific pain points, that can be discussed separately or in the same place.

[matoous]

For what it's worth, I am fine with it as it is as it was easy to switch from nvim to helix, on the other hand I am looking towards experimenting with some of the proposed new keymaps to see if it will suite me better.

[kirawi]

(Slightly relevant?) https://github.com/helix-editor/helix/wiki/Keymap-brainstorm

[bound-variable]

I would prefer not having to use the home and end keys - it's awkward with my keyboard, having to press Fn. But I'm a noob, so...

[valpackett]

Now you can rebind keys..

[tadashi90]

Suffering with the same problem.. Didn't want to rebind stuff, I hate to waste time configuring stuff. To not have to install and configure a bunch of stuff is why I'm using Helix =(

[sycured]

I'm a very long time user of vim and recently of neovim
I'm totally disappointed by the keymapping, it'll be good to have an option in Helix config to have vim mapping (keymap = default/vim) so the vim keymapping file already in helix

If someone has a full keymap like vim, I'm ready to try it… I'm going back to vim/neovim due to the keymap and how long is creating the vim keymap for Helix

[NNBnh]

If you want Vim keymaps then Helix is just not for you. Helix keymaps design around multiple selections therefore it should be different. Vim-keys compatibility isn't the project goal...

But maybe Helix could be for you if you try to get use to Helix's keymaps because the multiple selections keymaps design is great, it's quite similar to Vim. If you find it difficult to remember then try this cheat sheet, once you get used to it, you might appreciate it more.

[bob3000]

I pretty much appreciate the intention of a modal editor with a consistent concept of a keymap. The Helix keymap actually seems much more consistent to me then the vim keymap.
However I'm looking back on a period of more then ten years of conditioning my muscle memory to the Vim keymap. I'd even take the effort learn a new keymap because I like Helix's design with it's build in features. I can't do a complete switch yet though because I program in many different languages and I heavily rely on some vim plugins the are not optional to me.
For the time being until the functionality of these plugins become available in Helix in core or via plugin I would have to switch between Helix and Vim because of certain languages and that would obviously end up in total mental confusion and would be the opposite of productive. Does that resonate to somebody?
As much much as I appreciate the consistent Helix keymap I'd still find an option to switch back to classic vim keys amazingly helpful. If a corresponding configuration setting is not that much desired by the community a copy and paste snippet for the configuration file to get the classic Vim key layout could also be an option. Has anybody ever done that yet by any chance?

[sudormrfbin]

A vim-esque keymap would be near impossible to add without significant changes to the core system because of one fundamental difference - the selection first, action second in helix borrowed from kakoune.

In vim, for example if you press d it waits for the next movement or textobject key to know which part of the text to delete. But in helix there is no waiting around; a d immediately deletes whatever text is selected. Every editing primitive is designed around the invariant that it acts on the currently selected text.

[bob3000]

Thanks for the explanation. Keep up the good work. You guys are doing great stuff here 👏

[David-Else]

I have only been trying out Helix for a couple of days, but so far I am thinking:

EDIT: I found out more keys!

• Why not add back some familiar vim keys WHEN they don't clash with the Helix ones? I am missing:

D delete till end of sentence (vgld)
Y yank till end of sentence (vgly)
C change till end of sentence (vglc)

Would this be violating some principle?

I am LOVING the space and f, b, k etc. This feels so right :)

I am not comfortable with the selecting first approach yet, but I think it is probably better and could get used to it.

I think people not liking the keys is the number one thing that will stop people switching to Helix, so best to make any changes sooner rather than later.

[pickfire]

For this I usually do vgld to delete to end of line and vghd to delete to start of line, I am thinking of removing the v but that's not done yet.

[David-Kunz]

Yes, D, Y and C are the ones I miss most. However, I wouldn't directly introduce those commands in Helix because of its different philosophy (select first, then perform the action) but I would at least provide a single key to select until the end of the line.

[the-mikedavis]

You can bind a key to do this like so:

[keys.normal]
"$" = ["collapse_selection", "select_mode", "goto_line_end", "normal_mode"]

[valpackett]

There's no need for the "select_mode", "goto_line_end", "normal_mode" dance. I just have

[keys.normal]
"$" = "extend_to_line_end"

[tjmgregory]

Enter (or fEnter can also be a good choice if you want to select the newline itself). Any keybind where you get to slap the keyboard is fun :)
This was my favourite new tip in a while!

[leeola]

I mostly changed keybinds to my custom Kakoune. I didn't find anything lacking in my Kakoune binds, but Helix had superior(easier) LSP integration for me, and i think is performing better to boot. Plus it's in a language i like so i can contribute.

The thing i'm most happy about is it has been so configurable. I didn't want to change to a new editor mostly. Helix let me keep most of my Kakoune-UX, and i'm really happy with that configuration support

[sdothum]

Care to share your Kakoune for Helix key bindings?

[getreu]

Is there an key binding set that does not rely on the [alt] key as modifier?

The [alt] key combinations are used by the i3-Window Manager in my setup.

[txtyash]

U should probably use the windows key as mod for your i3 setup. If it is in an uncomfy position then swap it's position with alt with some key remapping tool.

[getreu]

This is how I followed your advice:

U should probably use the windows key as mod for your i3 setup.

In /etc/i3/config set

set $mod Mod4

If it is in an uncomfy position then swap it's position with alt with some key remapping tool.

in /etc/default/keyboard set:

XKBOPTIONS="altwin:swap_lalt_lwin"

---

Can one remap the [alt] key as modifier in one go to some other key, lets say [ctrl] key, [shift]+[ctrl] or [win] key?

[getreu]

Is there an key binding set that does not rely on the [alt] key as modifier?

Keymap refactor · Issue #1179 · helix-editor/helix

[JigglyBuff-Kun]

I just started using the project, so far so good. I am coming from neovim / doom-emacs. I like how a lot of the features are built into the editor, unlike vim, where you have to install plugins. Going forward, I hope this is how the project grows, with lots of sane defaults built into the editor rather than having to configure everything. This will bring more people who are put off by configuring vim to use helix.
Regarding keybindings, I am still getting used to it. I do like the idea of helix's approach, this is the first time I am using it.

My question to other users who use vim keybindings in other software, how are you guys changing your workflows to adapt to helix ?
For e.g. : I use doom-emacs to use org mode(evil mode), I think it would be a pain to use it after using helix for a while. Also, will helix have something like org mode in the future included in the core ?

[pickfire]

For e.g. : I use doom-emacs to use org mode(evil mode), I think it would be a pain to use it after using helix for a while. Also, will helix have something like org mode in the future included in the core ?

org-mode I think not anytime near, and it doesn't seemed to be able to be done with LSP I think, so most likely it needs to wait for plugin

[jficz]

Using Helix for a few weeks now after using Vim for like 20 years. It's not as bad as I have expected but I still have a few issues:

• Home & End keys are awkward, I still keep hitting 0 instead of Home. I kinda like the idea presented in "Better" Home/End/PageUp/PageDown #2131 (i.e. using H & L)
• I have trouble with d and x, mainly because I'm used to Vim's x and dd which makes my line and char delete operations a pain. But I guess this is more about me not yet being used to the select-first paradigm
• not sure if bug or feature - when x is pressed on empty line, it selects the line below it as well. On top of that pressing d on empty line deletes the line. This makes deleting whole lines inconsistent
• again, not sure if bug or feature - when I press PageDown and then PageUp I end up on a different line. I've got a ThinkPad with PgUP/Down right next to arrow keys and sometimes I press them accidentally which destroys my flow because I can't easily go back to the place I drifted from
• I really miss V and C-v features (line select and block select) - I know V can somewhat be emulated by x but C-v does not have an equivalent I could find. The closest thing would be split-line multi-cursor select which is much more complex in comparison
• Also, ZZ :)

[CptPotato]

not sure if bug or feature - when x is pressed on empty line, it selects the line below it as well. On top of that pressing d on empty line deletes the line. This makes deleting whole lines inconsistent

I addressed the same issue here: #835

[sbromberger]

If it helps, I mapped ZZ:

Z = { Z = ":wq" }

It's not quite the same, but it's good enough for my use.

[vtmx]

[keys.normal]
Z = { Z = ":wq" }

[sycured]

Someone did a vim-like config for helix: https://github.com/LGUG2Z/helix-vim

So maybe vim users can migrate more easily to helix… without having to relearn absolutely all keymaps

[LGUG2Z]

I noticed a few of the Helix maintainers starred it, though I'm not sure if it's because they like the idea/execution or if it's because they like the README. 😅

[the-mikedavis]

Admittedly, reading through config.toml did put my hair on end a little but overall I'm very impressed how close to vim you can get with some determination. Plus of course the readme is great 😄

We're looking to merge a fix for #2051 soon - maybe before the next release (no promises though) - not that I can ever condone using Helix like this 🙂😛

[LGUG2Z]

Just looking through all the requests/demands for a Vim mode in various issues/discussions/PRs here, I have a lot of empathy for all of the contributors and maintainers here.

From my experience writing and maintaining komorebi, which aims to be somewhat similar to two incumbent tiling window managers (bspwm and yabai), but different enough in key areas that justified the creation of the project, I have been met with many users who want it to shed its peculiarities and be the same as those twms (kind of like the Kakoune comments here), or alternatively, they want it to be changed to be like something totally different like i3 (kind of like the Vim comments here).

I hope to be able to get this configuration to a state where, when people comment asking you to "make this like VIM!!!?!?!?" in the issues and discussions in the future, it's easy to link to and say "Here you go, try this at your own risk" and end those conversations without having to put so much mental energy into the endless back-and-forth justifying the design and vision of this project.

[diktomat]

I mostly like it, only added H/M/L keys I'm used to from Vim (see below). What I'm constantly stumble upon though is the handling of newlines as regular characters. xc putting me on beginning of the next line instead of keeping the line I'm on, x on an empty line selecting that one and the next line, etc. I get that it's more consistent, it just doesn't fit my mind apparently.

[keys.normal]
H = "goto_window_top"
M = "goto_window_center"
L = "goto_window_bottom"

[ChrHorn]

I mostly like it, only added H/M/L keys I'm used to from Vim (see below). What I'm constantly stumble upon though is the handling of newlines as regular characters. xc putting me on beginning of the next line instead of keeping the line I'm on,

You can use x_c to imitate vim's cc behavior. It is a bit clunky, but once #2634 is merged it will be possible to rebind it.

[the-mikedavis]

x on an empty line selecting that one and the next line, etc

You may want to use X when you think "select the current line" rather than x. x is inconsistent with the rest of normal mode actually and to have it behave like the other motions, you can remap like so:

[keys.normal]
x = "extend_to_line_bounds" # previously "X"
X = "no_op"
[keys.select]
x = "extend_line" # previously normal mode "x"

[noor-tg]

I was using doom emacs so I used to do space space to open project files list. and I mapped it to hilex config with

[keys.normal]
space = { space = "file_picker" } 

I think it is better than using space f

[langston-barrett]

Similarly, coming from Spacemacs, I use

space = { space = "command_palette" } 

[workingj]

i'am pretty much happy with the std key mapping of helix, find it very intuitive.
But for me learning and relearning keys is also not so much an issue.
So i go with the build in, except a few additional commands mapped for my work flow.

[jharrilim]

I don't really have any gripes with any individual bindings. I can say that the thing I enjoy the most about helix is that it opens modal dialogs for its different modes (modal modals?), and makes it intuitive to discover/rediscover keybindings. The command palette is super useful too, and is a great way to discover what some of the keybindings are.

There is a nifty trick you can use from the command palette (space, ?) to search for keybindings: Type in (, some key, and then ) to "search by binding". ie. (C) will show you that the C binding is "Copy selection on next line"

All of the features around discoverability and useability is what wins for me. It takes a lot of weight off of individual key bindings. In comparison to vim, well, try doing a Google search for "vim keybindings" and "helix keybindings". vim has :help tutor, but helix has :tutor, docs.helix-editor.com/keymap.html, and all of the dialogs you get while editing.

I think as long as good discoverability remains a key theme for helix, I think the weight on individual key choice selection matters a lot less. Not to say that it doesn't matter entirely of course, but I think I'll be happy with most keybindings that are given to me, so long as there is documentation and that they're searchable.

[Nathan-Furnal]

I'm an Emacs user and being able to use Ctrl and Alt instead of the modal experience would be amazing.

[haxfn]

You are not helping

Your comment was unhelpful itself instead. What did you not find helpful? What did you not understand, convey that if you need help.

What is your motivation to switching to helix? What should you do to copy/paste from the system clipboard? Convey/Ask all that. Don't say, "You are not helping" instead say "I still don't understand this"

[pycaw]

You are not helping

Your comment was unhelpful itself instead. What did you not find helpful? What did you not understand, convey that if you need help.

What is your motivation to switching to helix? What should you do to copy/paste from the system clipboard? Convey/Ask all that. Don't say, "You are not helping" instead say "I still don't understand this"

My motivation is to use a modern, decent terminal-based editor with LSP support and no modal UI forced down my throat. I use micro but LSP support is lacking. Emacs doesn't classify as modern and is too quirky (tried it as well and ditched it long ago). So Helix would be great if it extended its UI to work out-of-the-box with non-modal style. I myself, naively, don't see why that is such an impossibility or against its core design principles.

[haxfn]

no modal UI forced down my throat.

Don't try swallowing modal editing either try learning modal editing first or try @pycaw try this maybe microsoft/edit

be great if it extended its UI to work out-of-the-box with non-modal style. I myself, naively, don't see why that is such an impossibility or against its core design principles.

Maybe someone else will do a better job at explaining that to you.

[jficz]

@pycaw

My motivation is to use a modern, decent terminal-based editor with LSP support and no modal UI forced down my throat.

Then Helix is just not for you. Modal editing is a design principle editors like Helix and Vim are based on. If you don't want modal, you don't want Helix, simple as that.

[pycaw]

@pycaw

My motivation is to use a modern, decent terminal-based editor with LSP support and no modal UI forced down my throat.

Then Helix is just not for you. Modal editing is a design principle editors like Helix and Vim are based on. If you don't want modal, you don't want Helix, simple as that.

Sad to hear that. Hope someone will soon fill the gaping void.

[Sepero]

[gabydd]

You can rebind C-wp, for example to make it do nothing in insert mode

[keys.insert]
 C-w = "no_op"

Currently you cant rebind a group #1508 so you would have to manually add all the keybindings for window mode if you wanted C-w to have those bindings

[CaesarXInsanium]

I like the insert mode C-w, I can practice my spelling by deleting the entire word.
Also why would anyone leave the window in the middle of writing

[Sepero]

[pascalkuthe]

All of these insertmode bindings that go to normal mode and undo/save and go back to insert mode won't work and will cause crashes. Insert mode bindings aren't really supported by helix. Insert mode is intended only for inserting text, not any additional actions

[David-Else]

🧐

"A-s" = [ ":set soft-wrap.enable true" ]
"A-S" = [ ":set soft-wrap.enable false" ]

🍻

[keys.normal.space]
t = { s = ":toggle soft-wrap.enable" }

PS You might need the latest Helix version.

[TeddyDD]

I tried to use Helix, but the key map is the reason I decided against it. Helix uses bastardized version of Kakoune bindings. Kakoune differs from Vim, but at least there is the proof changes are for the better. Vim bindings have the advantage of familiarity. There is no merit behind Helix bindings (I'm not counting wave handy „not want to press modifiers”), just design by committee.

[kirawi]

Helix's keymap is designed to be memorable and easy to use, and we do take possible improvements into consideration. Number of strokes are not the goal, as per our vision: https://github.com/helix-editor/helix/blob/master/docs/vision.md

It would be more helpful to discuss where Helix's keymap falls short for you. We can also discuss what "better" means for you.

[archseer]

Ah yes, code golf: the ultimate proof of editor efficiency.

[archseer]

There's no design by committee. I've designed the keybinds the way I preferred them (and they mostly match kakoune, I don't find vww any less efficient than wW since you're still pressing the same amount of keys. Shift counts too)

If you don't like the mappings we of course allow key remapping, but sticking with a different editor is a perfectly fine alternative too.

[TeddyDD]

Ah yes, code golf: the ultimate proof of editor efficiency.

Code golf might not be the best metric, but at least it is an objective metric you can use and compare keymap with vim. What I'm trying to say is Vim bindings have huge value of being ubiquitous, and to change them you should have good reasons.

Number of strokes are not the goal, as per our vision

Fair enough

vww any less efficient than wW since you're still pressing the same amount of keys. Shift counts too

It's less efficient since you are dealing with one additional mode. The mental overhead is huge. I suspect that's one of the reasons why Vim golf counts modifier + key as a single keystroke.

At this point Helix kemap is like vim's with visual mode and multi cursors plugin + some visual feedback. Minor consistencty fixes won't change that.

sticking with a different editor is a perfectly fine alternative too.

Sure, sticking with your keybindings is fine as well. I'm not a target audience for Helix. Just wanted to express my opinion.

[dead10ck]

Code golf might not be the best metric, but at least it is an objective metric you can use and compare keymap with vim. What I'm trying to say is Vim bindings have huge value of being ubiquitous, and to change them you should have good reasons.

There is nothing objective about personal preferences. There is nothing inherently better about objectivity when comparing a subjective experience. This is like saying saying one blanket is better than another because its thread count is higher.

Sure, sticking with your keybindings is fine as well. I'm not a target audience for Helix. Just wanted to express my opinion.

Expressing constructive feedback is always welcome, even if you decide helix is not for you. Just showing up to say "lol vim golf 🧐" is just trolling.

[EnricoGhiorzi]

I use Helix as my first modal editor (tried NeoVim and Kakoune before but failed to stick to them). I now use it as my main editor for pretty much everything. This alone says a lot about Helix's user friendliness! Though, as a user, there is something I cannot wrap my head around. To use a command, I can either:

• Use a keybind, if I can remember it
• Press ':' and get into command mode, which uses a discover-as-you-type model
• Press space and get into space mode from where I have a tree-menu-like with some commands
• Into space mode, open the command palette with fuzzy-finding

Commands can be accessible in any of these ways without an apparent consistent structure: some are duplicated in multiple modes, others are accessible in only one way. Only command-mode commands can apparently take arguments. This is confusing and I wish there was a more unified model.

[kirawi]

I want to provide some context:

• Helix began without any keymap customization for a while until it was tacked on as a band-aid solution until the plugin system could supersede it (Configurable keys 2 (Mapping keys to commands) #268). The possibility of unifying typable and regular commands was also acknowledged, thought it seems it was lost to history (Configurable keys 2 (Mapping keys to commands) #268 (review)).
• Allow multi key remappings in config file #454 added support for chained keybindings
• space-? was added for command discoverability which became more useful once we started adding commands without assigned keys (VS Code like command palette to search for commands and keybinds #559). Prior to this, the recommendation was looking at the source code.

[thiagomajesk]

I posted a comment just recently about my experience coming back to Helix with a different perspective… Just gonna link my previous two comments here for visibility (and future reference): 1) #165 (comment) and 2) #165 (comment).

[goyalyashpal]

helix just didn't work for me. there have been constant bugs and bugs and bugs in my experience with it.

just on the distribution side:

1. this one has been long fixed, so not mentioning it
2. then this msys2-pacman + hx = 🐛: [distribution] helix not launching (installed via msys2) #8017
3. this wezterm + hx = 🐛 one still persists: bad captures of key combinations wezterm/wezterm#5213
   which when fixed would replace this one: Support Alt+<key> to act as ESC <key> (ref: Emacs/Neovim/Iterm2) #3162

after sidelining these distribution problems, even the usability part of helix has been horrible for me unfortunately:

1. first major one was this 👀 : how to view sideways? #5794
2. and this 🔲⬆️ : Unselect line from down #5548 (reply in thread)
3. and the biggest of all, the poor poor line ⬌ selection: how to move current line up or down #5764 (reply in thread)
4. then this one finally made me give up on helix for good ⧉⌧🔳: Match m doesn't respect SELect v mode #6435

not to mention the 5-7 others which i was willing to put up with. and many many of the following recurring theme:

per1: no good use case, no point in making this new feature configurable;
per2: but this breaks my work & is doable in neo/vim

i have just re-continued my learning journey on neovim, and it's ohkay so far too.
yes, helix was kinda my first dedicated venture into modal editors

[haxfn]

I had used neovim for about 3 years then four months ago, when configuring rust was a pain I decided to use helix cold-turkey, never looked back at neovim.

Sufficiently consistent keybindings when editing and sufficiently synergetic modal editing, Discoverability of features, ready-to-use, fast (pasting huge files in a zap).

Rough edge: inconsistent keybindings. file-pickers not using same keybindings, command mode ':' not using same keybindings.

Rough edge: hackability. In terms of laying bare components of the editor (project name, file editing time, list of buffers open) and writing my own cute programs with them for keybindings.

What do others think about my comments?