Helix: A Neovim inspired editor, written in Rust
github.com
github.com
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.
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.
[0] https://github.com/helix-editor/helix/wiki/Migrating-from-Vi...
I find it immensely helpful that Kakoune and Helix _make sense_. It is also a great boon that there's visual feedback.
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.
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.
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.
If we use | to mark our cursor, and you have your cursor inside quote: '"he|re"'
ci" would replace everything inside giving you '"|"' and putting you in insert mode.
cab would aso remove the quotation marks and give you '|'
With ce or cw you'd get '"he"' and cE or cW would give you '"he'
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.
My hx doesn't wrap lines, so didn't check `gj` and `gk`.
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. :)
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.
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 also don't remap anything. It's fiiine. You'll get used to it :-)
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.
Yes, indeed.
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).
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 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.
P.s. I'm hoping to eat my words one day.
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).
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.
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).
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.
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.
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.
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.
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.
One time setup cost is a small factor in choosing an editor. Stability and ubiquity are more important IMO.
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.
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.
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'd say that those features are useful for source code editing, not text in general.
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.
Ergonomic keybindings would be a challenge though.
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 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.)
Sadly, that achievement is compromised by having to call into unsafe code.
As long as the content of those blocks has been carefully checked there is no problem with using unsafe.
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)
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.
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.
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?
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".
I agree with you in principle, but in practice I’m not convinced this is an insurmountable hurdle for other editors.
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.
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.
I assume helix will be constantly evolving those ten or twenty years.
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.
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.
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 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.
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.
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.
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.
https://www.farah.cl/Keyboardery/A-Visual-Comparison-of-Diff...
And for me I'm pretty sure that this "remap everything and translate every tutorial" barrier is why I never have been able to get into vim.
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 ).
Here's a photo of the layout: https://image.shutterstock.com/shutterstock/photos/279261125...
As an Argentinian, I've no fucking idea why we have our own layout instead of just using ISO Spanish.
It doesn't look terrible, but believe me, switching to US English International was a one-way trip.
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..
Usually I have between 10 and 20 tab opened, so the tablist is very helpful for navigating between tabs.
Unfortunately (AFAIK) the 'fast' editors (vim, kakoune, etc) don't provide such feature. Some have a tree list but not a tab list :-(
Edit: sorry, it’s actually :ls
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
vim: $
helix: gl
vim: D
helix: vgld or t<ret>d
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.
[0] https://github.com/helix-editor/helix/wiki/Migrating-from-Vi...
https://github.com/LGUG2Z/helix-vim/blob/master/config.toml
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).
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.
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 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.
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).
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.
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.
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.
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.
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.
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.
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.
Ah, this old chestnut.
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.
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.
Well..you just made the argument to stick to Neovim which already does this.
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.
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.
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.)
My guess is that 4coder kicked all this off.
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.
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.
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 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)!
> vscode is very good at this
I'm sorry, but what? VSCode over ssh? Huh?
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.
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.
Thanks!
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.
- 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.
Ah the old PS3 argument ;)
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?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.
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.
> 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.
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.
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.
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.
"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.
The comments on the open issue in Github are not particularly encouraging.
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.
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.
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.
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).
In fact, I was such a fan that I bought it, which has turned out to be a rather foolish move. The people behind it have gone completely silent.
[0]: https://news.ycombinator.com/item?id=30952084
[1]: https://daringfireball.net/linked/2020/03/20/mac-assed-mac-a...
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.
Next thing you know... you have warp stories in your terminal.
Anyway, to add to your point there are also cases where highlighting a large chunk of code is often easier with mouse based nav.
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 has 624 open issues (1,103 closed) [0]
- Vim has 1,172 open issues (5,518 closed)[1]
- NeoVim has 1,258 open issues (7,496 closed)[2]
- VSCode has 7,463 open issues (136,638 closed) [3]
[0] https://github.com/helix-editor/helix/issues
[1] https://github.com/vim/vim/issues
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.
gl end of line
Both key presses are home row, and as soon as you press the 'g', you get a little pop up telling you about them.
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.
I need to run my code in one pane and send commands to a console in another pane. I use this feature at least 100 times a day.
edit: it does work with tmux
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?
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 :)
https://news.ycombinator.com/item?id=27358479 (657 points | 1 year ago | 365 comments)
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,
It also only works on Rust projects, not single files. You have to open helix with the path to the project folder for it to work.
Documentation is missing, it's a bit scattered
Not sure if this is still necessary, but I needed this workaround in ~/.config/helix/languages.toml:
language-server = { command = "rustup", args = ["run", "nightly", "rust-analyzer"]}
From a brief experiment basic lsp usage seems to work in helix without any config changes, so perhaps that's changed since you set it up.
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.
- 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.
https://github.com/helix-editor/helix/blob/master/screenshot...
Does Helix have a solution for this?
However this was last year, not sure what the current status of all this is.
EDIT: while I'm here, where are the sentence and paragraph movements?
edit: Paragraph and other object movement/selection is done by the `[`, `]` menu. `]p` for the next paragraph. Surrounds are done by the `m` menu.
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.
EDIT: Oops, you weren't replying to my 'dd' question. Sorry ignore me. Though if you know the equivalent of 'dd' in helix I'd like to know...
I don’t wanna spend hours on configs so I really like its opinionated defaults
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.
theme = "bogster"
Next up: keys suck. I often use dw or d/something and these fail. Any quick way to resolve?
It does not sound like that has your interest. That's fine. Stick with vim.
Do we have elf64 static binaries of this compiler? (with minimal usage of syscalls).
(For those who like the traditional vim binds, I salute you, but I have craved an upgrade for a while now)
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.