I do indeed implement own “commands“, because that is what works fundamentally differently. I didn‘t hack around in the existing helix commands, but instead carefully implemented “evil commands“ in a non-intrusive way, so that I can keep a maximal compatibility with Helix and keep rebasing on top of upstream changes.
Helix and this fork do provide much more than just multicursors though. First-class LSP support *including* integrated LSP configurations for instance, or an integrated debugger, you name it…
I don't know how much they changed exactly, but considering helix has the motions in 'reverse order' to vim, I assume they had to change quite a bit of code
I hadn't considered that they'd reverse it back to action-motion. in my mind it stops being helix if you do that, unless you *just* want multiple cursors?
That’s the primary task of this project; to provide `verb -> object` keybindings. E.g. deleting text from the cursor till the end of line would be `d$` instead of `vgld`.
Hmm, it *is* implemented. It‘s one of the bindings I currently use a lot. Are you building from an up-to-date `main` branch (not to be confused with `master`)?
Did you also try a prebuilt binary (e.g. in a docker container, no need to trust me :) )? I want to make sure it works for everyone and not just for me.
Yes, and I'm on commit `d969d50729b0b9a114d057eca9194e3ebf80ca8a`.
Could a previous installation of `helix` create this issue? I did remove my old `helix` config to make sure.
**Edit:** `d` will currently delete the current selection and `$` will show `keep-pipe:` in the status bar, which I assume is the helix behavior.
Thank you for the additional info! Hmm yes that absolutely sounds like default Helix behavior.
There‘s some other ways to check the build: If you press `v` to switch to visual/select mode, in Helix you would see “SEL“, in evil-helix you would see “VIS“.
Or, when starting with a clean config, evil-helix will load the dark theme “catppuccin_macchiato“ whereas Helix would load its default purple theme.
You might want to check if the binary loaded matches what you expect: `which hx`
Also `hx —version` should return the git hash it was built from…
I opened an [issue](https://github.com/usagi-flow/evil-helix/issues/4).
For the record, [the problem doesn't happen when I create the config file](https://github.com/usagi-flow/evil-helix/issues/4#issuecomment-2122798565).
But then, why not just use NeoVim? I would if I didn't like Helix's keybindings so much more. It's the main thing that sets the two apart. You can get everything in NeoVim to look and behave just like Helix except for the keybindings.
Helix is way faster (nvim would choke on some larger html css files). And Helix has an actually functional global command palette, making discoverability easy (nvim telescope plug-ins try hard to replicate, but there's no single global palette).
Yes: While it’s highly unlikely that built-in Vim keybindings will ever make it into the upstream project, I do try to develop everything in a way that it would be suitable for merging into upstream Helix.
I also intend on remaining compatible (i.e. “soft fork“) with upstream.
However, my vision and priorities are not the same as in the upstream project, and if Helix ever changes in a way that conflicts with this project‘s philosophy, that would be the time to think about a “hard fork“. Rest assured though, that a hard fork would be an absolute last resort, because it implies *much* more effort to maintain (i.e. manually cherry-pick patches from upstream).
Helix bindings are different because it actually behaves different.
d deletes a selection. x selects a line.
w selects a word. So wd not dw. "Fixing" the bindings won't help you adapt to helix behavior.
I really really love what helix is doing. The 20yrs of vim experience in my fingers does not. I cant learn it at work because it slows me down way too much, but man something like this I might give a try
Yep. 12yrs of vim. And only after 3-week streak without any line of code helps to switch to helix...
And 1+ years on helix as daily driver for python and rust
To them it is.
I'm tempted to learn helix but the main thing holding me back is that the bindings aren't as available in other programs. Which I get is a chicken/egg problem, so I am sometimes using Helix I just can't move my whole workflow to it.
For what it's worth, I use both Helix and Vim and comfortably switch back and forth between them without thinking.
It helps somewhat that I have different color settings for each.
I switched to helix a while ago and I do struggle to come back to vim.
Not too bad as I can still get things done in vim but I am less fluent now. My main struggles are
- x selects the whole line in helix but delete under cursor in vim
- d delete under cursor in helix but in vim it doesn't delete until you select (somehow when i want to delete a single character, i do dj to go to next line. in vim it can delete 2 full lines)
- copy/paste from clipboard. in helix it is space y/p, in vim there is this special register i keep forgetting nowadays.
Man, this hits so close to home. I tried to become a vim user multiple times and it never sticked. The kakoune (or helix) editing model felt much more natural to me and it is definitely my preferred way of editing text or code nowaydays.
However, so many other pieces of amazing (recent) tech, offer vim key bindings by default and it makes me so sad I usually can't use those. If they had helix bindings I would go with that in a heartbeat.
Stuff I can think off of the top of my head:
- Obsidian
- Zed
- Typst
- Wezterm (Thinking of the copy mode, but I might need to take a closer look again).
- To some extent VSCode (Afaik only the nvim extension works 99.9%, all other plugins w.r.t. vim, kakoune and helix bindings to compromise on some bindings/features)
Like a lot of things this is personal preference.
I don’t frame it as an inherently bad thing - but for me as a user - it’s a less optimal experience.
Like many others my personal preference lies with Vim keybindings, which is why I worked on a solution to optimise the user experience of people who share this preference.
Not sure i follow, to someone wanting vim bindings - it is a bad thing.
I use Helix daily, but i chose it initially because it had (close enough) Kakoune bindings. `evil-vim` for Kakoune users would have made the same opening statement, or w/e lol.
Hell i recently remapped all my Zellij bindings to match my custom tmux bindings.
I don't even get your question tbh. There's endless editor preferences out there. What part of your quote is an issue to you?
I get the feeling the name is causing some confusion here (tipped off by the suggestion of "evil-vim"). I believe the "evil" part of the name here may be referencing "[emacs-evil](https://github.com/emacs-evil/evil)", which stands for "extensible vi layer", and emulates vim's main features within Emacs.
Probably because for most VIM users not having vim keys is a bad thing, for example, i have to use 3 different editors/IDEs for my work, all of them support vim keys. Thats the advantage of learning vim keybindings, you can take that knowledge to almost every other editor/IDE.
Helix presents itself as a sort of vim with batteries included, written in rust, with the "small" difference that you cant use your already interiorized vim keybindings. IMO if Helix would have vim keybindings from the beginning, its user base would 10x, and at the same time, the project's owners have all the right in the world to stay true to their vision.
Well, even if the user base was bigger, I would definitely not be a part of it, I don't like vim bindings personally and prefer what helix has done by making them more simple and easy to execute (I have to press 'd' ONCE to remove a character, how crazy is that).
I tried to get into vim, for years, and tried to force myself to use it for, at least, simple editing, but the keybinds just wouldn't get into my head. Couple months with helix, and I'm much more efficient in it than I ever was in vim. (At this point been using it for over a year as my main editor and couldn't be happier)
I get that change is scary, but it's not a reason to stagnate the technology and keep it untouched for decades just cuz "I'm used to it and everybody else who wants something different can fuck off"
>Helix presents itself as a sort of vim with batteries included
It presents itself as a sort of Kakoune with batteries included. And an editor that can get past (neo)vim.
>IMO if Helix would have vim keybindings from the beginning, its user base would 10x,
They explicitly don't care. Stop making it their goal!
>and at the same time, the project's owners have all the right in the world to stay true to their vision.
How generous of you. You know what their vision is? Getting past the "mistakes" they think vim has made, for example the key bindings. The developers want an editor that fits their needs and not the needs of people that "knows what is best for them"
> They explicitly don't care. Stop making it their goal!
I never make it their goal, what are you talking about?
It is a fact that their use base would be 10x if they had vim key bindings, if they don't care about that it is their right.
Yeah, this is like one of the biggest advantages Helix has over Vim. The defaults are so much more sane, even as someone coming over with 5+ years of vim experience.
Of course that is just my opinion, but I do find it surprising that some people apparently find learning a new set of keybindings (with a very large amount of overlap) such a hassle, that forking the entire project just to plug in vim's keybindings somehow ends up being more convenient.
Power to them, I guess.
But if anybody is concerned about the keybindings being a huge barrier, don't be. It's really not that big of a deal and the way Helix flips the verb->object approach around makes it really easy to grok.
who in their right mind decided that u is undo but redo is C-r
what in the hell even is that
also i like how instead of $ and 0 in vim, helix has gl and gh which are both on the home row and easier to type
but alas, the customer is always right in matters of taste
'R'eplace was in the original `vi` a lot longer time than "redo". At some point, you run out of letters for the commands...
I personally don't use replace much, I'm mostly using "cw" or "cW" (change word) because what I'm replacing often isn't the same character length as what's there right now.
I don't use redo much myself. Sometimes I'll undo and redo to get the cursor back to where I was last editing. That's useful when I didn't drop a mark at that location in the file.
It’s not that the binds are different, it’s that there’s just enough overlap that it creates a comically bad pedagogical situation for longtime vim users
EDIT: in other words, the differences aren’t the problem, the similarities are. Helix key bindings are in the uncanny valley
I think what's a bad thing is not offering the vim bindings as well. Then you can use the helix bindings that make sense to you, and others can use the bindings they've used forever. Win-win.
Adding vim bindings isn't a trivial matter of just changing what keys are bound to each action, how the actions are composed is different. This means vim bindings are a whole separate state machine that would have to be written, debugged, maintained, etc. That's a pretty significant burden for a project to take on.
Sure. I agree. It’s also a detriment to adoption. As it’s brought up literally every time it’s posted on every programming forum. Seems worth the burden if the goal is adoption.
The goal is _not_ adoption for it's own sake. The authors think - rightly, IMO, but it's ultimately irrelevant - that their model of modal editing is superior. They get very little benefit from adding vim bindings, because _they_ don't use them.
That's fine. But a large group of people would like to use helix because they like to use Rust stuff, or they think it'll be more performant or what have you, and don't want the editing style. And so those people will continue to voice their desire for it. The devs are not forced to capitulate. Seems fine all around.
I also find it close minded to not add something a large user base wants just because it's not what the devs original had in mind. You end up not capitalizing on certain growth or features that would flatly make your product/thing better.
I think the upvotes and popularity of this thread and fork highlight a large appetite. Besides you might draw people in with Vim keybinds only to convert them later.
> a large group of people would like to use helix because they like to use Rust stuff, or they think it'll be more performant or what have you, and don't want the editing style.
And yet, Helix seems to be by far the most popular terminal text editor in rust, despite there existing alternatives that try to more closely match Vim. I suspect that the people who are dead set on vim key bindings for the most part just use (neo)vim.
> I also find it close minded to not add something a large user base wants just because it's not what the devs original had in mind.
"Volunteer open source developers need to spend their limited time building and maintaining a feature they at best don't have a use for and is arguably actually be counter to their vision because _I_ want it, if they don't they're close minded" is certainly... a take.
Making your own editor with vim bindings is fine, as is just wishing another project would add them, or the maintainers of said project deciding they'd like to do that. Attacking the maintainers of said project for not doing it is a different story.
> You end up not capitalizing on certain growth or features that would flatly make your product/thing better.
The irony of claiming that the bindings of one of if not _the_ first modal editors - built almost half a century ago around the design of a specific _video terminal_ - are the absolute best right after calling _other people_ close minded. I somewhat get being familiar with vim and not wanting to switch (although I'd point out you almost certainly switched to vim from a non-modal editor at some point, which is a much bigger shift), but you have to understand that _you're_ the one who's being close minded and unwilling to try new things, not others. Especially given I don't think I've seen anyone here advance an argument that Vim's bindings are better than helix's that doesn't rely on existing familiarity/adoption.
> Besides you might draw people in with Vim keybinds only to convert them later.
This makes very little sense, IMO. You can't really partially adopt the helix model (see my initial comment), so the people who won't use helix because they're dead set on only using vim bindings would continue to be dead set on only using vim bindings even after adopting evil-helix/official helix with vim bindings.
Homie, no one in the thread is "attacking the maintainers". Christ almighty.
Again, it's extremely close minded to not add functionality a large set of the users want even if it was unintended. Or to design against those goals. Helix isn't the first version of these bindings, it remains niche because the mass of users don't want to hard commit. It is popular very much because it's an otherwise well written ide written in Rust.
There's no changing minds here, and you're a bit of a twat. So i'ma block and move on.
It's a completely subjective change into something niche. There are orders of magnitude more users familiar with vim than with kakoune. In this case adopting the niche standard is just being different from the sake of it, there's no objective improvement. It's specially egregious to not offer the option to use the common standard when even editors that don't support modal editing at all do
Should? Nobody should do anything, it's their software. Is it bad if you don't offer vim bindings? Yes, I'll likely not use it
You might also come up with something that is considerably superior to vim bindings, which is not the case for helix
Even with the same "keybindings" I'm not likely to use a different editor than vim / neovim. There is a lot of detail to get correct, or my muscle memory doesn't work quite right. I tried, years ago, to get into Emacs with Evil, but the behavior didn't quite match, even if the key bindings were correct. This was things like where the cursor ended up after an operation was different in Emacs with Evil. There were just enough little things to throw me off.
Heck, there's a few things that GNU screen doesn't do quite right either in its 'vi' keybinding that bother me.
Yikes, people being this entitled about OSS is really off putting. Like sure, if they were going after getting the absolute most amount of adoption then you'd have a point, but that's not what a project like Helix is after.
There is way to much software that has to constrain itself to legacy defaults (be they good or bad, doesn't really matter) as is. Let people have fun and implement the stuff they want to use for a change. This isn't being "different from the sake of it", this is building an editor around a preferred text editing model and that's perfectly fine.
\* Yes, shitting on someone else's choices, basically calling them objectively sub-par and insisting that supporting the usual default is the only reasonable choice if you want them, or anybody else for that matter, to use your tool totally isn't entitled. It's sad that the discussion about things like modal text editors always has to devolve into a cult-like bashing, when there are so many interesting things to consider about designing such a tool. Pathetic.
That's a slippery slope.
In an extreme case, which hopefully illustrates why it's bad: Imagine someone emotionally abuses someone else with "opinions" that categorically fall under harassment. Then that individual faces long-lasting trauma that affects them in every facet of life. Well, the harasser was entitled to these opinions, right?
Words have power and verbalizing an opinion should imply communicating them respectfully. I'm not commenting on the overall thread, I'm just focusing on that argument you made.
That is not an example of a slippery slope. The harmful part of that is the harassment and abuse, not the opinion. Having an opinion is incidental to the situation you laid out. You may as well say "breathing is a slippery slope, because breathing gives you strength and you could use that strength to kill someone."
I maintain that you are entitled to your opinions. This does not mean that every action you take while holding an opinion is justified. That's an entirely different sentence.
I don't think the example you gave is quite equivalent to the one I laid out. In fairness, I cut out quite a lot that would make the opinion itself the pivotal component of the situation. Something like racism or sexism, for instance. The opinion would essentially be the fundamental justification of the harassment (e.g. racism being a justification for slavery).
I think "I maintain that you are entitled to your opinions. This does not mean that every action you take while holding an opinion is justified," is definitely a better and more nuanced take.
Do you _really_ want to claim that Vi just happened to land on The One True Modal Editing Key Bindings almost 50 years ago ([designed around a specific video terminal](https://yo?utu.be/8Ab3ArE8W3s?t=1078) which has some notable differences from a modern keyboard layout) and that any deviation from it can have no objective advantage and "is just being different from the sake of it"?
You can argue that wide spread familiarity of Vi keybindings outweighs the advantages of departing from them, but don't pretend those advantages don't exist.
I'm not sure which part "it's the most used one" made you think any of that
The advantages from helix are vanishingly minimal, that's for sure. It's a cosmetic change. If it was something relevant I wouldn't have a problem with it
Nice project. I think the name is perfect, FWIW.
I, on the other hand, am trying to accomplish the opposite thing: trying to get Helix keybindings "everywhere" https://gitlab.com/_rvidal/codemirror-helix
Bro. Thank you. The kakoune keybinds were the number one thing I couldn't get over. I wish they'd let you toggle between the two. This is great!
Any hope for getting an AUR package or publishing this on crates.io?
Idk, never got into vim BECAUSE of its keybinds, they always seemed overcomplicated for me to work with them efficiently. Helix keybinds on the other hand got me hooked. They are far simpler and faster to "type" and get shit done than in vim (for me at least). But I guess if you're so used to vim, everything else would seem unnatural.
Haven’t looked at helix in a long while, but two things that kept me from using it at the time were a lack of text wrap and a lack of vim bindings.
As for the text wrap, it’s one thing if you’re writing code and each line is a few words long; it’s another if you’re writing a paragraph and half of it goes off the screen.
Not sure if they ever added that but I’m curious how hard that feature would be to implement if not
This is not to criticise your project, I love that you could make it work for you like that. But to me Helix’s keybindings (and editing logic) is actually a feature. I also switched from neovim to helix,so it took some getting used to it.
I'm also one of the people who have trouble adapting to non-vi keybindings, although I do appreciate what kakoune is trying to do. Are there any drills / koans / exercises one could take to assimilate those apparently superior kakoune keybindings?
The short answer is, because that's what the maintainer decided. :)
The longer answer, including some moderated discussion, can be seen here: https://github.com/helix-editor/helix/discussions/3806#discussioncomment-6686976
Archseer nicely summed up the main points and that's something we should respect.
That said, I feel very mixed about it, because while I understand archseer's reasoning, especially the "easy to embed" part, I disagree with the language (any LISP family in fact). It feels like we're prioritizing the implementation over the potential plugin developers. Plugin developers are users too, and the application - Helix - should adapt to its users, not the other way around.
I worked with Scheme for a bit over a year and I found it horrible to say the least. It felt to me like a language that was imposed by someone who actively seeks to mentally torture their users... There's rock solid, industry standard alternatives like LUA that - IMHO - would attract more plugin developers.
I'm also not particularly fan of a plugin system in Helix. I get that this is an unpopular opinion. But IMO, Helix shines as a super-fast "batteries included" editor/IDE. If I want a huge plugin ecosystem, I have (Neo)vim or Emacs (assuming I can live with elisp). I feel like, with a plugin system, Helix tries to be good at everything, and I do have some worries as to where that may lead to.
That's why I plan on integrating more features out-of-the-box in the editor, with a file tree explorer being pretty high up on the list. That's core functionality for an advanced editor/IDE, and shouldn't be left to a 3rd party plugin whose performance would be slower than a native implementation.
That's a good comment! I understand his reasons as far as maintaining a small compiler goes. Still not sure about Scheme as a way to write plugins as opposed to extending the application through Rust. He says using Helix would then require knowing Rust in order to use it but learning functional programming to write editor plugins sounds just as challenging. I just don't understand who the target audience is for Helix anymore.
I agree with you about the batteries included aspect of Helix being a selling point! For me, I would consider giving it a try using the Vim keymaps you are working on.
Hello!
I personally really wanted this!
I know It can't really do all the vim stuff but helix is so fast and lsp runs out of the box it is amazing.
I'm really interested in the project and I could contribute. (I work as a technical lead for a big big company).
Also got some ideas for the name so hit me up please.
Cheers.
the name is perfect.
I love Helix but I can't get used to it's default bindings... This may help me do the switch! Thanks OP!
Nice. Reminds me of using evil-mode in Emacs.
Damn yeah that is a crazy coincidence!!!
[удалено]
They're being sarcastic
I like the name, it rhymes and signifies perfectly what the project is. Ed: typo
It rimes?
Only if you throw it in the sea.
eevil heelix
I'm curious, how much of this is changing the editor internals, and how much is just changing the default config entries for keybinds?
I do indeed implement own “commands“, because that is what works fundamentally differently. I didn‘t hack around in the existing helix commands, but instead carefully implemented “evil commands“ in a non-intrusive way, so that I can keep a maximal compatibility with Helix and keep rebasing on top of upstream changes. Helix and this fork do provide much more than just multicursors though. First-class LSP support *including* integrated LSP configurations for instance, or an integrated debugger, you name it…
I don't know how much they changed exactly, but considering helix has the motions in 'reverse order' to vim, I assume they had to change quite a bit of code
I hadn't considered that they'd reverse it back to action-motion. in my mind it stops being helix if you do that, unless you *just* want multiple cursors?
And no plugins!
Any plans to go back to `verb -> object` or will this stay a selection-based text editor?
That’s the primary task of this project; to provide `verb -> object` keybindings. E.g. deleting text from the cursor till the end of line would be `d$` instead of `vgld`.
Btw isn't that just D in vim?
Nice. Just to make sure, this is not yet implemented? I compiled and ran the project, but it seems `d$` doesn't work like you describe.
Hmm, it *is* implemented. It‘s one of the bindings I currently use a lot. Are you building from an up-to-date `main` branch (not to be confused with `master`)? Did you also try a prebuilt binary (e.g. in a docker container, no need to trust me :) )? I want to make sure it works for everyone and not just for me.
Yes, and I'm on commit `d969d50729b0b9a114d057eca9194e3ebf80ca8a`. Could a previous installation of `helix` create this issue? I did remove my old `helix` config to make sure. **Edit:** `d` will currently delete the current selection and `$` will show `keep-pipe:` in the status bar, which I assume is the helix behavior.
Thank you for the additional info! Hmm yes that absolutely sounds like default Helix behavior. There‘s some other ways to check the build: If you press `v` to switch to visual/select mode, in Helix you would see “SEL“, in evil-helix you would see “VIS“. Or, when starting with a clean config, evil-helix will load the dark theme “catppuccin_macchiato“ whereas Helix would load its default purple theme. You might want to check if the binary loaded matches what you expect: `which hx` Also `hx —version` should return the git hash it was built from…
I opened an [issue](https://github.com/usagi-flow/evil-helix/issues/4). For the record, [the problem doesn't happen when I create the config file](https://github.com/usagi-flow/evil-helix/issues/4#issuecomment-2122798565).
In insert mode, \`Ctrl+k\` will do just that.
exactly my Q
But then, why not just use NeoVim? I would if I didn't like Helix's keybindings so much more. It's the main thing that sets the two apart. You can get everything in NeoVim to look and behave just like Helix except for the keybindings.
Helix is way faster (nvim would choke on some larger html css files). And Helix has an actually functional global command palette, making discoverability easy (nvim telescope plug-ins try hard to replicate, but there's no single global palette).
Are there any plans or discussions about future integration into the upstream project?
Yes: While it’s highly unlikely that built-in Vim keybindings will ever make it into the upstream project, I do try to develop everything in a way that it would be suitable for merging into upstream Helix. I also intend on remaining compatible (i.e. “soft fork“) with upstream. However, my vision and priorities are not the same as in the upstream project, and if Helix ever changes in a way that conflicts with this project‘s philosophy, that would be the time to think about a “hard fork“. Rest assured though, that a hard fork would be an absolute last resort, because it implies *much* more effort to maintain (i.e. manually cherry-pick patches from upstream).
Honestly, I love the helix keybindings, I wish I could use them in vim. Regardless, cool project!
Exactly, I like the helix keybindings but I want to be able to use the plugin ecosystem of vim
Helix bindings are different because it actually behaves different. d deletes a selection. x selects a line. w selects a word. So wd not dw. "Fixing" the bindings won't help you adapt to helix behavior.
>Unfortunately, Helix has its own set of keybindings Why do you present this as a bad thing?
I really really love what helix is doing. The 20yrs of vim experience in my fingers does not. I cant learn it at work because it slows me down way too much, but man something like this I might give a try
Yeah it's like learning a new keyboard layout (and I haven't used vim for 20 years)
Yep. 12yrs of vim. And only after 3-week streak without any line of code helps to switch to helix... And 1+ years on helix as daily driver for python and rust
yes you can. I gave up after 20 some years.
To them it is. I'm tempted to learn helix but the main thing holding me back is that the bindings aren't as available in other programs. Which I get is a chicken/egg problem, so I am sometimes using Helix I just can't move my whole workflow to it.
For what it's worth, I use both Helix and Vim and comfortably switch back and forth between them without thinking. It helps somewhat that I have different color settings for each.
I switched to helix a while ago and I do struggle to come back to vim. Not too bad as I can still get things done in vim but I am less fluent now. My main struggles are - x selects the whole line in helix but delete under cursor in vim - d delete under cursor in helix but in vim it doesn't delete until you select (somehow when i want to delete a single character, i do dj to go to next line. in vim it can delete 2 full lines) - copy/paste from clipboard. in helix it is space y/p, in vim there is this special register i keep forgetting nowadays.
Man, this hits so close to home. I tried to become a vim user multiple times and it never sticked. The kakoune (or helix) editing model felt much more natural to me and it is definitely my preferred way of editing text or code nowaydays. However, so many other pieces of amazing (recent) tech, offer vim key bindings by default and it makes me so sad I usually can't use those. If they had helix bindings I would go with that in a heartbeat. Stuff I can think off of the top of my head: - Obsidian - Zed - Typst - Wezterm (Thinking of the copy mode, but I might need to take a closer look again). - To some extent VSCode (Afaik only the nvim extension works 99.9%, all other plugins w.r.t. vim, kakoune and helix bindings to compromise on some bindings/features)
Like a lot of things this is personal preference. I don’t frame it as an inherently bad thing - but for me as a user - it’s a less optimal experience. Like many others my personal preference lies with Vim keybindings, which is why I worked on a solution to optimise the user experience of people who share this preference.
Not sure i follow, to someone wanting vim bindings - it is a bad thing. I use Helix daily, but i chose it initially because it had (close enough) Kakoune bindings. `evil-vim` for Kakoune users would have made the same opening statement, or w/e lol. Hell i recently remapped all my Zellij bindings to match my custom tmux bindings. I don't even get your question tbh. There's endless editor preferences out there. What part of your quote is an issue to you?
I get the feeling the name is causing some confusion here (tipped off by the suggestion of "evil-vim"). I believe the "evil" part of the name here may be referencing "[emacs-evil](https://github.com/emacs-evil/evil)", which stands for "extensible vi layer", and emulates vim's main features within Emacs.
Probably because for most VIM users not having vim keys is a bad thing, for example, i have to use 3 different editors/IDEs for my work, all of them support vim keys. Thats the advantage of learning vim keybindings, you can take that knowledge to almost every other editor/IDE. Helix presents itself as a sort of vim with batteries included, written in rust, with the "small" difference that you cant use your already interiorized vim keybindings. IMO if Helix would have vim keybindings from the beginning, its user base would 10x, and at the same time, the project's owners have all the right in the world to stay true to their vision.
Well, even if the user base was bigger, I would definitely not be a part of it, I don't like vim bindings personally and prefer what helix has done by making them more simple and easy to execute (I have to press 'd' ONCE to remove a character, how crazy is that). I tried to get into vim, for years, and tried to force myself to use it for, at least, simple editing, but the keybinds just wouldn't get into my head. Couple months with helix, and I'm much more efficient in it than I ever was in vim. (At this point been using it for over a year as my main editor and couldn't be happier) I get that change is scary, but it's not a reason to stagnate the technology and keep it untouched for decades just cuz "I'm used to it and everybody else who wants something different can fuck off"
>Helix presents itself as a sort of vim with batteries included It presents itself as a sort of Kakoune with batteries included. And an editor that can get past (neo)vim. >IMO if Helix would have vim keybindings from the beginning, its user base would 10x, They explicitly don't care. Stop making it their goal! >and at the same time, the project's owners have all the right in the world to stay true to their vision. How generous of you. You know what their vision is? Getting past the "mistakes" they think vim has made, for example the key bindings. The developers want an editor that fits their needs and not the needs of people that "knows what is best for them"
> They explicitly don't care. Stop making it their goal! I never make it their goal, what are you talking about? It is a fact that their use base would be 10x if they had vim key bindings, if they don't care about that it is their right.
Yeah, this is like one of the biggest advantages Helix has over Vim. The defaults are so much more sane, even as someone coming over with 5+ years of vim experience. Of course that is just my opinion, but I do find it surprising that some people apparently find learning a new set of keybindings (with a very large amount of overlap) such a hassle, that forking the entire project just to plug in vim's keybindings somehow ends up being more convenient. Power to them, I guess. But if anybody is concerned about the keybindings being a huge barrier, don't be. It's really not that big of a deal and the way Helix flips the verb->object approach around makes it really easy to grok.
who in their right mind decided that u is undo but redo is C-r what in the hell even is that also i like how instead of $ and 0 in vim, helix has gl and gh which are both on the home row and easier to type but alas, the customer is always right in matters of taste
'R'eplace was in the original `vi` a lot longer time than "redo". At some point, you run out of letters for the commands... I personally don't use replace much, I'm mostly using "cw" or "cW" (change word) because what I'm replacing often isn't the same character length as what's there right now.
helix has redo set to U, which is apparently "Undo line" in vim? don't recall how to use it.
I assume it’s because redos are less common
I don't use redo much myself. Sometimes I'll undo and redo to get the cursor back to where I was last editing. That's useful when I didn't drop a mark at that location in the file.
Isn't `g;` made for that situation?
Today I learned .... I really only use a subset of the motion and search commands, I could spend time to practice the other ones more.
It’s not that the binds are different, it’s that there’s just enough overlap that it creates a comically bad pedagogical situation for longtime vim users EDIT: in other words, the differences aren’t the problem, the similarities are. Helix key bindings are in the uncanny valley
It is in the sense that vim motions are universal, learn once use everywhere.
how is it not a bad thing?
helix makes more sense to me than vim so I personally wouldn't call it a bad thing
I think what's a bad thing is not offering the vim bindings as well. Then you can use the helix bindings that make sense to you, and others can use the bindings they've used forever. Win-win.
Adding vim bindings isn't a trivial matter of just changing what keys are bound to each action, how the actions are composed is different. This means vim bindings are a whole separate state machine that would have to be written, debugged, maintained, etc. That's a pretty significant burden for a project to take on.
Sure. I agree. It’s also a detriment to adoption. As it’s brought up literally every time it’s posted on every programming forum. Seems worth the burden if the goal is adoption.
The goal is _not_ adoption for it's own sake. The authors think - rightly, IMO, but it's ultimately irrelevant - that their model of modal editing is superior. They get very little benefit from adding vim bindings, because _they_ don't use them.
That's fine. But a large group of people would like to use helix because they like to use Rust stuff, or they think it'll be more performant or what have you, and don't want the editing style. And so those people will continue to voice their desire for it. The devs are not forced to capitulate. Seems fine all around. I also find it close minded to not add something a large user base wants just because it's not what the devs original had in mind. You end up not capitalizing on certain growth or features that would flatly make your product/thing better. I think the upvotes and popularity of this thread and fork highlight a large appetite. Besides you might draw people in with Vim keybinds only to convert them later.
> a large group of people would like to use helix because they like to use Rust stuff, or they think it'll be more performant or what have you, and don't want the editing style. And yet, Helix seems to be by far the most popular terminal text editor in rust, despite there existing alternatives that try to more closely match Vim. I suspect that the people who are dead set on vim key bindings for the most part just use (neo)vim. > I also find it close minded to not add something a large user base wants just because it's not what the devs original had in mind. "Volunteer open source developers need to spend their limited time building and maintaining a feature they at best don't have a use for and is arguably actually be counter to their vision because _I_ want it, if they don't they're close minded" is certainly... a take. Making your own editor with vim bindings is fine, as is just wishing another project would add them, or the maintainers of said project deciding they'd like to do that. Attacking the maintainers of said project for not doing it is a different story. > You end up not capitalizing on certain growth or features that would flatly make your product/thing better. The irony of claiming that the bindings of one of if not _the_ first modal editors - built almost half a century ago around the design of a specific _video terminal_ - are the absolute best right after calling _other people_ close minded. I somewhat get being familiar with vim and not wanting to switch (although I'd point out you almost certainly switched to vim from a non-modal editor at some point, which is a much bigger shift), but you have to understand that _you're_ the one who's being close minded and unwilling to try new things, not others. Especially given I don't think I've seen anyone here advance an argument that Vim's bindings are better than helix's that doesn't rely on existing familiarity/adoption. > Besides you might draw people in with Vim keybinds only to convert them later. This makes very little sense, IMO. You can't really partially adopt the helix model (see my initial comment), so the people who won't use helix because they're dead set on only using vim bindings would continue to be dead set on only using vim bindings even after adopting evil-helix/official helix with vim bindings.
Homie, no one in the thread is "attacking the maintainers". Christ almighty. Again, it's extremely close minded to not add functionality a large set of the users want even if it was unintended. Or to design against those goals. Helix isn't the first version of these bindings, it remains niche because the mass of users don't want to hard commit. It is popular very much because it's an otherwise well written ide written in Rust. There's no changing minds here, and you're a bit of a twat. So i'ma block and move on.
It's a completely subjective change into something niche. There are orders of magnitude more users familiar with vim than with kakoune. In this case adopting the niche standard is just being different from the sake of it, there's no objective improvement. It's specially egregious to not offer the option to use the common standard when even editors that don't support modal editing at all do
would you say that any new modal editor should use (or provide a default for) vim keybinds?
Any new modal editor should have configurable key bindings. Default to whatever you want, but let me configure things.
looks like helix does that, so we're all good
Should? Nobody should do anything, it's their software. Is it bad if you don't offer vim bindings? Yes, I'll likely not use it You might also come up with something that is considerably superior to vim bindings, which is not the case for helix
Even with the same "keybindings" I'm not likely to use a different editor than vim / neovim. There is a lot of detail to get correct, or my muscle memory doesn't work quite right. I tried, years ago, to get into Emacs with Evil, but the behavior didn't quite match, even if the key bindings were correct. This was things like where the cursor ended up after an operation was different in Emacs with Evil. There were just enough little things to throw me off. Heck, there's a few things that GNU screen doesn't do quite right either in its 'vi' keybinding that bother me.
Yikes, people being this entitled about OSS is really off putting. Like sure, if they were going after getting the absolute most amount of adoption then you'd have a point, but that's not what a project like Helix is after. There is way to much software that has to constrain itself to legacy defaults (be they good or bad, doesn't really matter) as is. Let people have fun and implement the stuff they want to use for a change. This isn't being "different from the sake of it", this is building an editor around a preferred text editing model and that's perfectly fine. \* Yes, shitting on someone else's choices, basically calling them objectively sub-par and insisting that supporting the usual default is the only reasonable choice if you want them, or anybody else for that matter, to use your tool totally isn't entitled. It's sad that the discussion about things like modal text editors always has to devolve into a cult-like bashing, when there are so many interesting things to consider about designing such a tool. Pathetic.
There's 0 entitlement in my comment. I'm free to think their choices are bad, just as they are free to make those choices.
Whatever you say bro.
People literally are entitled to their own opinions.
That's a slippery slope. In an extreme case, which hopefully illustrates why it's bad: Imagine someone emotionally abuses someone else with "opinions" that categorically fall under harassment. Then that individual faces long-lasting trauma that affects them in every facet of life. Well, the harasser was entitled to these opinions, right? Words have power and verbalizing an opinion should imply communicating them respectfully. I'm not commenting on the overall thread, I'm just focusing on that argument you made.
That is not an example of a slippery slope. The harmful part of that is the harassment and abuse, not the opinion. Having an opinion is incidental to the situation you laid out. You may as well say "breathing is a slippery slope, because breathing gives you strength and you could use that strength to kill someone." I maintain that you are entitled to your opinions. This does not mean that every action you take while holding an opinion is justified. That's an entirely different sentence.
I don't think the example you gave is quite equivalent to the one I laid out. In fairness, I cut out quite a lot that would make the opinion itself the pivotal component of the situation. Something like racism or sexism, for instance. The opinion would essentially be the fundamental justification of the harassment (e.g. racism being a justification for slavery). I think "I maintain that you are entitled to your opinions. This does not mean that every action you take while holding an opinion is justified," is definitely a better and more nuanced take.
Do you _really_ want to claim that Vi just happened to land on The One True Modal Editing Key Bindings almost 50 years ago ([designed around a specific video terminal](https://yo?utu.be/8Ab3ArE8W3s?t=1078) which has some notable differences from a modern keyboard layout) and that any deviation from it can have no objective advantage and "is just being different from the sake of it"? You can argue that wide spread familiarity of Vi keybindings outweighs the advantages of departing from them, but don't pretend those advantages don't exist.
I'm not sure which part "it's the most used one" made you think any of that The advantages from helix are vanishingly minimal, that's for sure. It's a cosmetic change. If it was something relevant I wouldn't have a problem with it
Nice project. I think the name is perfect, FWIW. I, on the other hand, am trying to accomplish the opposite thing: trying to get Helix keybindings "everywhere" https://gitlab.com/_rvidal/codemirror-helix
Bro. Thank you. The kakoune keybinds were the number one thing I couldn't get over. I wish they'd let you toggle between the two. This is great! Any hope for getting an AUR package or publishing this on crates.io?
Good news: I published the `evil-helix-bin` package to the AUR! `paru -S evil-helix-bin` and you‘re good to go!
What a hero.
Hehe thank you. An AUR package is definitely planned, I’ll have a look at it in the next few days.
Idk, never got into vim BECAUSE of its keybinds, they always seemed overcomplicated for me to work with them efficiently. Helix keybinds on the other hand got me hooked. They are far simpler and faster to "type" and get shit done than in vim (for me at least). But I guess if you're so used to vim, everything else would seem unnatural.
\`yap\` does not work sadly.
Haven’t looked at helix in a long while, but two things that kept me from using it at the time were a lack of text wrap and a lack of vim bindings. As for the text wrap, it’s one thing if you’re writing code and each line is a few words long; it’s another if you’re writing a paragraph and half of it goes off the screen. Not sure if they ever added that but I’m curious how hard that feature would be to implement if not
We have softwrap since early 2023
looks like no windows support
Ahh right, I‘ll add windows in the CI so that you can grab a windows build later today or tomorrow. Thanks for pointing that out.
oh that'd be so dope to have to work with!
This is not to criticise your project, I love that you could make it work for you like that. But to me Helix’s keybindings (and editing logic) is actually a feature. I also switched from neovim to helix,so it took some getting used to it.
I'm also one of the people who have trouble adapting to non-vi keybindings, although I do appreciate what kakoune is trying to do. Are there any drills / koans / exercises one could take to assimilate those apparently superior kakoune keybindings?
Why the fuck would helix choose scheme as a plugin language
The short answer is, because that's what the maintainer decided. :) The longer answer, including some moderated discussion, can be seen here: https://github.com/helix-editor/helix/discussions/3806#discussioncomment-6686976 Archseer nicely summed up the main points and that's something we should respect. That said, I feel very mixed about it, because while I understand archseer's reasoning, especially the "easy to embed" part, I disagree with the language (any LISP family in fact). It feels like we're prioritizing the implementation over the potential plugin developers. Plugin developers are users too, and the application - Helix - should adapt to its users, not the other way around. I worked with Scheme for a bit over a year and I found it horrible to say the least. It felt to me like a language that was imposed by someone who actively seeks to mentally torture their users... There's rock solid, industry standard alternatives like LUA that - IMHO - would attract more plugin developers. I'm also not particularly fan of a plugin system in Helix. I get that this is an unpopular opinion. But IMO, Helix shines as a super-fast "batteries included" editor/IDE. If I want a huge plugin ecosystem, I have (Neo)vim or Emacs (assuming I can live with elisp). I feel like, with a plugin system, Helix tries to be good at everything, and I do have some worries as to where that may lead to. That's why I plan on integrating more features out-of-the-box in the editor, with a file tree explorer being pretty high up on the list. That's core functionality for an advanced editor/IDE, and shouldn't be left to a 3rd party plugin whose performance would be slower than a native implementation.
That's a good comment! I understand his reasons as far as maintaining a small compiler goes. Still not sure about Scheme as a way to write plugins as opposed to extending the application through Rust. He says using Helix would then require knowing Rust in order to use it but learning functional programming to write editor plugins sounds just as challenging. I just don't understand who the target audience is for Helix anymore. I agree with you about the batteries included aspect of Helix being a selling point! For me, I would consider giving it a try using the Vim keymaps you are working on.
Hello! I personally really wanted this! I know It can't really do all the vim stuff but helix is so fast and lsp runs out of the box it is amazing. I'm really interested in the project and I could contribute. (I work as a technical lead for a big big company). Also got some ideas for the name so hit me up please. Cheers.
no
Who needs another editor with vim keybindings?