I've used Helix for all my recreational programming projects (in Rust) for about 6 months and I've written about 10kLOC of code with it. Still using vim at $WORK for a variety of reasons (giant c++ codebase that does not easily plug in to clangd/LSP), but I might be doing the switch soon.
Installation was easy and the default configuration is good. Plugging in rust-analyzer still needed a line or two of config file editing, but that should not be necessary for very long. Hint: use `hx --health` to check that all the tools are properly installed and configured (it shows a matrix of programming languages and their associated tooling, with red/green check marks).
My Helix config file is about 5 lines long, but my Vim config is in the hundreds of lines.
I had very little friction coming from Vim and a little bit of Kakoune.
I particularly like the fact that all the important features are built-in and not half baked scripts with unintended side effects (e.g. opening a Makefile in Vim triggers a ftplugin script that messes editor-global config instead of buffer-local, with the default out of the box scripts).
Lots of people are requesting a plugin extension system, which is kinda understandable since every editor seems to have one. But I haven't had a need to add any kind of plugin, and it's easy enough to fork a shell for an external process if needed.
It's still rough around the edges, but good enough for a daily driver.
>I've used Helix for all my recreational programming projects (in Rust) for about 6 months and I've written about 10kLOC of code with it. Still using vim at $WORK for a variety of reasons (giant c++ codebase that does not easily plug in to clangd/LSP), but I might be doing the switch soon.
Do you have some supernatural ability to quickly (re)learn muscle memory for new keybindings? I’d consider myself a fairly advanced vim user, and it took me literally a couple years to get to the point of fluently using complex navigation/editing commands.
I took a look at the Helix documentation, and while it’s definitely “vim inspired,” it’s different enough [0] that I would have to rewire years of muscle memory to be as productive as I am in vim.
There are some very fundamental differences, e.g. the verb/object syntax is reversed in Helix; `dw` in vim is `wd` in Helix. When I want to rewrite a string in vim, I unconsciously type `ci"`; it would take me a long time with Helix to regain that level of fluency.
I’ve got the same question. One of the major reasons I invest time into vim is because it’s everywhere and so powerful. If I invested time into learning a different set of keys for an editor that isn’t always available, I wouldn’t be able to leverage that power and fluency all the time, and furthermore, would need to switch back and forth between vim and helix keys
I've switch from years of Vim to years of Kakoune and am now trying Helix.
While annoying I find I pick up the right keys fairly quick. A week until I get decent productivity back and a couple of months tops to truly get the hang of it.
I find it immensely helpful that Kakoune and Helix _make sense_. It is also a great boon that there's visual feedback.
Seconding this. I had used Vim for nearly 8 years and felt very comfortable with all the crazy tricks you could do with modal editing but I genuinely felt Kakoune's way of doing modal editing was an improvement so I committed to learning it and it took maybe a month to get comfortable with the new way of editing. I'm really glad I took the plunge because I'm a really happy Kakoune user and I can't think of anything that I miss from Vim.
How does it improve on neovim? Seems to me like slightly different keybindings to do the exact same thing, you're not saving any keystrokes or fatigue as far as I can tell.
It switches from "action selection" to "selection action" which allows you to first select the thing you want to operate on and only then specify what you want do with it. So for example in Vim you may accidentally select too many characters to delete and then you need to redo the command whereas in Kakoune you can adjust the selection before executing the action.
I think one of the best things Kakoune has to offer is that selection mode (visual mode in Vim) is always accessible through <shift><movement> so if I want to select some random number of characters going left, I'll just hold L, or if I want to select all characters until the end of line I'll just press GL whereas gl takes me to the end of line. It makes it so easy to select text.
Finally multicursor, it's so good. I've used Kakoune for over a year now and I haven't had need for macros except for maybe 2 times. I didn't know I needed a multicursor before I had tried Kakoune and I would highly suggest anyone to try Kakoune just for the multicursor experience. It allows you to select a pattern using regex and then operate on the matches simultaneous. Kind of like Vim's "visual block" but on steroids.
selection action is already possible in vim using 'v' or 'V'. But many times, I do want immediate action-operator when I know exactly what I need to operate on. So Kakoune is un-convincing.
>But many times, I do want immediate action-operator when I know exactly what I need to operate on.
This argument doesn't make sense, it's just as fast to type in Kakoune. The order is just different but it makes it possible for you to adjust it when you've either made a mistake or don't exactly know what kind of selection you want.
I know the visual mode in Vim exists under 'v' but the point I was making was that in Kakoune it's more handy and I use it constantly because it's so available, just hold Shift key as oppose typing another letter to enter it. I know it sounds insignificant but I find myself using the visual mode all the time in Kakoune whereas I barely used it in Vim because of that tiny extra effort to enter the mode.
This how I feel about vim too. I’m sure there are editors I would like more but I work on remote servers every day, some of them lightweight, and vim is already going to be on all 500+ of them as part of the OS install.
The keybindings are pretty similar, the paradigm change from verb-noun to noun-verb and the multiple cursor paradigm are bigger changes. I got used to it with my brief affair with Kakoune.
The Vim muscle memory will be quite helpful and not a whole lot of unlearning is necessary. hjkl navigation and other familiar concepts are similar in Helix and Vim.
Vim ci" translates to Helix mi"c. After the first key press (m), a help dialog pops up.
hjkl are definitely table stakes for a vim-ish editor, but I also can’t live without 0 and $. Making me move my hand over to find home and end misses the point of hjkl entirely.
I opened helix to check it for you. Pressed `g` and had a little popup tell me that following with `h` = line start, `l` = line end, `s` first non-blank in line (plus ~15 other options).
My hx doesn't wrap lines, so didn't check `gj` and `gk`.
Good question, and I don't think my answer will satisfy your needs, but it does mine.
The only long form text that I ever write is in markdown.
I do miss the `gq` command from vim, but in general I just do a single line break after every dot.
Markdown ignores a single line break in the middle of a paragraph, so it works out okay.
I even found it almost convenient to edit text like that because it's easy to move lines around.
In code documentation (which I do a lot of), I have to manually wrap the lines of course (just like anyone else). That's where I miss `gq` the most. :)
After 20 years of vim I decided to try out Helix back in Feb and never looked back, so I guess I can chime in here.
Sure, it took a few days (maybe weeks?) of feeling uncomfortable, but unlike vim, Helix is very approachable. I think you have to be okay with a certain level of feeling uncomfortable if you want to do or learn anything new though. If learning a new editor isn't your thing, then don't. :)
I get this same question a lot when people realize that I use Dvorak layout. Sure, yes, it took time to learn. But I was curious if there was something better for me on the other side. It seemed plausible that there would be, so I gave it a shot. In both cases I have been happy with my investment.
Slightly off-topic: how do you manage using an alternative layout with an editor like vim/Helix? I've been trying to figure out how/if to remap the keys in the editor condig.
If you remap hjkl to your right-hand home row, that could cause a cascade of other remappings. If you don't, you lose basic navigation with hjkl.
I use Dvorak, although I regret the choice to learn it instead of Qwerty. If you don’t remap, and I don’t, then you need to use two hands instead of one to navigate. Not a dealbreaker for me though, since by coincidence the places hjkl ended up on Dvorak that makes navigating with them tolerable.
This was my same impression when trying out helix. Really nice and shiny, but all the shortcuts I've spent time creating over the years are gone and not easily reconfigured.
Don't even try to reconfigure them. Try to learn the editor first as it is.
If you think that's crazy-talk, then imagine someone saying they'd like to learn vim, but they find it hard to configure the shortcuts to be like Eclipse. They aren't wrong, but it also doesn't seem like the right approach to learn vim either.
Deletes text inside the nearest quotes and puts you in insert mode. You probably tried it without being inside a quoted string, that's why it did nothing.
> But I haven't had a need to add any kind of plugin, and it's easy enough to fork a shell for an external process if needed.
For me, coming from writing Clojure with Neovim + vim-sexp + vim-fireplace, I would need Paredit and REPL integration.
Paredit is doable with Treesitter, and I'm actually really excited about Helix's Treesitter integration--- every time I write a non-Lisp language, I miss structural editing, so it'll be nice for other languages catch up to Lisp on that front. It doesn't really look like it's quite there yet, though. The built-operations that use Treesitter are spare [0], and while you could implement operations like promote, slurp, and barf with them, you'd have to clobber some register. I don't see at all how you could implement splice without an actual language, since you would need a way to select all siblings of the current node.
REPL integration absolutely needs a plugin language. Unlike the LSP, there isn't a standard protocol for communicating with a REPL, so each language requires its own REPL client. Unless they want to ship a REPL client for every language under the sun, they'll have to provide some way for users to implement their own clients. That said, every time I look at Conjure, they've added REPL clients for more and more languages [1], so maybe it is feasible to have it built into the editor.
Helix has built-in paredit-like navigation using tree-sitter, the default keybindings are alt-i, alt-o, alt-n and alt-p.
Maybe the Debug Adapter Protocol (DAP) used by vscode will solve the REPL issue in the future. Helix has experimental DAP support but it's still quite rough (but no Clojure DAP server yet).
I think the fact that helix doesn't really need a plugin/extension system is beautiful. It means that it's simple enough to config yet still powerful. Helix smooth out the learning curve in this good way and I hope it won't become complicated and make learning curve as deep as vim/nvim.
I fully expect Helix to replace Vim, Neovim, and Kakoune for most users in the long run.
Helix is built from the ground up around Tree-Sitter and LSP. This means you get the best syntax highlighting available, and IDE-like functionality, with zero configuration required other than installing the appropriate language server.
Those are by far the most important features for a text editor to have, and crucially, they are fully integrated into Helix, but are an afterthought in (Neo)vim and Kakoune. The quality difference is obvious the moment you try it side by side. Nothing else really matters. Vim's and Kakoune's syntax highlighting is terrible, and while Neovim can now use Tree-Sitter as well, there always seem to be some additional hoops the user needs to jump through in order to get it to work. Not so with Helix.
Regrettably, Helix has inherited Vim's worst design flaw, namely being unusable with non-English keyboard layouts, but all other Vim derivatives share this flaw as well so I don't see that stopping Helix from steamrolling the competition once it matures and the word spreads.
I just can't see if ever taking off, if I'm honest. The people that use neo/vim are going to continue using it, even if Helix is better. The people who aren't yet using it will use vs-code and the few that do switch, well they might go to Helix but there's a lot of vim resources out there, so I'm not sure all of them will go to Helix.
Honestly, language servers are a bit of a faff to set up, but that's tooling and it's getting easier and easier to get these installed now. I expect that will continue.
I've tried to make the switch to Neovim from Vscodium before but there was so much configuration for all the language stuff (and I'm not the biggest fan of Lua). But after seeing this post and installing Helix it's been pretty painless so far and I think this can actually help me make the switch. I am about to try some configuration for Rust debugging but that shouldn't be needed once they've got full DAP support. I use Neovim as my standard text editor so the navigation and bindings aren't a problem, lets see if Helix can make my IDE be in the terminal too.
For the longest time I was using YouCompleteMe with vim and then tried all sorts of LSP servers. And while I'm still using them, I feel like that YouCompleteMe solution back in the day had a lot less fiddling involved. Sure they have more features and more selection and variety nowadays, but I have spent so much more time configuring things that I kinda regret it now.
> I just can't see if ever taking off, if I'm honest. The people that use neo/vim are going to continue using it, even if Helix is better.
I would think that helix probably is better because I'm certain that the verb->text object paradigm in vim could be much better. It may in fact make more sense to do the 'text object' first like it seems to do in both helix and kakoune. But is it better enough for me to switch off something that I've used for years now? Only if it sees mass adoption and you see many developers adopting it. Like if you see it in VS Code as an option to use helix bindings, then it is probably safe to consider adopting it.
> Honestly, language servers are a bit of a faff to set up, but that's tooling and it's getting easier and easier to get these installed now. I expect that will continue.
I've been pleasantly surprised with how much better LSP setup in neovim has gotten, as I've transitioned over to the native LSP from CoC, which is also excellent. It's still not pain-free to setup, but it's much easier than it was and I suspect you're right that it'll continue to get easier... though I doubt it'll get anywhere close to how easy VS Code is to use any time soon.
While I was going through the effort to set up DAP support, I discovered [mason.nvim](https://github.com/williamboman/mason.nvim) which has been a game-changer for LSP, DAP, and linter setups.
There had previously been fragmented plugins (williamboman/nvim-lsp-installer was Mason's predecessor and is a good example) that solved the problem of installation and management for each of these. With Mason, I feel that the story for managing different language environments has jumped to be extremely close to VSCode's extensions.
> The people that use neo/vim are going to continue using it, even if Helix is better. The people who aren't yet using it will use vs-code and the few that do switch
I'm not so sure. I have been using vim for years and I still do, but in the last few years the majority of my use has been vscode with the vim plugin. I have seen the same pattern in many others.
Helix is right up my alley and I'm definitely playing with it. It's not a straight vim replacement for many reasons and it's also not yet a vscode replacement for me, but I'm very excited about it and I can absolutely see it replacing my use of vim sooner or later.
I fully expect Helix to replace Vim, Neovim, and Kakoune for most users in the long run.
Yeah, that’s not going to happen.
It’s cool to have choices, but you wouldn’t be the first person to think a new editor is going to replace Vim/Neovim. Vim is literally on every Unix/Linux server; every sysadmin can count on it being there.
I’ve been super impressed with the progress of Neovim and the team behind it. It’s only at version 0.8 but they’ve done some amazing things already.
I expect Neovim will get to the “batteries included” stage with Treesitter and LSP; it’s not far from there right now. And there are several Neovim distributions (LunarVim, Nvchad, etc.) that have all of the bells and whistles included. Helix sounds like it’s similar to one of these Neovim distributions.
Again, Neovim gives you choices: you can configure and tweak it to your heart’s content if you want or you can get something pre-configured with all the goodies installed and configured. Or you can use it headless from a different frontend (VS Code, browser, etc.) if that’s what’s needed.
Perhaps the best thing about Neovim is how great it is for both longtime Vim/Vi users and brand new users who are ready to graduate from Notepad and Nano.
>>And there are several Neovim distributions (LunarVim, Nvchad, etc.) that have all of the bells and whistles included.
Problem with distributions is as the contributions decrease they start becoming abandonware with time.
Leaving you with with vim and having to work through the configuration hell on the long term for yourself.
>>Again, Neovim gives you choices: you can configure and tweak it to your heart’s content
Trust me this is negative thing, not exactly something most programmers want. Most programmers don't enjoy configuring their IDE/Editors as a full time project together with your regular day job.
I agree with this. I spend most of my days on newly created systems (AWS EC2 instances) that are bone stock. I don't use any vim plugins at all because they wouldn't be the same everywhere and it's not worth configuring a system I'll only use for 2 hours. If I could get a full featured IDE installed by default on my systems I would ditch vim in a heartbeat.
You might want to look into Emacs with evil mode and TRAMP. TRAMP lets you remotely access files on a remote machine as if Emacs were running on that machine with all its IDE bells and whistles. It does require LSP programs and such to be on the remote side but you could probably script bootstrapping whatever you need fairly quickly. Certainly less setup than bringing over a whole editing environment with plugins, .vimrc, etc..
but you wouldn’t be the first person to think a new editor is going to replace Vim/Neovim. Vim is literally on every Unix/Linux server; every sysadmin can count on it being there.
Even that is a new(ish) development. For a long time people where saying exactly that about vim. I'm not _that_ old, and I was told early in my career not to get too dependent on either vim or the GNU tools since they probably won't be installed on most systems you connect to.
I don't disagree with your overall point, but that audience is pretty small, and the number of people who text edit a lot that a) need to float between machines frequently AND b) don't have enough access to install what they want is even smaller.
> Those are by far the most important features for a text editor to have
To you, maybe. The most important features of an editor for me, and for many people, is that it is stable, dependable, and ubiquitous.
There is no way I am going to re-learn years of muscle memory for a "post-modern" editor. Cool and trendy is the exact opposite of what I want in my tools. What happens with the authors get bored and move on to the next shiny thing?
Vim is available on ~every machine I could possibly interact with. There is a vim mode in every single mainstream editor / IDE. My Vim muscle memory will keep me productive for the rest of my life.
IMO, making something slightly nicer to configure is never going to overcome the inertia of a project like Vim. The new editor would have to be like 3x better to convince everyone to make the switch, not 1.1x better in some specific areas.
> Vim is available on ~every machine I could possibly interact with.
This is my exact reasoning for sticking with Vim. I use Neovim on my desktop, but I work with servers and have a homelab where I just want the greatest common factor. Nano is also an option, but just like you, my Vim muscle memory is embedded and I end up with :wq everywhere.
Is Helix cool? Absolutely. Will it replace [Neo]Vim? Not until it's installed by default everywhere, and that won't happen unless it has a compatibility mode for Vim shortcuts.
Exactly. The features OP described are IDE like features that many vim users like myself don't want in my basic text editor. Adding extra features via plugins is not an afterthought but design. He clearly doesn't understand the vim/neovim crowd and the design philosophy.
Small correction though, vi is available on every machine, not vim. But indeed this is big reason why I use vim for my own stuff.
Do you have any specific examples of things helix does better than neovim?
I think the neovim implementation of LSP and treesitter is quite nice. It was not that polished when I tried it last, but I think once it becomes mature, it will be really flexible. Tree sitter specifically is still considered experimental, but I think the timeline for that to be better integrated will be significantly faster than it takes for any new editor to get a decently sized community around it.
The zero config part of it is nice, but I think you’d be competing with e.g. VSCode with modal bindings on that note. Vim/Neovim have always had a fairly steep learning curve, and I can’t see that aspect of it mattering as significantly, especially since I only see LSP/Treesitter support improving in neovim.
There's a difference between having a "learning curve" and having to spend effort setting up things that work out of the box in another editor.
Vim advocates generally claim that investing time learning the Vim keybindings pays off as saved time during later work. But that's not what's happening here. If LSP just works in Helix, and requires fiddling with config files in Neovim, then Neovim is wasting my time, not teaching me something that will be valuable later on.
Yeah, learning curve may not be the best way to phrase it. But I think that is the price of flexibility to be able to create an editor in which you don’t have to use LSP if you don’t want to.
Personally, I think keeping Neovim the editor separate from something like nvim-lspconfig is pretty nice right now, to be able to update them separately, which is nice for new languages and language server changes. Maybe it (and the broader LSP ecosystem) will eventually be mature enough to be included by default.
I’d also say that if you want zero config, just using a config framework (there are a few), gets you most of the way there, whilst retaining more of the flexibility but that’s not a strong point in favour of Neovim.
Still, until Helix gets a comparable community and some features over a properly configured neovim, I think it will be hard to displace it (and Vim, EMacs etc.) because Helix doesn’t currently doesn’t as anything significant for existing users.
Any sufficiently complex "one-time setup cost" quickly becomes an ongoing maintenance quagmire. And I say that as a full-time neovim user for the past seven years.
Neovim is still my favorite vi, but I think I erred when I started bolting on so many plugins and supporting processes... when I want a lightweight IDE, I'll use VS Code.
> One time setup cost is a small factor in choosing an editor.
Perhaps for you, but empirically for devs as a population, this is very clearly false. A large part of the reason for VSCode's near-takeover for new devs in the last few years is its frictionless setup for almost everything.
Sometimes treesitter has problems. Indenting has gotten worse and configuration is a lot more complex.
I have the same config with some neovim / vim specifics and I find myself using vim more often even though the neovim features are "cooler".
I wonder if it will ever become "mature". It doesn't crash for that matter, but you have to keep everything updated constantly. Vim doesn't really have that problem.
Helix looks cool too, but I was looking for what it has that the others don't have and I can't figure it out. The website just makes it seem like it's cooler than the others.
Treesitter is still a bit iffy. LSP is a bit better, but is still not amazingly mature (but some of this is to do with the LSP servers themselves not being that mature).
Other than that, I haven’t had any problems with Neovim. Everything else has been rock solid, and I haven’t needed to update frequently for anything else. Have you experienced other issues?
However, these are the larger “killer” features of neovim, so at this point there’s not that much over Vim. However, there aren’t any Vim features I use that are missing in Neovim either. There are a couple of minor things that push Neovim over though (`inccommand`, Lua is marginally nicer, Neovim plugin scene has exploded recently).
So since Neovim (for me) has feature parity and equal reliability, with some really nice added frills and some moderately reliable, but maybe not incredibly mature, killer features it still beats Vim in my book.
For me personally is better because it works out of the box and their built in features are most of the things I need, fuzzy finder for files in the project, opened buffers, LSP, syntax highlight, etc.
If you are an old vim/nvim user, you already know deeply your editor/ecosystem and your config file is very solid, you definitely won't like helix at least yet, you need to learn to do everything the helix way and not the vim/nvim customised way you build all those years.
So I will say that for developers that are starting using terminal editors, helix is a very good starting point, because of the built in stuff that it seems essential at this point in time for an editor to already have and that might be what helix does better.
> I fully expect Helix to replace Vim, Neovim, and Kakoune for most users in the long run.
I hope this doesn't come off as flippant: I thought your comment was sarcastic at first.
While I love seeing newer / better software displacing the old and crusty, this seems a little unlikely, no? It seems like somewhat of a miracle that neovim has taken as much share as it has.
> It seems like somewhat of a miracle that neovim has taken as much share as it has.
It's not a miracle but rather a testament to how much Neovim improves upon Vim. The number of useful features, among them Tree-Sitter and LSP, that Neovim has introduced has ended what feels like decades of stagnation in Vim development.
Now imagine an editor like Neovim, but instead of working through 30 years of cruft and legacy code, it's built from the start using modern software engineering techniques and incorporates such features into its core editing model. That's essentially what Helix is. The Vim -> Neovim improvement is nothing compared to what Helix will deliver (and already is delivering in many aspects).
> Now imagine an editor like Neovim, but instead of working through 30 years of cruft and legacy code, it's built from the start using modern software engineering techniques and incorporates such features into its core editing model.
User inertia is strong. Neovim has its success because of its improvement, but more importantly, the keymap and config language is based on Vim7. Vim7 users can painlessly switch to Neovim with all config preserved. That's the main reason why Neovim can gain a large number of users initially. Conversely, Helix has no keymap nor configuration compatibility with Vim or other mainstream editors. Given this, I see no hope that Helix will become mainstream.
Based on my observation of colleagues' dominant usage of IntelliJ-originated editors, I think that modal-editors users are far enough from the mainstream that some rules dont apply: Heliy may end up dominant in our pocket-universe, based on merit alone.
IMO it is not that surprising that neovim has had some success, in the same way that it isn't very surprising that SwayWM has had some success. They both have the benefit of, in many cases, being completely compatible with the tool they want to replace. Being almost completely compatible with the old tool, while integrating a popular new technology (LSP or wayland) seems to be the only way to win over users who already have a strong connection to their tools of choice.
My vimrc already has a bunch of configuration in it, I'll give Helix a try when it is able to parse that (so, probably never, I guess).
> Those are by far the most important features for a text editor to have
The most important feature of a text editor is that it can edit text well. Vim is popular because it’s the best _text editor_ not because it has a bunch of plugins making it an IDE.
Code is text. So it is good to have a very good text editor for manipulating it as text. But code is also very different from plain text. It is highly structured. When I think about code I think about it as some kind of syntax tree (call hierarchies etc) . I don't think about it as character buffers. So if I am programming and I can have something that supports good text editing but also good tree editing then I will take that over something that only does good text editing.
I agree with this. I have never been a vim/neovim/helix user, so there's little I can contribute here. But I have always used paredit commands as much as possible, in all languages, not just lisps, and that's still true now that I've switched to vscode from emacs. I'm curious whether any vim/helix editing operations are "tree-based" in a similar way to paredit, and also whether anyone's building a paredit-like editing system based on treesitter.
I don't see it. If you want IDE features in a text editor, you can use VSCode, it even has vim bindings that are at least trying (with middling success) to match the originals. The addressable market for Helix seems to be (neo)vim users who aren't picky about keybindings and new users who want a terminal editor in 2022. So... on the bright side the developers can probably have one-to-one conversations with all 10 of these people.
I think you're overestimating the likelihood that Tree-sitter is going to gain enough traction to be reliable for general purpose text editing. It's great for popular modern languages, but not for everything, and there's no fallback in Helix. I'm not convinced that's ever going to change.
Reliable? I trust Tree-Sitter's grammars a hundred times more than the underspecified regex monstrosities that power highlighting in other editors.
Tree-Sitter grammars are unit tested, have usable primitives for precedence and associativity, and are generally far more predictable than previous highlighting systems.
Also, name a language for which there is no Tree-Sitter grammar yet. The only remaining ones are so obscure that the missing "fallback" is irrelevant for 99% of users.
Python, Janet, Haskell, and Hare were the filetypes I remember either being unsupported or not working well. I need to be able to depend on basic language support from my text editor, even when I work with niche languages.
I've been using Python with tree-sitter on neovim for many months. It's great, and has a lot of improvements when compared with the old syntax system.
Re Hare: I haven't even set that one up. Setting up a new tree-sitter on neovim requires extra work for each tree-sitter, and that's definitely a flaw that needs to be addressed.
> Helix is built from the ground up around Tree-Sitter and LSP
And what happens in ten or twenty years, when both are obsolete? I don't really care, what technologies my text editor is built on top of, but I sure would like to be able to still use it for writing my memoirs when I'm old.
LSP will not become obsolete, it will evolve. The entire industry is rallying around LSP, and Microsoft is constantly improving the protocol. In "ten or twenty years" LSP will have become a required feature for every programming language and every text editor. It will be essentially impossible to replace it with any other technology because of the massive investment already made in the ecosystem.
I can imagine Tree-Sitter slowly losing importance because LSP is integrating semantic highlighting, but Tree-Sitter will still be an easy option for writing grammars in the absence of a full-featured language server.
Unless the protocol changes to specifically address this, I find it unlikely that LSP will ever be a full solution for real-time syntax highlighting. The amount of JSON that has to be slung interprocess on each edit is just too much. Providing extra semantic highlighting on top of a built in option, absolutely, but I don't think it can replace an in-process, specifically incremental option like Tree-sitter or Sublime/TextMate language defs (or a completely custom solution like JetBrains, Nova, etc.).
I can see Helix replacing Vim and Neovim for the most "normal" user. It's great, and it's a better alternative than VSCode for Vim users that aren't quite power users but also not exactly the most basic user either.
However, until I can fire up a new installation of *nix and type `helix` to begin editing things it will never replace good 'ole Vim.
I'd say that has been true in the past (and is still mostly true today), but I think this will change in the future. I have been using lsp+treesitter for markdown editing and it's been an excellent experience. It's still early days, but with treesitter and lsp being as universal as they are I've been seeing a lot of people just experimenting with what's possible.
So yes, they are essential only for source code editing, but it's quite exciting to see what they can do for general text editing.
I'd say the most important thing is jumping to definitions. That's not terribly useful for standalone documents, but I use markdown for general note taking and it allows me to easily link other relevant notes. With that come a bunch of benefits, like autocomplete, finding all references, renaming/refactoring, hover preview, etc.
Other editors implement this specifically for markdown (i.e. Obsidian), but not needing to switch programs, as well as just having one set of motions/keyboard shortcuts has made a big difference in workflow for me.
There are also a lot of other surprising benefits of treating raw text the same as code. I started using auto-completion with user defined snippets when writing Documentation (makes it much faster to integrate code blocks, tables, etc).
Many (if not all) of these things can be done in other ways, but I think it all just fits very well together and I enjoy that workflow tremendously.
I'm looking forward to seeing Org Mode implemented as a language server. It's unfortunate that such a great general text organization tool is locked into the relatively small Emacs user community.
orgmode is so not a markup language and cant be served via lsp. its a whole ecosystem built on top of emacs. short of rewriting it, implementing it fully in another editor would require a sort of virtual emacs machine running in the background
Typescript or Rust are also not markup languages, and language servers for them allow for many interesting, non-trivial operations, so the model is capable.
Ergonomic keybindings would be a challenge though.
LSP goes far beyond source code. It also covers an increasing number of markup and configuration languages, and there are even language servers for prose that perform grammar checking and offer style suggestions.
Problem is, all of that sounds like a lot of crap to have running, and a lot of dependencies. That is not everyone's thing.
I like to be able to type "ps" and see one process for my editing session (with a low VM footprint in the low double digit megabytes at most, which had a startup time in the low hundreds of milliseconds.)
The existence of multiple editors of varying ages still in use today shows that tool choice is not a hard and fast X > Y thing. This personal choice is multi faceted and complex.
In software engineering, the proliferation of OSS is at the heart of what makes this craft great. Many passionate people create and recreate tools for the same “job”. All this happens with strong pressure towards public, inclusive and open communities around them. The fact that the method and medium require the same general skills means we can think very deeply about tool choice.
> I fully expect Helix to replace Vim, Neovim, and Kakoune for most users in the long run.
I feel like I am definitely not in the "most users" group here.
> syntax highlighting ... IDE-like functionality
> Those are by far the most important features for a text editor to have.
The most important features for me are the ability to navigate around and manipulate whatever's in the buffer(s) efficiently. I'm a 30 year vi/elvis/vim user and ... I'm not going to be able to use this. The deviations from vim's keybindings are much too widespread and tbh I find improved syntax highlighting and (especially) IDE-like functionality significantly too weak a draw to invest any effort in learning the Helix way - only to context switch between local Helix and remote vi(m) throughout my day anyway.
I tried, really I did. Opened up a file I'm actively working on. First thing I needed was `dd` and to my horror it didn't delete a line, but two characters. Turns out vim's `x` is Helix's `d` - except not quite; `5d` doesn't do what `5x` did, in fact the 5 does ... nothing?
OK fine, well, I regularly use `V` to highlight groups lines and delete those (or pipe them through my equalprg, or `:'<,'>!`) so I tried that ... nope. Though imagine my surprise when I tried `5x` and it highlighted 5 lines. Why didn't 5 apply to `d` but did to `x`?
I tried `:r!<some cmd>` but alas, no `:r` and in fact no `:!`. All these examples are things I do tons of times every day. So I read the "Migrating from vim"[0] document really hoping there was a "activate vim compatibility mode" thing but instead all I saw were the new sequences I'd need to learn, especially ones which require more keypresses such as:
go to line first non-blank character:
vim: ^
helix: gs
go to line end:
vim: $
helix: gl
delete to line end:
vim: D
helix: vgld or t<ret>d
Investigating more, I found `:insert-output` is the same as `:r!` - tried to map the latter to the former to no avail. I kept finding other things that pissed me off just while I was editing the config file (with helix itself). I want to turn off all the menus which pop up everywhere as soon as I hit `:`. I hated that every time I typed a double quote, it inserted two - I literally never want that, in any language, ever.
So many showstoppers for me, which is a shame. Perhaps I could configure the hell out of it - going against what many other folk are proclaiming as sensible, sane defaults - but then I'm back to where I came in. All the effort to make it be like vim except with some syntax stuff I don't really need... no sale.
I think most of the "muscle memory" bindings there are a bad idea (helix is different from vim - if you don't want that, I recommend neovim).
As for "dd" - that would be (as indicated in your quote) select line, delete (yd) in neovim.
Similar for delete to end-of-line - the second form is probably the "most helix like" - in being somewhat discoverable and "interactive" v(isual mark) return (end of line) d(elete).
As for filtering selection through pipe, or reading command output - they are also different:
"!" in normal mode is "insert-output" (r! in vim), while pipe is "filter" -
eg, after selecting three lines, hit "|" then input "sort<enter>" - and the selection is piped through sort.
As a long time vim user I agree that helix is alien - but I also think the change to selection-action is good for discoverability (the <space> context menu, interactive feedback on multiple replace) - and makes more sense.
I still would like to see <leader>, and some "shortcuts" like "dd" (but I'm not sure what would be "best fit" in the world of helix for that. I don't think "dd" is a great choice.
Thanks, I may give Helix another spin with that config. I saw the note about it being necessary to recompile, which I can't be bothered to do so I guess I won't get everything but it may get me through most of the day with less frustration (especially now I've turned mouse support off too; the cursor moving when I click to raise my terminal window was incredibly frustrating).
Two out of three examples for sequences that you provide are not shorter in vim.
At least on my (US) keyboard, typing `^` takes two key presses (Shift + 6), as does typing `gs`. The same is true for typing `$` (Shift + 4) and `gl`.
When reading the migration guide as a decade long vim user, I actually found myself to think that some sequences in Helix are improvements over the ones in vim. For instance, `gs` is easier than `^` because both g and s are on the home row.
I do agree that going from `D` to `vgld` is a big change. If it is consistent throughout the UX, it might not be that big of a deal, though.
I don't think I'd agree that two simultaneous keypresses is equivalent to two in sequence. But besides which, `^` and `$` are so ingrained with meaning to this grumpy old Perl coder that abandoning them is an extremely hard sell. Perhaps I'd be OK with `\A` and `\z`.
> I fully expect Helix to replace Vim, Neovim, and Kakoune for most users in the long run.
Is there anything preventing other editors from integrating LSP and making it work out of the box without any configuration other than adding a language server?
What's preventing it is their existing codebases, mostly.
IIRC, one of the first things Neovim did was throw out literally tens of thousands of lines of legacy code from Vim.
Meanwhile, Helix can just add the `lsp-types` crate as a dependency and they're already a quarter of the way to making LSP work.
The difference between adding something to a 30-year-old C project and a new Rust project is so massive that it can actually be the difference between "fairly straightforward" and "essentially impossible".
Right, but Neovim does in fact have LSP support. That part is done, that's not a blocker for the It Just Works experience. It's that the editor currently doesn't come with the relevant configuration (in vimscript or lua).
While the Mac-only editor BBEdit isn’t open source, it is a 30-year-old C++/Objective-C project, and BBEdit 14 added LSP support which is largely exactly what the comment you’re replying to suggested: install a language server somewhere on your path and BBEdit will find it and use it. It’s preconfigured for a couple dozen popular ones, and adding ones it doesn’t know about out of the box is usually just as as easy as filling in a couple fields in a dialog box.
I agree with you in principle, but in practice I’m not convinced this is an insurmountable hurdle for other editors.
> Regrettably, Helix has inherited Vim's worst design flaw, namely being unusable with non-English keyboard layouts
How so? I find the default helix shorcuts to be generally quite close to "ascii text input" - that is: ctrl, shift, alt, a-z and regular punctation?
FWIW I work on a Norwegian layout on a Mac, which is rather horrible for programming and shell use (option-7 for pipe, shift-option-k+space for tilde (!?), shift-option-7 for backslash, shift/option/alt + 8,9 for brackets ...).
I do miss "leader" from vim/neovim - and autocompletion from buffer (when there is no language support, like configuration files).
> How so? I find the default helix shorcuts to be generally quite close to "ascii text input" - that is: ctrl, shift, alt, a-z and regular punctation?
Try it with a non-Latin script language. It's borderline unusable.
Nothing works in Normal mode. You have to manually switch back to English any time you switch to Normal mode and back to the other language in Insert/Replace mode, or when typing parameters to things like :s.
No other editor requires you to switch language back and forth just to use the editor's commands.
If find motions in neovim a lot easier to reason about than those in helix. A lot of actions that are pretty easy on neovim are a huge pain on helix.
I do appreciate Helix as a research project investing in new ideas, but I do feel it a lot more limited. Everything keyboard/motions related just feels much more limited than Vim. For example, re-doing actions makes little to no sense because most actions tend to be split in two. `3dw` can be redone just fine on neovim, but not on Helix.
Can someone elaborate on why Vim doesn’t work well on non-english keyboards.
I use Vim occasionally using a Nordic layout but would like to know why English is superior.
On a Latinamerican keyboard (yet, that's a thing), the brances are not as convenient. IIRC, the ~ symbol isn't even around. Semicolon is shift+right right finger -- super odd compared to just pinky. And ^ is behind right-alt (the one in the photos shows where, but many don't actually have it printed on the keycap).
I'm a nordic-layout user as well and whenever I look at the actual differences side-by-side I get reminded about how much easier it would be to code if I had all those symbols that close.
I grew up with the Icelandic layout. When I started programming professionally I taught myself the en-us layout and stared using that instead. It is much easier on my hands and fingers; it really does show that the people who came up with the syntax for most of the programming languages in use picked things that were easy to type on a US layout and didn't give any thought to the rest of us.
I’d love to know what the result might have been if they gave some thought to the rest of you. And if a person is designing a programming language syntax, I don’t see why keyboards that are foreign, even unknown, to them merit much consideration.
BTW I really don’t think the en-us layout is actually nice on hands and fingers. All the programming symbols are a stretch. I now use Karabiner to make easy key-chords for all the symbols, e.g. f-j is ( and f-k is ).
I do not think there's a particularly feasible way to facilitate every keyboard layout out there, so it makes sense that they are at least built with one keyboard layout in mind, much like I think it makes sense that programming in general is overwhelmingly done in English. It increases interoperability significantly.
I tried that once, but already back then my muscle memory wasn't having it. Now I'm too old to put down the required hours to relearn and get back up to speed.
Here's some advice from a Norwegian who programmed in Vim for years on the nordic layout: do yourself a favor and get an American keyboard ASAP. The brackets alone are worth it.
It's really not, so long as you map hjkl to the appropriate key sequence on your keyboard. Everything else is based on mnemonics, not locations, so I is just I.
Maybe some stuff might be quicker because it's on the first layer, but if it's so bad you can map those specific keys.
I like Helix, but it feels slow compared to Neovim. As in the actual scrolling performance. No one else has mentioned this, so I wonder if that’s an issue on my machine.
> Those are by far the most important features for a text editor to have
The most important feature of an IDE is to be easy to use, having powerful functionalities is important too, but that's goes after..
VSCode has nailed the first point.
Wake me up when (neo)vim/kakoune/Helix has a "list of tab view" similar to VSCode..
99% of my neovim usage is not programming, and either way I have never found syntax highlighting and similar to be all that important. Text editors need to view and edit text, and do it well. That's about it.
Have you checked what that unsafe code does? Unsafe code is not bad per se, there has been quite a bit of discussion about the naming of unsafe and many are of the opinion that it should have better been called something like trustme to clarify that the code must not be necessarily unsafe, just that the borrow checker doesn't fully check here, which for certain core algorithms can be necessary.
As long as the content of those blocks has been carefully checked there is no problem with using unsafe.
> just that the borrow checker doesn't fully check here
That's incorrect. The borrow checker performs the same checks inside `unsafe` blocks as everywhere else.
`unsafe` blocks can perhaps best be summarized as areas of code where memory safety rules are relaxed. The borrow checker deals with ownership, and ownership rules are still fully enforced inside `unsafe` constructs.
> just that the borrow checker doesn't fully check here, which for certain core algorithms can be necessary
Why is that? Does this imply that there are certain algorithms you simply can't write (efficiently) when using the borrow-checker? (I don't know Rust btw, but have plans to start learning very soon)
Missing some nuance, but that description is not too far off. The ownership/borrowing concept is based on the idea that every piece of data has a single owner. Particularly in cyclical data structures, it's not very clear who should have final ownership over what. This can make graph-like data structures somewhat difficult to express.
I have been trying out Helix for the last few months as part of my now 24 year quest to incorporate some form of vi into my daily routine. This time, it's looking good. What sets it apart are the (zero-conf) built-in LSP and tree-sitter highlighting, and the select-verb modal keybindings instead of vi's verb-object syntax, where you see what you're about to do before you do it. Some of the key combinations also show a reminder menu, aiding the learning process, which is a nice touch over plain old vi which has zero discoverability. General performance is also very good, the editor feels a lot snappier than a fully loaded Neovim or Doom Emacs, or a monster like Visual Code.
I think there are plans to see if a graphical editor could be built on top of it, which would be an interesting project. As a new Rust graphical tree-sitter based editor, it would probably rival the upcoming open-or-not Zed editor by the Atom folks.
Man, I don't know what has happened but the spur for new editors has.been delightful. I have been using Zed for a bit since I made it into the closed beta, but it has been very nice to use. VSCode does the job pretty well, but it just feels more clunky to me, and I have hitches quite often. It is not bad, but I want something more performant while giving me the style of vim and emacs. Zed definitely has some rough edges and some sorely missing features (that are being worked on), but it just feels better to use.
I know so many people probably discount these projects because of the RIIR meme, but it really has spurred more inovations that we should all be grateful for.
RIIR doesn't scare me at all -- as a user, my experience has been the rust rewrites are usually high-quality improvements over the original. Ripgrep is legendary!
It is a huge accomplishment of Rust to enable the creation of better versions of lang-standing highly-optimized-C tools.
(Which inspired me to kick the tires a bit on the language; it felt like C++ done right to me. Being able to write threaded code w/o fear of data-races is very cool.)
I actually think that the place where it could potentially really shine is when you have to do remote shell work. I don't know if you can specify the runtime folder but if you use it as a simple replacement for nano on old machines that don't have a proper editor this would be perfect.
vscode is very good at this, and is the primary reason why I even use it.
Frankly speaking the vim/emacs lines are yet to catch up with this sort of thinking. vscode feels like you are editing on the local machine. The experience is seamless and feels magical.
Tramp in all honesty was not that seamless, its just that these are great editors, but they were not invented in the context of the overall changes in how programming is done today. To me the biggest plus of emacs/vim is they make it easy to navigate and manipulate text, that's pretty much it.
Every other feature seems to be an after thought therefore is not subject to the same experience the modern editors have. They also have a huge learning and set up time, and can send you down configuration hell for lots of things.
Emacs is completely programmable so I don't think it needed to be invented for these specific use cases. The entire point is that you can program it to do what you want it to do!
Emacs can certainly be a little clunky at times though which can put a lot of people off. It does take some configuration and tuning for your personal preferences to feel good, but the upside is that it can do way more than the alternatives can do if someone/yourself puts in the effort to implement it. Magit is a great example of such a thing, the interface and functionality is extremely nice, even compared to something like Intelli-j's git GUI which is a pretty impressive feat!
With that being said it's not for everyone (and that's okay)!
I can't vouch too much for it as I've used it for maybe 1 hour tops, but the remote capabilities of vscode were pretty seamless for that one hour.
Emacs+Tramp definitely does not feel like you're editing locally. A surprising amount of things work, but many others will fail in annoying ways or are just clearly not supported.
Helix author here: I think the poster chose an unfortunate headline.
1) Helix was written to replace my neovim setup but is in fact kakoune inspired.
2) It's written in Rust but I don't draw focus to it precisely because RiiR/"X in Rust" posts are getting a bit tiring to see.
Directly, I believe this has more to do with people interested in the language seeing it being used in actual projects.
Indirectly (a lot indirectly), sure. Maybe the software should perform better or maybe have fewer bugs because programming language X or Y is understood to help with those things. Maybe it showcases a more flexible architectural design, which leads to more potential features in future versions, etc.
It also hints at the mindset and values of the creator. Communities around languages value things that may or may not line up with the qualities of the language they form around, but simply the fact they value those things is reflected by rhe things they produce. If people think a language is performant, then performance will be something their community values. If it is known for having a learning curve, their product might too.
Yes, because if it's a language I'm comfortable in, if there's a bug I can hop into the code and try fix it myself. I find this happens most often for me with Flutter projects to be fair.
Yeah, it's a tool targeting developers. The language matters to a certain subset of people who don't throw their arms up and move on when they encounter a bug.
Technically no, but quite often they are easier to install and tinker with than C/C++ projects (for instance usually you just need to clone the repo and run either 'cargo build' or 'zig build', and it mostly 'just works' no matter the platform).
Some C/C++ projects which have switched to cmake are equally easy to build (well not quite: "mkdir build && cd build && cmake .. && cmake --build ."), but it's definitely not the norm.
Yes, it's a useful indicator of how portable the software is. I can ignore systems software written in Rust because it only works in places that LLVM targets, and extending LLVM is a nightmarish process. I can ignore software written in Zig because until this year (or arguably last year) it's been a one-man hobby project, worth checking on again in about a decade. For now there are too many weird bugs that pop up if you use platforms different from the main developer. "Written in Go" means I at least have a chance of fixing deployment problems, becausae crosscompiling is easy and the language is fully self-hosted.
For an editor? Makes a lot of difference. The day intellij ide is rewriten in non gc/dynamic language, there will be a noticeable improvement in performance and number of times the ide has to be restarted because it ate all the memory.
Right, except for libraries or language-specific toolchain, the only legitimate reason to mention language in the title is to suggest doubt it was possible.
Hey ncmncm, I know this is off-topic, but I just wanted to say that I really enjoyed your informative comments on high performance low-latency architectures. I was wondering, could I ask you a question via email?
- Rust is a systems-level language and requires developers to be experienced in order to create big software components. This usually leads to better quality.
- Rust rewards putting effort upfront (e.g. error handling, Option<T>, ...) leading to less bugs than more forgiving languages.
- Rust uses zero-cost abstractions which enables efficient code. In other languages it's a lot easier to degrade your performance by accident.
- Rust can easily create binaries for the most relevant architectures, so your programs tend to be portable.
- The contribution story is great, your code tends to be correct and you don't need to watch out for many foot guns. I've done it myself for Helix and the experience was awesome [1].
But take everything with a grain of salt, you can create bad software in every programming language.
We don’t provide the ‘easy to program for’ console that (developers) want, because
‘easy to program for’ means that anybody will be able to take advantage of pretty
much what the hardware can do, so then the question is, what do you do for the
rest of the nine-and-a-half years?
Super cool to see another competitor in this space. There's no support for tabs, I really hope it's coming and they implement them in the same way vim does. So far the buffer/window implementation matches vim (as far as I can tell), so I really hope the tab implementation matches as well.
If they could implement the client/server architecture of kakoune, then this would really best editor (for me). It's a shame each editor implements a different subset of all the features I like and I'm always choosing between them.
Edit: Looks like there's an issue for tabs: https://github.com/helix-editor/helix/issues/2295 , doesn't have too much traction. I hope someone picks it up, unfortunately my rust sucks far too much to get it done in any reasonable amount of time.
Kakoune has a client/server mode so that the client instances can talk to the same server. This way unsaved changes to a buffer are visible across instances + all the registers etc are shared.
Helix doesn't have that functionality. Kakoune also doesn't have splits at all where as Helix does, so the design philosophy is different between the editors.
Personally, I would prefer if tabs were first class citizens in the editor, but would make do with scuffed tabs if there was a server/client model implemented.
I have not tried the editor itself, but one thing that puts me off is how some people are claiming its going to replace vim/nevoim and others by the virtue of its great LSP and tree sitter support. I am working as a full time developer for the last 4-5 years and I never needed to use auto complete (for long words C-x n is there) and the current syntax highlighting seems fine. Vim is working great for me and I don't feel any reason to switch to others. Instead of bashing other editors, maybe just tell what makes your editor unique and why people would want to use it?
> by the virtue of its great LSP and tree sitter support.
> maybe just tell ... why people would want to use it?
Apparently they did tell you, and you’re not interested. Fine, but what a pointless comment. Rob Pike will also tell you how he loves coding without syntax highlighting, which you apparently find useful.
It's not a "pointless comment". Why would someone want to use it every day over Vim or Neovim? The only benefit of Helix specific to LSP and tree-sitter is the ease of configuration, a mostly fixed cost. Then what?
That would be a reasonable comment, and people have been discussing that in this very thread. The one I replied to is "I don't use autocomplete, so you didn't tell me what's good about this editor, except you actually did and I even acknowledged that". Pointless.
When you say you never needed LSP, do you mean you've tried it and found no benefit to having it, or do you mean you're doing just fine without it? (Because its possible to do just fine without it yet still find significant benefit to having it).
What LSP does for me is instant documentation integrated into the editor and getting constant feedback if you get it wrong (at least from a typechecking perspective). I guess that in many cases, you can get something similar by having a documentation window open on the side as well as automated unit tests in a second terminal re-running on every save.
I have tried using it few times but I didn't see much benefit of using it, I am mostly working with python/django/javascript/react and by now most of the common functions I already know, so I didn't see much use of it and tbh it felt a bit distracting to me when a big hover definition came when I am typing something.
The times when I don't remember how something works, usually I have to go the stackoverflow answers/documentation to read on how it works, maybe try it out a few times in the shell, before writing the code. For typechecking and errors I have been using ALE and it does give a warning if there's something wrong and this setup is working fine for me.
I feel you. Vim has been such a staple in my dev life. So much that switching felt like betraying sweet uncle Bram ;-) And without the need to write typescript, I probably wouldn't have switched. But what made me stay even for non-typescript work were the little things, like the positions in the location and quickfix list being auto-updated while editing, being (feeling?) faster and more responsive, the saner default settings (server usage) etc.
Regarding lsp integration, it's just nice to have project-based instead of buffer-based auto-completion, auto-insertion of import statements etc. Definitely makes me more productive. Setting it up the way I wanted (non-obstrusive, on-demand) was a bit of pain though.
I use vim with ale. Linting, go-to- definition etc. for typescript (or really any other language I use) just works automagically. It took more effort to get it working in vscode. I haven't tried neovim or helix yet. They both seem great, but it seems to me that people here might be slightly exaggerating the difficulty of getting this working with regular old vim.
Well, I tried ALE and it worked ok. Compared to the neovim built-in lsp client it just doesn't display as much info and does not support multiple hints per line. There's also CoC which should also work with regular vim and which I've used for a while, but it wasn't very stable for me (the auto-insertion of import statements made it crash frequently for example). The built-in lsp client seems to be the cleanest, fastest and most stable implementation. Using nvim-lspconfig it was fairly easy to set as well. It just took me a while to find out how to disable all the distracting live-/auto- completion, underlining, inline-hints etc. (vim.diagnostic.config)
For a long time I had the same opinion (using Sublime Text with its plain same-file autocomplete). It's okay, but after using LSP for a while, I'm sold on it. It really is nicer, and I wouldn't go back to my pre-LSP times.
"Go to definition" and "Find references" is faster and more precise than grepping, especially for common function names. This lets me browse larger codebases, even if I don't remember their layout.
Being able to peek at actual types of variables is quite useful in Rust which has type inference. I can check types instead of deducing issues out of compile errors.
LSP support for like "Extract into function/module" are great for refactoring eliminating most of the busywork. Renames are also more reliable than find'n'replace, especially when I'm renaming because the name is ambiguous.
He very explicitly stated what about the post was off-putting to him. You made a comment about being personally attacked while repeating the tool is better without any argument whatsoever.
You're exactly proving the point of the comment.
And the part that they listed as "off-putting" was a very tame and popular sentiment, to the point that it's off-putting itself (or at least bizarre) to be "off-put" by it.
Not to mention that the whole comment is based on a bizarro claim amounting to "who needs LSP/treesitter anyway" and how they can't see the point of those (probably the most requested features from any new editor), since he "never uses autocomplete".
Still, "I can't see the point for feature X" and "I never use X" are totally fine. But saying that people saying they appreciate them and consider them important is "off-putting"?
No, they contextualized that these improvements aren't actually improving anything for them, as they're not actually interested in using these features. And thus, it's no longer a better tool for them.
>He is saying that these tools aren't improving his dev process and therefore are not better for him.
That would just be a personal preference thing, and it would be fine if they just stated that and left it at that.
But they also mention how they are "put off" (wtf) from people who claim that the LSP/tree-sitter support makes this a viable candidate to replace vim/neovim.
Saying you're being "put off" by what others use, is no longer a "this is what works for me" claim. In this context, the "I never needed to use autocomplete" sounds like some ill-conceived bragging point.
The commenter stated clearly that they are not put off by what others use but their claims that their shiny new toy is going to replace everything in a couple of years. Those people are just trolling; trolls are off-putting.
>Those people are just trolling; trolls are off-putting.
Trolling means saying something you don't believe in to start a ruckus/annoy people/make a flame war.
People saying that an editor done in the spirit of vim can replace vim/neovim, since it has LSP/tree-sitter support (which translates to: since it, on top of what it inherently has, automatically gets auto-complete/lint/etc support for all kinds of languages) is perhaps a little over-optimistic but in absolutely no way does it constitute trolling.
Now, the commenter would be fine to state that they're put-off by claims that "this is going to replace everything in a couple of years".
But, for starters, nobody stated that "it is going to replace everything in a couple of years". Just that it could, over due time (not "a couple of years") gain traction over vim/neovim and perhaps others for users wanting a vim-like editor.
Besides, he explicitly wrote that what puts him off is not that claim alone, but "how some people are claiming its going to replace vim/nevoim and others by the virtue of its great LSP and tree sitter support".
-- that is, he is put off people touting "LSP/tree-sitter" as features relevant to this editor gaining popularity. He even uses "I never needed to use auto complete" as some kind of supporting argument that others shouldn't consider those features important either...
> Trolling means saying something you don't believe in to start a ruckus/annoy people/make a flame war.
No it doesn't; please don't make up word semantics to try to make people look wrong. It's childish and pointless.
A disruptor cannot be absolved of trolling by it being confirmed that they believe in their own statements; a good many trolls are invested in their message, not just in disruption activity.
> nobody stated that
The put-off person was relating experiences from elsewhere to which you have no access to be able to say that. But in fact, I think I saw very similar remarks in comments under this very HN submission.
Some people are put off by trollish OS/language/editor/hardware/whatever advocacy. And water is wet, and dogs bark.
> how some people are claiming its going to replace vim/nevoim and others by the virtue of its great LSP and tree sitter suppor
That literally means "the outdated shit you're using ain't gonna be here before long, now that we have this", which is trolling even by your definition that incorporates disbelief in one's own statements.
>> Trolling means saying something you don't believe in to start a ruckus/annoy people/make a flame war.
> No it doesn't; please don't make up word semantics to try to make people look wrong. It's childish and pointless.
OK, this conversation doesn't have a point anymore. I make up "word semantics"? What I described is the canonical definition of trolling. Don't believe me? Here are some third party one's:
Cambridge dictionary: the act of leaving an insulting message on the internet in order to annoy someone
Urban dictionary: Trolling – (verb), as it relates to internet, is the deliberate act, (by a Troll – noun or adjective), of making random unsolicited and/or controversial comments on various internet forums with the intent to provoke an emotional knee jerk reaction from unsuspecting readers to engage in a fight or argument
Merriam-Webster: to antagonize (others) online by deliberately posting inflammatory, irrelevant, or offensive comments or other disruptive content
In any case, nobody knowing what a troll is and hiw it's used would consider people saying "this editor as is, and with the aid of LSP/tree-sitter support it has, will gain adoption" fits any definition of a troll.
That's even if we consider people posting stuff they sincerely believe as "trolling". If the intention is not to mock/insult and get a reaction out of those reading the message, it's not trolling.
Those people are just optimistic for some new tech. That's a dime a dozen in HN and tech forums or blogs. At worse they're hyping it (like the Nth "X in Rust"). All of this has nothing to do with trolling
So, I don't know what bizarro definition you have. If you do have one, do share it.
See I am not against newer tools, I am using a lot of newer tools myself like fd/rg. What I am against is claims like "Ths new tool will replace everything else that has been made". Let people decide what works for them and choose accordingly.
I gave Helix a try last week and I think there are a lot of things to like about it, but until it supports soft text wrapping for prose documents it's effectively useless to me. I'm not going to bounce back and forth between neovim and helix depending on whether I'm editing code, documentation, or personal notes.
The comments on the open issue in Github are not particularly encouraging.
As far as I understand from scanning the PR, there's been more than a year of discussion with no actual progress on a basic (if not in this case simple to implement) feature which is universally available in text editors. Helix looks nice in many ways (I installed it last night and have worked with it on a couple of Rust projects today) but it's clearly more of a research project with potential than current practical tool.
I'm a big fan of open source software and have tons of respect for any OSS developer, regardless of the software he/she develops.
But I have to say, as a developer who has been taking part in the OSS scence for the last 20 years, it is very strange to me that some developers feel obliged to indicate they wrote a piece of code with Rust.
If I'm a user, I care much more that this is a usable software than what kind of programming language was used. For all I care, write it in binary.
Rust may be a great programming language, but it is only a mean to an end.
I can think of several ways this is useful to know:
1. As OSS software, some users will want to edit the code and add features, and knowing what language it’s written in is a pre-requisite to doing that.
2. The developer community is an important factor in making OSS projects successful. If I’m going to take a chance on a young project, I want to know that it is set up to have a strong community and continue to be improved over time. If it was hand-written in binary or assembly as you suggest, there is no chance it would grow a popular community of developer contributions.
3. Like it or not, different programming language communities have developed around different values in how to build software. The Rust community generally promotes strong type safety that makes entire classes of bugs much less likely which is a plus to me as a user.
4. With editors in particular, the language it’s written in often leaks into the user experience. E.g. Emacs is written and configured in Lisp, Vim has a ton of legacy cruft in the C and vimscript codebase that can make it annoying to compile/install, annoying to build plugins for, and has made modern features like asynchronous tasks difficult to add, which was the whole reason for neovim existing. VSCode has plugins written in JavaScript. Knowing this project is written in Rust gives me some hints that it probably won’t share any of these similarities with these other editors.
See also Lapce, an editor also written in Rust although it's trying to compete more with VSCode rather than Vim.
Also, RIP OniVim 2, it was great having been written in a similarly fast ReasonML/OCaml but the creator ran out of funding and had to get a job. A shame, it even had compatibility with VSCode extensions.
Lapce is looking really promising IMO. It's very fast, has single-click support for a few languages (Rust of course) and the UI is surprisingly complete.
Obviously there are still a ton of paper cuts but it's still very impressive and they are very welcoming of contributions.
The only thing that concerns me slightly is that they're using their own fork of Druid which was pretty much labelled a failed experiment by its primary author (though tbf he still seems to be working on it). On the other hand the UI mostly looks and works really well! I've only noticed a couple of niggles - misalignments, labels not linked to check boxes, ugly context menus on Windows etc. (and that last one is mostly Windows's fault).
Oni was presumably dead in the water as soon as they switched from Neovim to vim, as the initial backers would have been primarily composed of neovim enthusiasts
Does anyone happen to know if there is a terminal IDE that more or less operates like the very basics of popular GUI IDEs? By this I mean has a file manager pane which can be manipulated by mouse, allows multiple open tabs which are selectable and closable by mouse, is generally mouse-aware with regard to cursor activity on the text, and operates as a regular user would expect (not modal)? The closest thing I've found to this is Micro, but the full IDE experience is missing.
I know mouse-aware file manager and tab capabilities are possible in terminal IDEs, but I haven't seen anything that simply put it all together as a cohesive and easy-to-use whole that anyone who has used VSCode could quickly start using for basic editing of multiple files in a project.
Not OP, but I get their frustration. File browsing is not very amenable to keyboard based navigation IMO. I'm currently using fdfind through telescope.nvim as well as another neovim plugin for this, but I can easily see why someone would want to use a terminal based text editor, with a mouse based file navigation tool.
Not to shove Emacs into a Vim thread but Emacs file browsing is actually pleasurable. You can have a tree if you want (neotree) but C-x C-f with Ivy fuzzy search makes navigating really easy. It's one of the things I wish Vim had for a long time and one of the things that eventually drew me away from Vim to Emacs.
Anyway, to add to your point there are also cases where highlighting a large chunk of code is often easier with mouse based nav.
I love to see that Helix tries its best to ensure an out-of-the-box experience, as well as to add so many interactive hints for key combinations (for example when you want to paste in insert mode with C-R it’ll immediately list a set of registers that you can paste from).
However Vim is much more to me. It’s not just an editor, but a keybinding that I can use not only in nain, but also in VSCode, in fish shell, and even in GHCi REPL.
How long would it take to make them all support (some reasonable subset of) Helix?
Helix is great! The out-of-the-box LSP for C++ is a major strength, no config needed for me compared to 100% of all other editors I've used. The context-aware popups are nice too, and the overall UI is snappy and fresh. Highly recommend if you are a fan of modal editing and willing to try something new.
They not only change the keybindings, they change the editor paradigm from a verb-noun model (dw = delete word) to a noun-verb (wd = select word, then delete) model. Multiple cursors also have an effect.
It's pretty close to vim keybindings, but the paradigm change makes it incompatible with 1:1 keybindings.
That said, coming from 15+ years of Vim, I was felt pretty much immediately at home with Kakoune, and dropped right in to Helix with comfort.
I went into this expecting it to be another toy editor that someone was showing off. But no, this thing is legitimately impressive!
I had just been messing around with my neovim config because of that Leap plugin that was posted here. I decided to also install and configure the Lua language server because I wanted to try switching away from Vimscript for my init file.
Since that file was still fresh in my mind, it was the first thing I opened after installing Helix, and to my surprise it immediately showed me warning markers in the gutter and moving the cursor over the underlined symbol showed the langue server's complaints. I love that it just worked from having the language server installed!
Also while messing with neovim yesterday I was thinking about seeing if there was a plugin to show possible operations after pressing the leader key, like what you get with Spacemacs. I decided to try hitting the spacebar in Helix to see what happened and was impressed to see that it popped up with a menu showing how I could continue my input.
I'm sure I'll run into annoyances after using it for a while, but damn does this project leave an excellent first impression.
Quickly tried it out and feels quite good. Unfortunately I also have to use IntelliJ, where I use the Vim-Mode (IDEAVim plugin) and I would have a hard time toggling my muscle-memory multiple times a day...
does anyone know of any plugin which does the same as the IDEAVim plugin? I'd like to try this kakoune based layout in intellij for the same reasons but this is a bit of a blocker if I have to keep flipping between vim and kakoune bindings.
Felt more responsive than neovim/neovide, and out-of-box was great.
However, while the selection > verb scheme conceptually made sense, I noticed it took longer to do many basic text editing functions than it would with vim bindings. Perhaps others had a different experience?
I've used Helix since February, and vim for 20 years prior.
For basic edits it's roughly on par now for me (maybe a bit slower?); but then Helix has really neat tree-sitter integration, so as I'm getting more and more used to that, I find myself jumping around code faster and with more precision.
I also never have these moments of fat-fingering a key and then have vim go nuts on me. Like I suddenly deleted half the function and ended up in some mode I've never heard of while doing a recursive recording. ... just mentioning that because I believe (but not sure) that it's because of this selection > verb scheme that I don't ever see that happening in Helix :)
Can someone help me with how to make a caret in insert mode to line instead of block? Most themes are just block cursor both in "read" and insert mode, hurts visibility.
The FAQ currently mentions that they're planning on implementing a LISP dialect. I wonder why they chose that instead of an existing language (e.g. Lua, Tcl, or Guile)
I don't understand why "in Rust" makes these irrelevant posts somethign worth of the HN frontpage. All it means is that you won't be able to compile it yourself unless you use a fast rolling distro or out of repository tools to get this month's compatible rustc with rustup or curl|sh, etc.
I've tried helix and it doesn't seem as customizable as neovim/vim. I also prefer neovim/vim's default keybindings much more. While I can't see helix replacing neovim/vim, I can see people using it, as it has defaults that could appeal to some people. It's also fast.
From the description, the architecture is nicely modern.
It's also interesting to see a project that seems young to already be version 22.
What I tried to find and could not was some built-in language, more expressive than the one used to describe syntax highlighting. This means that extensibility is at best not a priority,
FWIW, the maintainers have been exploring various extensibility solutions. For e.g., I remember seeing a PR to allow a WASM-based plugin system, though I think it was abandoned because of the tradeoffs it posed.
I am currently almost entirely developing in Go. And for that I have a highly customized Vim environment, which really took me a while to get to where it is right now (it works very well, thanks to the great 'vim-go' plugin). Nonetheless, I am starting to have to develop more stuff in other languages like js and Elixir, and I definitely do not want to invest all that time tweaking my vimrc to have all the IDE bare functionality that works so well in Go. I was starting to consider making the transition into neovim, but Helix sounds almost like a plug-and-play solution with sane defaults (which is exactly what I would like to have). Is it better that I go for Helix, or is LunarVim or AstroVim actually what I am looking for?
Helix is a simple install, easy to give it a try and see what you think. For most people, there’s no configuration necessary to get started. I jumped through the hoops to get C++ tools in a variety of editors, and nothing was as simple as Helix for me.
I gave it a try out of curiosity with Rust, which you might reasonably expect to be well supported. But it didn't start a language server. So I followed the docs to find out how and was none the wiser. A tad undercooked, I'd say.
I'm sure that nvim-lspconfig doesn't take care of installing binaries for LSP servers like this. You either set the path to the binary in your config, or you are using another neovom plugin to make sure LSP server binaries are installed
No you're right it was mason, which installs lsp servers to a location it manages. I had set it up once and then forgotten. The complexity of all the interacting packages needed with neovim does add to helix's appeal.
This, people say it's no configuration but I had no idea how to make python work, and that's even after I got l figured out I had to --install-grammars our whatever the command was.
I already use this as my daily driver for everything, especially writing code. Have been using it for a few months. It gets better with every release. I love it.
It's got a few quirks. Trying to navigate while in insert mode (I know bad habits die hard) will have you undoing a lot of unintended autocompletes unless you turn LSP off. Tab to complete is a must for autocomplete features, and it should never autocomplete in comments or a completed line of code.
So a little rough around the edges, but still wonderful to use.
Played around with a bit. In my experience compared to a configured vim:
- once you have your local language servers available it works quite nicely out of the box. syntax highlighting, file finder, lsp navigation, formatting, etc. just works
- its fast
- i really like having the order of selection->action instead of action->movement
- im still missing some features like a navigation tree and a quickfix list or something to do project wide find/replace.
On of the things with vim/neovim for me what was a deal breaker is that you could not turn off/on LSP's for different projects. So neovim got slow for me.
I also don't wanted to copy my config for each project.
For what it's worth, you can definitely disable autostart conditionally in nvim-lspconfig, maybe using on_new_config and setting autostart=false therein.
IIRC the plan is to migrate the core logic into a library that can be consumed by either a CLI or GUI. There were also some discussions of collaboration with the Neovide folks, something that I personally found very exciting as Neovide is an excellent Neovim client.
However this was last year, not sure what the current status of all this is.
One of the reasons I love n/vi/m is the ergonomic benefit of using keys that are close to your touch typing position. I'm a bit disappointed that beginning and end of line in helix are home and end.
You can also use `gh` and `gl` for start and end of line (and `gs` for first non-whitespace character in line). These options (among others) pop up when using helix and typing `g`.
I get it - so 't' is 'to' and enter is new line. Makes sense.
The menu under `[` looks good, but very code-focused and lacking sentences.
EDIT: I am finding it a bit weird to have 'go to's as different to movements. There isn't a distinction in vim, which is useful. I'm learning that 'ge' will take me to the end of file, but I can't do 'ged' to delete to there.
Looks great, I've aliased vim to hx as muscle memory. Will give it a test, I'm guilty of having lots of stuff installed on vim I don't really know how to use (or even vim's full power)
I've used vi from Linux terminal sessions for more than a decade, and VS Code as a GUI editor now most times when not in a terminal session.
Am I missing something not using a GUI vi editor? I came across some dude on YouTube that calls himself "The Primeagen" that swears by VIM, but I couldn't follow his use of it.
I wouldn't even say 'like', it's just that I don't see a big enough advantage to switch. I built up enough muscle memory over the years and while helix might be slightly better (I don't actually know how much better, but I tried it and the impression I got was that it was at most only slightly better), that slight improvement doesn't really make up for the cost, which is being really slow for a while until you get used to it. Also you're giving up all your plugins. Also, you're giving up universal support in pretty much every other editor, since there are vim bindings in emacs, vscode, visual studio, jet brains ides, xcode, etc.
Vim isn't going anywhere, so it just makes more sense for me to continue using it. Maybe for new people they could get into helix? I love that there's more options for people and I hope they can cross-pollinate ideas. But it's a hard sell to be honest.
Seems like we agree! I don't think there's much need for people happy with the existing Vim layout to switch, and Vim is still a very serviceable editor. My comment more spoke to my personal tastes around editors. :)
I don't particularly like vim keybindings - actually the very fact that they become so much of a consuming hobby for many people speaks to me of real problems with them. But their availability in so many tools aside from vim/nvim makes them very practical, given things as they are. It's a bit like QWERTY. Ubiquitious presence can be more practically useful than intrinsic advantages.
Installation was easy and the default configuration is good. Plugging in rust-analyzer still needed a line or two of config file editing, but that should not be necessary for very long. Hint: use `hx --health` to check that all the tools are properly installed and configured (it shows a matrix of programming languages and their associated tooling, with red/green check marks).
My Helix config file is about 5 lines long, but my Vim config is in the hundreds of lines.
I had very little friction coming from Vim and a little bit of Kakoune.
I particularly like the fact that all the important features are built-in and not half baked scripts with unintended side effects (e.g. opening a Makefile in Vim triggers a ftplugin script that messes editor-global config instead of buffer-local, with the default out of the box scripts).
Lots of people are requesting a plugin extension system, which is kinda understandable since every editor seems to have one. But I haven't had a need to add any kind of plugin, and it's easy enough to fork a shell for an external process if needed.
It's still rough around the edges, but good enough for a daily driver.
Thanks to everyone working on the project.