Helix 23.03(helix-editor.com)
helix-editor.com
Helix 23.03
https://helix-editor.com/news/release-23-03-highlights/
95 comments
> but the almost-like-vim-but-not-really key bindings are a deal breaker. I just can't make the switch.
> If Helix were completely different in this regard, like Emacs is, I could handle--and I know because I use both vim and Emacs regularly pretty fluently. But Helix is way too close to the vim keybindings to discern it from a memory muscle perspective.
You might want to reconsider trying a bit to see if you think it's worth it. I ended up learning vim deeply, emacs deeply, and meow (most similar to Helix being almost somewhat vim-like but different) somewhat deeply. I thought before each one that I couln't possibly learn the other, especially the similar one.
> If Helix were completely different in this regard, like Emacs is, I could handle--and I know because I use both vim and Emacs regularly pretty fluently. But Helix is way too close to the vim keybindings to discern it from a memory muscle perspective.
You might want to reconsider trying a bit to see if you think it's worth it. I ended up learning vim deeply, emacs deeply, and meow (most similar to Helix being almost somewhat vim-like but different) somewhat deeply. I thought before each one that I couln't possibly learn the other, especially the similar one.
Same. Helix made me realized vim is a walled garden and I willingly helped buidling those walls.
The thing that worked for me: Don't try to be focused on coding efficiency when learning Helix. I've used Vim for well over a decade and I'm very fluent in it. But when I decided to learn to use Helix, I shifted my mindset to a Notepad.exe-like experience. A lot more scrolling, a lot less jumping. And then I started prioritizing the most needed shortcuts one by one. Helix also has a nice command search that is available via "space ?" that helped me find the commands and key combos that I wanted to learn.
I also went through the :tutor several times. Unfortunately, it doesn't cover typical coding activities, but it does a good job at explaining the editing model.
The features of Helix are also a lot more discoverable than in Vim, because you get these nice menus when you press one of <space> g m v
I also went through the :tutor several times. Unfortunately, it doesn't cover typical coding activities, but it does a good job at explaining the editing model.
The features of Helix are also a lot more discoverable than in Vim, because you get these nice menus when you press one of <space> g m v
I don't think this is such a big deal. Yeah, you'd spent a couple of days cursing at your fingers. The bindings are an improvement and they require an investment, like all things worthwhile in life.
"not a big deal" and "[Helix] bindings are an improvement" are rather subjective in this case I'm afraid
I've been using helix a while, and compared to vim, the bindings are not as time-efficient as vim bindings are, but I just can never get LSP to work quite right at neovim, so I use helix for code
I switch between helix and evil bindings on emacs.
(To the extent that it matters, I also mostly use the Dvorak keyboard layout if I can, but can still use QWERTY).
The helix keymap overall seems very well thought out. The built-in multicursor functionality also seems very expressive/powerful.
I will sometimes think I'm driving helix when in emacs (or vice versa), but overall don't see that as a major issue.
It did take a bit of time to learn how to do some things in Helix which I'm otherwise comfortable doing with vim motions.
(To the extent that it matters, I also mostly use the Dvorak keyboard layout if I can, but can still use QWERTY).
The helix keymap overall seems very well thought out. The built-in multicursor functionality also seems very expressive/powerful.
I will sometimes think I'm driving helix when in emacs (or vice versa), but overall don't see that as a major issue.
It did take a bit of time to learn how to do some things in Helix which I'm otherwise comfortable doing with vim motions.
Same here. Not that having a different editing modal is a bad thing, but vim model is proven so well that I'm not sure why any new editor would choose to die on this hill and not offer vim keybindings for many more audiences.
I find this baffling. Who is even going to try a new modal editor if they are not already a vim (bindings) user?
Users of kakoune, like myself. What I don't understand is why this is seem as such a big deal. You spend most of your workday in your editor of choice. It's not that big a deal to spend a day or two getting used to the (IMO better) keybindings. I still up using vim for some things, like vimdiff, and I don't find it difficult to move between the two.
Then again, I also use Dvorak, so maybe I'm just used to changing between layouts.
Oh thank you for the pointer. I'm exactly at your point where I tried it a few times, but >30 years of VIM keybindings in my fingers make it too painful to switch and stick to it. I'll try those.
BTW: nearly 500 stars for this simple config, that should send a clear message to Helix devs.
BTW: nearly 500 stars for this simple config, that should send a clear message to Helix devs.
Has any vim-like ever not had the complaint that it was insufficiently vim so as to be impossible to switch to?
I suspect the helix devs knew what they were doing when they deviated from the vim gospel.
One does not convert the users of vim; text editors are like science — it advances one death at a time.
I suspect the helix devs knew what they were doing when they deviated from the vim gospel.
One does not convert the users of vim; text editors are like science — it advances one death at a time.
Same here. The vim muscle memory is too strong.
I've been using Helix for a few months now and it's fantastic. It was a bit rough at the very beginning because I was a die hard Vim user, but after a few days of struggling and paying close attention to the keys I'm pressing, I slowly adjusted and now I'm pretty comfortable.
The one thing I really appreciate about Helix is that all of the features I want are already built in - I don't have to install any plugins nor configure anything. The fact that Helix feels much more responsive than Neovim is just a bonus. Here's my complete ~/.config/helix/config.toml:
The one thing I really appreciate about Helix is that all of the features I want are already built in - I don't have to install any plugins nor configure anything. The fact that Helix feels much more responsive than Neovim is just a bonus. Here's my complete ~/.config/helix/config.toml:
theme = "nightfox"
[editor]
true-color = true
auto-save = true
line-number = "relative"
[keys.insert]
"C-backspace" = ["normal_mode", ":w"]
[keys.normal]
"C-j" = ["goto_next_paragraph"]
"C-k" = ["goto_prev_paragraph"]
"C-backspace" = ":w"
"C-h" = "jump_view_left"
"C-l" = "jump_view_right"
[keys.normal.space]
"space" = "goto_last_accessed_file"
"H" = ":toggle lsp.display-inlay-hints"
[keys.select]
"C-j" = ["goto_next_paragraph"]
"C-k" = ["goto_prev_paragraph"]
Using Helix has been a really positive experience, thanks to everyone contributing to this release.
I've been using Helix 22.12 release for a few months, it's been really stable. The previous release had some stability issues (crashes due to panic, no data loss experienced) but I've had none of that for the past three-four months.
I have written about 15 kLOC of Rust code using Helix. LSP and tree-sitter are really nice built-in features. I've also occasionally used it to browse C and C++ codebases, features like go-to-definition work quite well without even building the source (which you need for compile-commands.json to get CFLAGS etc working).
Looking forward to trying out the new release.
I've been using Helix 22.12 release for a few months, it's been really stable. The previous release had some stability issues (crashes due to panic, no data loss experienced) but I've had none of that for the past three-four months.
I have written about 15 kLOC of Rust code using Helix. LSP and tree-sitter are really nice built-in features. I've also occasionally used it to browse C and C++ codebases, features like go-to-definition work quite well without even building the source (which you need for compile-commands.json to get CFLAGS etc working).
Looking forward to trying out the new release.
I was using Helix for some time, however what stopped me at some point was lack of persistent state in the editor. Helix is a powerful IDE, so you start to use it as an IDE, work on a project and close the editor at some point. How do you get the last opened files when you start the editor again?
Right now there is now way to do that, because there is no consensus on how the state should be stored. That's a worse developer experience, compared with vim for instance.
Another story is that some people pointed out a missing feature - moving lines or blocks of text up and down, as more advanced IDEs do. I volunteered to implement this feature, however I'm getting impression that the community is a bit puristic when it comes to features like that, based on feedback I get.
One argument is that this feature will make the code too complex to maintain (write your own bindings if you want that). Another that have been brought up is that acting on selected lines, instead of characters violates the rule act-by-selection (that is, modify only selected characters in the buffer, similarly how visual mode in vim works).
I acknowledge these arguments, yet I got a feeling that the community is a bit too perfectionist.
Right now there is now way to do that, because there is no consensus on how the state should be stored. That's a worse developer experience, compared with vim for instance.
Another story is that some people pointed out a missing feature - moving lines or blocks of text up and down, as more advanced IDEs do. I volunteered to implement this feature, however I'm getting impression that the community is a bit puristic when it comes to features like that, based on feedback I get.
One argument is that this feature will make the code too complex to maintain (write your own bindings if you want that). Another that have been brought up is that acting on selected lines, instead of characters violates the rule act-by-selection (that is, modify only selected characters in the buffer, similarly how visual mode in vim works).
I acknowledge these arguments, yet I got a feeling that the community is a bit too perfectionist.
Not really what you are asking for, I know, but: run Helix in tmux and leave it running there. Sure, it's not going to survive computer reboots, but your state will survive almost anything else (in particular, closing terminal windows or logging out of a remote server if that's where you are working).
> Another story is that some people pointed out a missing feature - moving lines or blocks of text up and down, as more advanced IDEs do. I volunteered to implement this feature, however I'm getting impression that the community is a bit puristic when it comes to features like that, based on feedback I get.
Wait, what does this add? I feel like in Helix I would just select a bunch of lines (say, via treesitter or the x command), and then I'd delete them, and paste them somewhere else. Could you elaborate what the difference is between this and 'moving lines or blocks of text up and down'?
Wait, what does this add? I feel like in Helix I would just select a bunch of lines (say, via treesitter or the x command), and then I'd delete them, and paste them somewhere else. Could you elaborate what the difference is between this and 'moving lines or blocks of text up and down'?
Yeah, you can use registers or the system clipboard, however this takes more actions and puts stuff into your clipboard history. Maybe it's just my way of working, but I move lines above or below when reorganizing lists in markdown or other basic text operations. For me it's as useful IDE feature as multiple cursors and in fact I often use them together.
All the major IDEs like sublime/jetbrains/vscode have both of these functionalities.
All the major IDEs like sublime/jetbrains/vscode have both of these functionalities.
Perhaps you can try Ctrl+z to background the editor, do whatever you need to, and then run 'fg' (foreground I think) to get back into it. It should just stay paused in the background for you.
Inlay hints look great. Is there a keymap configuration or a motion to toggle them on temporarily and turn off when a key is released? In VSCode you can do this so that holding 'alt+shift' pops up inlays, but releasing that combo makes them go away. Best of both worlds IMO, since type signature inlays often add an unnecessary amount of clutter in some languages.
Either way, love Helix. It's now my quick editor of choice; I really like the Kakoune-style motions.
Either way, love Helix. It's now my quick editor of choice; I really like the Kakoune-style motions.
I'm not sure if you can show them only when you're holding a key combination, but you can toggle them.
[keys.normal.space]
"H" = ":toggle lsp.display-inlay-hints"Thanks! This is probably a reasonable substitute; I'm not too sure if "hold to activate/release to deactivate" is something to add to the input model or something the developers are interested in.
> I really like the Kakoune-style motions.
Kakoune has often seemed like a platonic ideal to me. Of course, my mind doesn't agree so much about the visual by default stuff much of the time. Maybe I didn't use Kakoune long enough.
I gave it a try for a while, but had to go back to emacs ecosystem.
This led me to inevitably tryout https://github.com/meow-edit/meow which I think is the best combination of fast, stable, well-integrated, similar to the kakoune model.
Kakoune has often seemed like a platonic ideal to me. Of course, my mind doesn't agree so much about the visual by default stuff much of the time. Maybe I didn't use Kakoune long enough.
I gave it a try for a while, but had to go back to emacs ecosystem.
This led me to inevitably tryout https://github.com/meow-edit/meow which I think is the best combination of fast, stable, well-integrated, similar to the kakoune model.
I feel the same way. I love the ability to check them when I need them, but 90% of the time, I'd rather they were invisible.
I fell in love with Helix a few months ago and every single release is improving so much. I stopped using Microsoft visual studio code and vim, and I am not missing them at all.
When I tried Helix I was impressed by what I saw but had two problems with it:
1) I am used to Vim motions and Helix was just slightly different which was confusing.
2) No plugins. I have my Nvim heavily customized with many plugins and would not want to miss their functionality. This cannot all be provided by the core editor so I guess it won't be an option for me as long as they don't support user plugins.
1) I am used to Vim motions and Helix was just slightly different which was confusing.
2) No plugins. I have my Nvim heavily customized with many plugins and would not want to miss their functionality. This cannot all be provided by the core editor so I guess it won't be an option for me as long as they don't support user plugins.
The ability to use plugins is no quality in itself. Even if Helix would support plugins tomorrow, it would not magically mean you could use the same (or equal) plugins from your vim experience – someone needs to write them. You can argue that the Helix Project is in its early stages but many of the features you get by crafting your vim config are running out of the box in Helix now.
There will very likely be a time when Plugins are supported, but this time is not now. I like the approach to make first class integrated functionality rather than the mess we currently have in vim. Helix aims to have an out of the box experience that would take you hours or even days if you are fresh to vim. If you need functionality on top of it, plugins will come into play. There is a reason why astrovim, spacevim etc. are popular, people don't want to spend to much time configuring the most basics that everyone is expecting today.
So if Helix does most of the things you need today i would encourage you to try it out and if it does not have a feature that you really need, plugins wouldn't help much either because somebody needs to write it in the first place and by the current userbase its very unlikely. It seems that most of the people are just gathering around the main project and make PR's directly which somewhat guarantees a certain amount of quality.
There will very likely be a time when Plugins are supported, but this time is not now. I like the approach to make first class integrated functionality rather than the mess we currently have in vim. Helix aims to have an out of the box experience that would take you hours or even days if you are fresh to vim. If you need functionality on top of it, plugins will come into play. There is a reason why astrovim, spacevim etc. are popular, people don't want to spend to much time configuring the most basics that everyone is expecting today.
So if Helix does most of the things you need today i would encourage you to try it out and if it does not have a feature that you really need, plugins wouldn't help much either because somebody needs to write it in the first place and by the current userbase its very unlikely. It seems that most of the people are just gathering around the main project and make PR's directly which somewhat guarantees a certain amount of quality.
i agree that the plug-in chaos of vim and even emacs is exhausting. there’s so much churn, abandoned packages, and all this decision making that you have to do to get started. but at the same time you can’t expect to be able to build all the functionality into the editor. my workflow is greatly simplified by using tpopes vim-fugitive, it’s a fantastic git interface and it makes total sense to be part of an editor, and the lack of a similar thing in helix was the first reason i went back to vim after trying it out. if helix had plug-ins i’d probably be implementing that functionality myself! there are tons of other things like that. sure i could start building a git interface into helix itself but that both seems like a failure to separate concerns and a possible waste of time if it gets rejected by the maintainer etc.
> The ability to use plugins is no quality in itself
Theoretically no, practically, it is since someone is indeed more likely to extend the functionality via a plugin since the barrier is lower vs. adding the same thing to the core Also, for some things that someone could also be you
> Helix aims to have an out of the box experience that would take you hours or even days if you are fresh to vim.
Or you'd just copy the plugins/configs of someone who spend those days already, just like in those astro-space-packages you mentioned
Theoretically no, practically, it is since someone is indeed more likely to extend the functionality via a plugin since the barrier is lower vs. adding the same thing to the core Also, for some things that someone could also be you
> Helix aims to have an out of the box experience that would take you hours or even days if you are fresh to vim.
Or you'd just copy the plugins/configs of someone who spend those days already, just like in those astro-space-packages you mentioned
As far as I remember they stated that plugins won't be supported back when I tried it. No idea if that has changed.
Of course the plugins need to be written but my point is that they cannot be written at the time.
I understand and support the idea of Helix to be useful out of the box for many use cases. However for me the editor in its current form is not sufficient. As I already stated I use many (wonderful) plugins in Neovim. I could not justify going away from the status quo because it is pretty good. I have my setup configured so the ease to jump into is not really a valid argument for me and I suspect for many more Vim users.
Of course the plugins need to be written but my point is that they cannot be written at the time.
I understand and support the idea of Helix to be useful out of the box for many use cases. However for me the editor in its current form is not sufficient. As I already stated I use many (wonderful) plugins in Neovim. I could not justify going away from the status quo because it is pretty good. I have my setup configured so the ease to jump into is not really a valid argument for me and I suspect for many more Vim users.
I get what you're saying. The problem is that it is not really a matter of if plugins are supported or not. Helix will have plugins in the future. There is work being done towards it – mainly design work right now and they try to figure out how to approach this best, writing "demos" etc.
Plugin systems are not easy and they have a clear vision of how this should NOT end up working. In their current state putting in work into a Plugin-System does not make much sense (limited developer time that is better spend elsewhere) regarding their project goal.
As i said you can argue that the project is in its infancy and does not work for you because of that. But the main reason is not the support or lack of plugins. As i said, even if there was a plugin system you could argue that there are no plugins available for the things you want – ending up at exactly the same point you're today. Having a Plugin-System does not magically makes hundred of useful plugins appear out of nowhere.
Plugin systems are not easy and they have a clear vision of how this should NOT end up working. In their current state putting in work into a Plugin-System does not make much sense (limited developer time that is better spend elsewhere) regarding their project goal.
As i said you can argue that the project is in its infancy and does not work for you because of that. But the main reason is not the support or lack of plugins. As i said, even if there was a plugin system you could argue that there are no plugins available for the things you want – ending up at exactly the same point you're today. Having a Plugin-System does not magically makes hundred of useful plugins appear out of nowhere.
I don't think you get my point. In the end it's simple. Helix misses many features I want and that exist in (N)Vim. To support all these features you need plugins because they cannot be all maintained by core and everyone wants different features anyways.
As long as there is no way to extend the editor for me or for anyone else (aside from contributing to core), I am not interested in adopting it when I have another option that already does all of these things I want.
So yes you need plugins but for that you first need a plugin system. If that takes a while I am totally fine with it. I am all for good software. But why should I currently choose it over nvim?
As long as there is no way to extend the editor for me or for anyone else (aside from contributing to core), I am not interested in adopting it when I have another option that already does all of these things I want.
So yes you need plugins but for that you first need a plugin system. If that takes a while I am totally fine with it. I am all for good software. But why should I currently choose it over nvim?
Helix will get plugin support sometime, it's basically a matter of when not if.
Also; the scripting languages seems to become an S-Expression like lisp dialect.
What plugins do you miss in particular? I'd be curious how much of a delta it would be to getting to exactly what you needed.
A bit late but here is a list of plugins I could not live without:
- tpope/vim-fugitive
- samoshkin/vim-mergetool
- folke/zen-mode.nvim
- kevinhwang91/rnvimr
- nvim-telescope/telescope.nvim
There might be more I am forgetting.. and maybe something like telescope is already part of Helix. I will check Helix again in a year ;)
- tpope/vim-fugitive
- samoshkin/vim-mergetool
- folke/zen-mode.nvim
- kevinhwang91/rnvimr
- nvim-telescope/telescope.nvim
There might be more I am forgetting.. and maybe something like telescope is already part of Helix. I will check Helix again in a year ;)
Yes, just rewriting NeoVim in Rust would be a perfect solution.
Helix does not want to limit itself by what NeoVim is:
> If Neovim is the modern Vim, then Helix is post-modern.
/s
> If Neovim is the modern Vim, then Helix is post-modern.
/s
I would really like to try Helix and I'm even willing to learn it's keybindings, but I really need the ability to write plugins. Unfortunately, I work in a very "custom" environment where most modern tools have not made inroads yet. I rely on a couple of VIM plugins that I wrote myself to smooth out the edges and make development a bit nicer.
Ooh man had hoped multiple lsp servers in one file would have made it into this release. Ooh well its not such a biggy but i would have made my transition to hx from vs code more doable.
I want multiple lsp for html files with tailwindcss its more a thing because im still learning/memorizing tailwind stuff.
I want multiple lsp for html files with tailwindcss its more a thing because im still learning/memorizing tailwind stuff.
I wish Helix has vim-motions as an option. I don't want to break my muscle memory and le-learn everything just to use it in one editor (I use vim motions everywhere I can via plugins).
I think that helix doesn't have vim motions is a core part of its identity.
Or, rather, what's the difference betweeen "helix but with vim motions" and a bundled vim distribution?
I see Helix as a polished-out-of-the-box editor with kakoune-style motion, LSP, and tree-sitter (which supports enhanced motion). -- I think each of these things is a nice improvement over what came before; even if vim motions have long staying power.
Or, rather, what's the difference betweeen "helix but with vim motions" and a bundled vim distribution?
I see Helix as a polished-out-of-the-box editor with kakoune-style motion, LSP, and tree-sitter (which supports enhanced motion). -- I think each of these things is a nice improvement over what came before; even if vim motions have long staying power.
> Or, rather, what's the difference betweeen "helix but with vim motions" and a bundled vim distribution?
Vim/Neovim distribution as polished as Helix OOTB does not exist :D
Vim/Neovim distribution as polished as Helix OOTB does not exist :D
Up further, I wish things like vim were abstracted out so that they were hiding in the operating system level instead of on the application level. That way you could have vim emotions everywhere.
Something close to that is available for macOS.
https://vim.tonisives.com/
These are all great features, really. Everything I ask from a modern editor with language server support is just there. I also love modal text editors and use vi daily, EVERYWHERE (e.g. `set -o vi` on shell). But not on terminal GUI to write code, unless I am live debugging some shell script or python code on a server. I install vi extensions/plugins on all my editors. Using vscode over a terminal application has a lot advantages mostly due to being a very flexible graphical editor. You can move windows around, put them side by side, have fancy themes/colors/fonts. You can both use the keyboard AND the mouse when it is more convenient.
I still appreciate the effort, looking forward to more modal editors that are better suited to modern programming specific editing capabilities that are easy to learn and apply!
I still appreciate the effort, looking forward to more modal editors that are better suited to modern programming specific editing capabilities that are easy to learn and apply!
> You can move windows around, put them side by side
Why wouldn't you be able to do that with a CLI editor?
Why wouldn't you be able to do that with a CLI editor?
You can, but I'm not convinced that is as efficient. As someone who uses keyboard a lot, even for window management, I still reach for mouse whenever it is convenient. That's just one example. When you think about all the little information around (like in the status bar below), all the GUI elements like buttons. Just think about how IDE shows text at different sizes depending on the context, that alone should be a good argument against a CLI editor.
I vastly prefer the Vim way of action+selection to kakoune way of selection+action. Here is a short write-up (not mine) about why kakoune model is not that appealing [1].
So helix is not for me. My ideal editor would be a modern re-implementation of the Vim way of doing things, probably using different keys, probably thought-out more, probably more light-weight. But for some reason no editor wants to go there. They either break from Vim's model (kakoune, helix) or follow Vim along with all it's flaws (Neovim, Vis).
[1]: https://github.com/noctuid/dotfiles/blob/master/emacs/editin...
So helix is not for me. My ideal editor would be a modern re-implementation of the Vim way of doing things, probably using different keys, probably thought-out more, probably more light-weight. But for some reason no editor wants to go there. They either break from Vim's model (kakoune, helix) or follow Vim along with all it's flaws (Neovim, Vis).
[1]: https://github.com/noctuid/dotfiles/blob/master/emacs/editin...
Great write-up. Hate that I gotta press semicolon to drop the preceding selection that's a side-effect of my intent to merely navigate somewhere.
Neovim, though, if it wanted to distinguish itself to novices, should integrate which-key.nvim as well as the behavior in the annotation plugins you listed in the article to make things more obvious.
Vim's big fail is discoverability, not the editing model. You can run through past (Neo)vim threads on HN and consistently find 10+ year vets discovering some new behavior from the TFA of the thread. Perhaps some sort of predictive ChatGPT-based solution would expedite that effort since Vim has a lot of behavior to surface from its manuals. There's :helpgrep yes, but a novice still needs to know what to do ask.
This is why I'm a big fan of efforts like Fish, cause it does a great job surfacing CLI tooling behavior OOB just by pressing tab and navigating for what you want, with descriptions, in place
Neovim, though, if it wanted to distinguish itself to novices, should integrate which-key.nvim as well as the behavior in the annotation plugins you listed in the article to make things more obvious.
Vim's big fail is discoverability, not the editing model. You can run through past (Neo)vim threads on HN and consistently find 10+ year vets discovering some new behavior from the TFA of the thread. Perhaps some sort of predictive ChatGPT-based solution would expedite that effort since Vim has a lot of behavior to surface from its manuals. There's :helpgrep yes, but a novice still needs to know what to do ask.
This is why I'm a big fan of efforts like Fish, cause it does a great job surfacing CLI tooling behavior OOB just by pressing tab and navigating for what you want, with descriptions, in place
> They either break from Vim's model (kakoune, helix) or follow Vim along with all it's flaws (Neovim, Vis).
I am sincerely curious of what flaws from Vim has Vis inherited, in your opinion.
I have the impression that the design idea of Vis is taking only the modal design of Vi (not Vim), plus the structural regular expressions of Sam, then make it as clean as possible with programmability via Lua plugins.
In fact, the state non-goals [1] seems to clearly distant itself from Vim.
[1]: https://github.com/martanne/vis#non-goals
I am sincerely curious of what flaws from Vim has Vis inherited, in your opinion.
I have the impression that the design idea of Vis is taking only the modal design of Vi (not Vim), plus the structural regular expressions of Sam, then make it as clean as possible with programmability via Lua plugins.
In fact, the state non-goals [1] seems to clearly distant itself from Vim.
[1]: https://github.com/martanne/vis#non-goals
Vis inherits default keymaps. I prefer the way kakoune tried to clean them up by - for example - putting all the "goto" commands under "g" (where Vim has H, M, L, g;, G, gg, $, 0, ^, etc) and all the "view" commands under "v". Such rearrangements make a lot of sense and to me were more intuitive right away, even after a decade use of Vim. Then there are things like ";" and ",", W, B, E, and gE (where something like w, W, e, E would be a lot more obvious), etc. Vim likely acquired those incrementally and that's why they are all over the place. But if an editor were to start from scratch they could be re-arranged in a more logical order. Yet every vim-inspired editor takes Vim defaults for granted.
I really want to like Helix, but muscle memory of vim over the past 5-6 years trips me all the time. I frequently have to edit files in remote servers and vi is choice editor mostly by default.
So far for me the story has been: see or read something cool on Helix, try it for 20min and attempt to do my actual work for the day on it, then get frustrated and feel slowed down, switch back to my neovim to get stuff done and forget about Helix until the next release hype.
So far for me the story has been: see or read something cool on Helix, try it for 20min and attempt to do my actual work for the day on it, then get frustrated and feel slowed down, switch back to my neovim to get stuff done and forget about Helix until the next release hype.
Maybe you should try committing longer? I had used Vim for nearly 8 years and had learned the crazy tricks you can do with Vim before switching to Kakoune and it took maybe 2 weeks to feel comfortable. I think people may overestimate how long it takes to relearn a style of modal editing which keeps them from committing to Kakoune/Helix which then prevents them from giving Kakoune/Helix a fair chance. After having learned this new style of modal editing, I'm really glad Helix doesn't have Vim style because I feel it be inferior to what Helix has.
I agree about committing longer. It took me a long time of switching back n forth with vscode and vim to fully convert over.
My only problem is personal productivity speed. My whole setup and automation workflow is built around nitpicked or hand-built tools, I'm not Primeagen fast but nearly there. With a full time job, side project/startup I'm really passionate about and family/kids, every seconds matters.
My only problem is personal productivity speed. My whole setup and automation workflow is built around nitpicked or hand-built tools, I'm not Primeagen fast but nearly there. With a full time job, side project/startup I'm really passionate about and family/kids, every seconds matters.
> , try it for 20min and attempt to do my actual work for the day on it, then get frustrated and feel slowed down,
Oh wow... I thought I abandoned new editor attempts quickly when I spent less than a week through the frustration phase.
Oh wow... I thought I abandoned new editor attempts quickly when I spent less than a week through the frustration phase.
By the way, why not start with spending that time changing the keybind to fit your style (someone at the top even mentioned a config with vim bindings already available)? This would at least remove a lot of the frustration and maybe allow you experience the "coolness" longer?
I'm very excited about LSP snippet support, I will finally be able to use stuff like emmet on my svelte/html projects.
For anyone that switched to a CLI editor from GUI, what helped the most with shaking the mouse dependency?
Patience. It's hard to see the line or word you want to jump to and have to look at your keyboard and be like "what do I do?" For me it was basically tell myself "it's ok to be slow" and I started memorizing the navigation patterns from the top down of the `hx --tutor`. The further down you get on having that tutor file in muscle memory the easier it gets to want to ditch the mouse.
I switched from PyCharm and Sublime Text, although I admit I still use them from time to time when trying to grasp an entire codebase. Helix is my primary editor now and I wish I had the helix navigation and editing everywhere now lol.
I switched from PyCharm and Sublime Text, although I admit I still use them from time to time when trying to grasp an entire codebase. Helix is my primary editor now and I wish I had the helix navigation and editing everywhere now lol.
Using vim motion extensions for my primary editors (VS Code & Visual Studio) for ~11 months at my day job while using vanilla neovim (no plugins, syntax highlighting, lsp) for the first 6 months on personal projects.
Easy-Motion, or whatever the new version of that is.
[deleted]
I've finally made the full jump to neovim after using vim bindings in all of my other fully fledged IDES. I've recently been looking at Helix, but the lack of plugin support along with fluid git support is where I'm still stuck. I use lazygit for all of my git operations inside of neovim and it's hard for me to give that up. Anyone have good recommendations for workflows that worked for them regarding these two issues?
Soft-wrap! I love Helix Editor (it’s my daily driver), and soft-wrap was the last feature I was waiting for. Thanks to all the people who contributed to this release.
Same here. I don't usually like soft wrap when writing code, but I really need it when reading documentation. I saw this and am about to update in a minute.
Congrats to all the contributors! I wrote a small patch a few months ago and they were incredibly kind and welcoming as a community. Thrilled!
This is really cool, but the lack of the ability to have code at runtime to do things dynamically is a massive limitation for me, I think most of my issues could be solved with just the ability to do things at runtime. Here's some things I couldn't get working in helix:
- Can't make the the editor's theme automatically switch at runtime when I change the system to dark/light mode. In neovim this is done by hooking Signal and VimResume. - Can't dynamically configure auto-formatters for python projects on the basis of the presence and contents of a file located at the root* - Can't turn off the completely unusual feature of having the tabstop position change (for the actual tab character) depending on the language, or to set a default. Also, why on earth is the bash (or shell) tabstop set to 2 characters? - Can't only show trailing whitespace. - Editor doesn't warn you when you open a file twice (only once you actually edit it). In neovim I have this set up with a custom bit of code to find out which window the neovim instance is in and focus that window instead. An incredibly neat feature you can't seem to implement in hx either.
At this point I can't spend much more time with this, but may later.
The main issue I have with helix (and had with kakoune when I tried it) is just the vast number of slight issues. I don't really care that the motions are different (I agree that the vim motions are inconsistent and would be happy to ditch them for something more consistent) but there's just too many little things for me to feel happy with the end result.
*I have worked around this in hx temporarily using a bash script which works in the formatter key in a [[language]] block for python:
- Can't make the the editor's theme automatically switch at runtime when I change the system to dark/light mode. In neovim this is done by hooking Signal and VimResume. - Can't dynamically configure auto-formatters for python projects on the basis of the presence and contents of a file located at the root* - Can't turn off the completely unusual feature of having the tabstop position change (for the actual tab character) depending on the language, or to set a default. Also, why on earth is the bash (or shell) tabstop set to 2 characters? - Can't only show trailing whitespace. - Editor doesn't warn you when you open a file twice (only once you actually edit it). In neovim I have this set up with a custom bit of code to find out which window the neovim instance is in and focus that window instead. An incredibly neat feature you can't seem to implement in hx either.
At this point I can't spend much more time with this, but may later.
The main issue I have with helix (and had with kakoune when I tried it) is just the vast number of slight issues. I don't really care that the motions are different (I agree that the vim motions are inconsistent and would be happy to ditch them for something more consistent) but there's just too many little things for me to feel happy with the end result.
*I have worked around this in hx temporarily using a bash script which works in the formatter key in a [[language]] block for python:
#!/usr/bin/env bash
bail() { exec cat; }
declare -A rootfile=([python]=pyproject.toml)
declare -A format_cmd=([isort]="isort -" [black]="black -q -")
while [[ ! -e "${rootfile[$1]}" && ! .. -ef . ]]; do cd .. || bail; done
[[ -e "${rootfile[$1]}" ]] || bail
pipeline=()
{ exec 3< .autoformat; } 2>/dev/null || bail
while read -r; do
pipeline+=("${format_cmd[$REPLY]}")
done <&3
recpipe() {
if (( $# > 1 )); then
$1 | recpipe "${@:2}"
else
$1
fi
}
recpipe "${pipeline[@]}"
The rate of progress is impressive.
Helix is awesome but I'm unlikely to see itch from Neovim. There aren't any killer features that I'm aware of and my Nvim setup is highly customized and works perfectly for my workflows.
Good editor. Unfortunately no copilot so I'll keep using NeoVim.
Devs could use the unofficial plugin for Emacs (https://github.com/zerolfx/copilot.el) as a guideline to add support
Addition of soft wrap is huge. That was the main thing that kept me from sinking more time into this in the past.
The only thing missing from Helix is Sublime-like multiple carets.
Can you explain what you mean? Multiple insertion points is kind of The Point Of Helix (and Kakoune, for that matter)
Yes, but only on SEL mode. Not on INS mode. You can't quickly make multiple caret selections and insertions like you can in Sublime.
there are plenty of things missing from Helix, but it does support multiple carets via `copy_selection_on_next_line`
Unfortunately, not on INS mode. I can't be editing one line, then quickly create 5 new carets on the lines below, jump to the end of the line and add something, like you can with Sublime.
As an aside, this is a modal editor, so you're supposed to quickly switch modes
But you can also do it in the INS mode but sandwitching the commands in mode shifts, for example, these should work in the INS mode part of your config
But you can also do it in the INS mode but sandwitching the commands in mode shifts, for example, these should work in the INS mode part of your config
[keys.insert]
'C-j' = ['normal_mode','copy_selection_on_next_line','insert_mode'] # Copy selection onto the next line (add cursor ↓)
'C-k' = ['normal_mode','copy_selection_on_prev_line','insert_mode'] # Copy selection onto the previous line (add cursor ↑)Ah, interesting. That does work, thank you. How would you implement the (Ctrl|CMD) + D feature from Sublime?
I'd wait until the open issue to select words and another one to allow more command composability are closed with PRs :)
Meanwhile you could use something like this (if you already have the word selected as you might likely have since Helix selects by default, then delete the first two command that expand your selection to a word like in Sublime)
Meanwhile you could use something like this (if you already have the word selected as you might likely have since Helix selects by default, then delete the first two command that expand your selection to a word like in Sublime)
'*' = ['select_mode' #
, 'move_prev_word_start' #
, 'move_next_word_end' #
, 'search_selection' #
, 'extend_search_next' #
, 'exit_select_mode' #
] # = find_under_expandThank you, this is enlightening.
A better alternative more closely matching Sublime by limiting search to word boundaries
'*' = ['select_mode' # = find_under_expand
, 'move_next_word_end' # 1st since word_start command might select previous word
, 'move_prev_word_start' #
, 'search_selection' #
, 'make_search_word_bounded' #
, 'extend_search_next' #
, 'insert_mode' #
] #Hah! You're on a roll, thanks. Using this daily and trying to get used to Helix. :)
[deleted]
I tried it and it's great but not being able to use the keybindings I want is a deal breaker. I'm an Emacs user and I won't make the jump to learn another system again.
Love the editor for making some quick fixes or checking the repo/files. But not using it as a full time driver.
This release has support for snippets but at this day and age, I would have thought we would get our long time request fixed.
https://github.com/helix-editor/helix/issues/1927
If you read the issue you link to, you would know that the request itself is not the issue, but the lack of a plugin system is.
If Helix were completely different in this regard, like Emacs is, I could handle--and I know because I use both vim and Emacs regularly pretty fluently. But Helix is way too close to the vim keybindings to discern it from a memory muscle perspective. I use vim keybindings everywhere else (zsh, all readline-based apps via a setting in ~/.inputrc, VSCode), so getting used to slight differences in just one editor is extremely hard because I can't just drop all other apps.
I recently tried this: https://github.com/LGUG2Z/helix-vim which attempts to provide vim mappings to Helix. It's funny how the description in the page describes my progression almost 100%. And while it makes things slightly better, it's still not accurate enough to make this a non-issue.