It’ll happen! It’s just a lot of work… That said, thanks for making rust-analyzer a joy to integrate with! It’s certainly been one of the most spec compliant language servers :)
It’s certainly been one of the most spec compliant language servers
Heh, that’s surprising. Our relationship with LSP historically was, ahem, adversarial, we shipped a tonne of extensions for missing bits and I still recommend people to sometimes, eg ignore the spec :)
Though, one thing we did early on is to outright crash and burn if we think we detect a spec violation. This allowed us to iron out a lot of bugs in many different clients, and even some of our own bugs :)
I want to like helix, but my brain keeps thinking this is vim and there are too many vim shortcuts I apparently use all the time that don’t work in helix - or are just different. Is anyone else experiencing this?
Basically two key bindings, the most important one being my test runner for the tmux pane next to hx. Helix does the rest. Works like a charm for Go and TypeScript (every day at $JOB) and the occasional Rust project.
Same. Muscle memory can be really strong. How cool would it be if there was a built-in tutorial where a text file is instructing you how to interact with it (maybe changing a simple block of text? Maybe a program in the coming levels), showcasing typical strengths of the highlighting-by-default flow, some refactoring, some search and replace etc.
I have been trying helix more and more. The subtle changes from vim keybindings are truly painful, but the undo is responsive. I need to come up with a better shortcut list, because typing the vim keybinding is one thing, not knowing how to do it at all in hx is another.
Also an Emacs user—and unlikely to switch—but I find that even the default settings of Helix are very comfortable and if I ever needed a text editor that didn’t require that I lug around a 500-line config file, Helix would be it.
Congrats! I switched to Helix a few weeks ago and it instantly became my primary editor. I’ve been running HEAD and it’s been a little bumpy (the odd panic) but devs have been incredibly responsive in fixing things up. I’m really impressed!
Helix looks really cool. I love that with a half page of configs, I can do 95% of what neovim needs 20 plugins to do.
There’s a few missing features, but are being worked on or are easy to work around (e.g. an in-editor terminal, lastplace/nvim-lastplace-style functionality).
For me, the bigger concern is relearning keys and patterns of editing without all the documentation that vim/nvim have accumulated over the literal decades. But I think maybe I just need to take the plunge and use it for a week, and things will start making sense.
Really impressed at the speed in which they’re adding features. I’m a big fan of key features integrated into the editor itself opposed to having a third party plugin system, everything just works out of the box.
Git gutter + bufferline were two things preventing me from making the switch, with every new feature this gets more and more tempting…
I still tend to get pretty confused between the kakoune editing vs vim but overall my experience has been positive.
Ah! I was hoping the file tree support landed in this release. In neovim I frequently use the file explorer (nerd tree? idk) as an interactive stateful find.
To me it’s not very clear what problem does Helix try to solve and what are the shortcomings of Vi/Vim/Neovim for solving that problem? I admit that I did not read very carefully the documentation of this project but I was expecting to get that information from the front page of the project.
code editor, rather than text editor: syntax tree is used for “text” editing and navigation (programming language aware “text objects”), built-in LSP for semantics-aware features
more out-of-the-box: default config is reasonable, more features are built-in, editor tries to help the user by providing more introspective contextual help on how to use the thing.
more hackable, by virtue of being implemented in a collaboration-friendly language.
Sorry but I’m not convinced that those are real improvements. Let’s take them one by one. First, I see no numbers to hold the claim that the new model is better than the old model. The thing that they give as an example in the link can be done in Vim with Visual Mode, more or less. So I would take it as a proposal for improvement, not as an actual improvement. Second, I would be interested in the complexity of implementing such a code editor. My guess is that it needs to “recompile” the code every time you make a change so that it can “reason” about your changes. This looks to me as an overkill for large files or large projects. More than that, old systems cannot afford this type of “recompilation”. Third, I don’t understand your point here. Why more is better? Fourth, call me unagreeable, but I don’t buy the Rust propaganda. Every project in whatever language it is implemented is “hackable” and all programming languages are “collaboration-friendly”. I’m curious what you think about this.
I am not trying to convince you, you do sound like a person quite happy with vi, and that’s perfectly fine! It feels like helix solves the problems you personally don’t have. But I am pretty sure these are real problems for quite a few people (and I personally definitely acutely feel all of them).
Re editing model: I personally wouldn’t rely on numbers to make a decision here. To me, it’s blindingly obvious that what kakoune/helix are doing is much better. I’ve also heard enough stories from vim users who tried kakoune and got addicted. But, if you want numbers, it is better than vim at vimgolf: https://news.ycombinator.com/item?id=29984176
Why do that? To be honest, for me the biggest reason is aesthetics: everytime someone opens an .html file in a text editor, html gets parsed with regexes, and that’s just horrible. See why an IDE for the list of most impactful things semantic understanding of the language provides.
Every project in whatever language it is implemented is “hackable” and all programming languages are “collaboration-friendly”. I’m curious what you think about this.
I do think that there are various degrees of collaboration-friendliness. On this axis, I think Rust (and Go as well, though I don’t have direct experience with that) is ahead of the average by a wide margin. One significant contribution is tooling: git clone $rust_repo && cd $rust_repo && cargo test works for 90% of rust projects without extra setup. For most other languages, it is “go read README to learn how we do things here, and then spend some time creating a non-hermetic dev environment”. The second significant contribution is that Rust is much better at interfaces (as “software components”, not as “dynamic dispatch”). This is most visible if we compare memory management between Rust and other sans-GC languages. In something like C++, every codebase has certain rules for lifecycles of objects, and its up to the programmer to ensure that distant parts of code agree on who frees stuff and when. This is a very significant chunk of project-specific knowledge, and is a barrier for contribution. In Rust, there are also project-specific rules about lifetimes, but then the compiler just tell you about them, you don’t need to bug the maintainer to learn how things work. But this goes beyond just memory: module&crate system is build around library as a first-class concept, different from a module, which helps tremendously with slicing large projects into independent chunks, and keeping the separation in place throughout refactors.
On a more anecdotal note, IntelliJ Rust and rust-analyzer are similarly very contribution friendly projects, but setting that up with Rust was loads easier than with Kotlin, as gradle is a trainwreck.
It doesn’t matter very much what editor I use, because I try to view the problem from an objective perspective rather than entering the war on text editors. If we fight over which editing style/mode is better based on user preferences then what we are doing is politics, not science.
Complexity and performance are crucial aspects in developing software. It didn’t work “perfectly fine” because since 2000 a lot of hardware was deprecated to leave space to solutions that did not take into account complexity and performance as their fundamental problems. See Google et al. for reference. The micro-economical factors that you are talking about are there for a reason, i.e. to let everyone use the software on whatever software/hardware stack they want. Aesthetics is a second tier problem in this case.
Your collaboration-friendliness point is interesting. On one hand you can argue that it’s easier for users to “just use” the project as-is without making modifications to the project, and on the other hand you have people that want to make modifications to the project and they need to go to the README in order to actually understand how the project works under the hood. It depends very much on who is your audience. But I would argue that the idea of open-source works better with the second approach.
Second, I would be interested in the complexity of implementing such a code editor. My guess is that it needs to “recompile” the code every time you make a change so that it can “reason” about your changes.
Helix uses tree-sitter under the hood, which is a fairly new project designed to enable incremental, fallible parsing. Basically, on every keystroke, Helix (through tree-sitter) efficiently updates the syntax tree it has parsed. There’s no compilation involved. Edits and selections work on ranges of text that represent pieces of syntax, like a whole function.
more out-of-the-box: default config is reasonable, more features are built-in, editor tries to help the user by providing more introspective contextual help on how to use the thing.
Third, I don’t understand your point here. Why more is better?
More is better because it lowers the barrier to entry for picking up the editor. I personally don’t enjoy spending a long time figuring out what Vim plugins to use and developing a config file hundreds of lines long just to get reasonable defaults that come standard with, e.g. VSCode and now Helix. My Helix config file is like four or five lines of TOML that change two config options.
cc @archseer, “run the test under cursor / rerun the last test” is a huge thing. Sadly, this isn’t supported by the LSP directly: https://github.com/microsoft/language-server-protocol/issues/944. rust-analyzer has a minimal custom extension for these, but I’d love something more fully fledged to be supported by different servers and editors:
I really like Helix. I’ve unfortunately switched to Emacs, and I feel that Helix is more of a Neovim/Kakoune replacement. I’m still keenly following the development. The plugin system is the big thing they need to nail.
I wish so hard for either of:
I’ve been programming for some time, and still don’t have an editor I can comfortably put at the foundation of my workflow :(
It’ll happen! It’s just a lot of work… That said, thanks for making rust-analyzer a joy to integrate with! It’s certainly been one of the most spec compliant language servers :)
Heh, that’s surprising. Our relationship with LSP historically was, ahem, adversarial, we shipped a tonne of extensions for missing bits and I still recommend people to sometimes, eg ignore the spec :)
Though, one thing we did early on is to outright crash and burn if we think we detect a spec violation. This allowed us to iron out a lot of bugs in many different clients, and even some of our own bugs :)
I want to like helix, but my brain keeps thinking this is vim and there are too many vim shortcuts I apparently use all the time that don’t work in helix - or are just different. Is anyone else experiencing this?
I’d say it’s painful for a day or two then you start adapting. I’m biased though of course :)
I’ve been a Vim user for 15+ years. It took me a couple of days to get used to Helix shortcuts, but it was so worth it…
I threw away years of Vim hacks accumulated in my
~/.vimdir and replaced them with a half-page config. I’m not going back!Can you share your config?
Don’t expect much :)
Basically two key bindings, the most important one being my test runner for the tmux pane next to
hx. Helix does the rest. Works like a charm for Go and TypeScript (every day at $JOB) and the occasional Rust project.Same. Muscle memory can be really strong. How cool would it be if there was a built-in tutorial where a text file is instructing you how to interact with it (maybe changing a simple block of text? Maybe a program in the coming levels), showcasing typical strengths of the highlighting-by-default flow, some refactoring, some search and replace etc.
We do have this! It’s available via
hx --tutorWow that’s just lovely. Thanks!
I had that problem too - until I remapped a few keys to avoid the pain points. See djacuen’s link in this comment thread for some example rebindings.
I have been trying helix more and more. The subtle changes from vim keybindings are truly painful, but the undo is responsive. I need to come up with a better shortcut list, because typing the vim keybinding is one thing, not knowing how to do it at all in hx is another.
Though I main Emacs, I have come to like Helix with some config modifications. You can find my config here: https://github.com/danieljaouen/dotfiles/blob/master/topics/helix/config.toml
Also an Emacs user—and unlikely to switch—but I find that even the default settings of Helix are very comfortable and if I ever needed a text editor that didn’t require that I lug around a 500-line config file, Helix would be it.
Congrats! I switched to Helix a few weeks ago and it instantly became my primary editor. I’ve been running
HEADand it’s been a little bumpy (the odd panic) but devs have been incredibly responsive in fixing things up. I’m really impressed!Helix looks really cool. I love that with a half page of configs, I can do 95% of what neovim needs 20 plugins to do.
There’s a few missing features, but are being worked on or are easy to work around (e.g. an in-editor terminal,
lastplace/nvim-lastplace-style functionality).For me, the bigger concern is relearning keys and patterns of editing without all the documentation that vim/nvim have accumulated over the literal decades. But I think maybe I just need to take the plunge and use it for a week, and things will start making sense.
Really impressed at the speed in which they’re adding features. I’m a big fan of key features integrated into the editor itself opposed to having a third party plugin system, everything just works out of the box.
Git gutter + bufferline were two things preventing me from making the switch, with every new feature this gets more and more tempting…
I still tend to get pretty confused between the kakoune editing vs vim but overall my experience has been positive.
Ah! I was hoping the file tree support landed in this release. In neovim I frequently use the file explorer (nerd tree? idk) as an interactive stateful
find.To me it’s not very clear what problem does Helix try to solve and what are the shortcomings of Vi/Vim/Neovim for solving that problem? I admit that I did not read very carefully the documentation of this project but I was expecting to get that information from the front page of the project.
I think the four axis of improvement are:
Sorry but I’m not convinced that those are real improvements. Let’s take them one by one. First, I see no numbers to hold the claim that the new model is better than the old model. The thing that they give as an example in the link can be done in Vim with Visual Mode, more or less. So I would take it as a proposal for improvement, not as an actual improvement. Second, I would be interested in the complexity of implementing such a code editor. My guess is that it needs to “recompile” the code every time you make a change so that it can “reason” about your changes. This looks to me as an overkill for large files or large projects. More than that, old systems cannot afford this type of “recompilation”. Third, I don’t understand your point here. Why more is better? Fourth, call me unagreeable, but I don’t buy the Rust propaganda. Every project in whatever language it is implemented is “hackable” and all programming languages are “collaboration-friendly”. I’m curious what you think about this.
I am not trying to convince you, you do sound like a person quite happy with vi, and that’s perfectly fine! It feels like helix solves the problems you personally don’t have. But I am pretty sure these are real problems for quite a few people (and I personally definitely acutely feel all of them).
Re editing model: I personally wouldn’t rely on numbers to make a decision here. To me, it’s blindingly obvious that what kakoune/helix are doing is much better. I’ve also heard enough stories from vim users who tried kakoune and got addicted. But, if you want numbers, it is better than vim at vimgolf: https://news.ycombinator.com/item?id=29984176
Re code editor complexity&performance: we’ve been doing that since early 2000’s in Java perfectly fine, there are no insurmountable technical or performance challenges there. It’s just due to open source micro economical reasons that no one actually bothered to go beyond regexes until Microsoft did the thing (see why LSP). As another data point, I started solving IDE problem for Rust in 2015, and by 2021 it was thoroughly solved, twice (by IntelliJ Rust and rust-analyzer). Some docs for that are in https://github.com/rust-lang/rust-analyzer/blob/master/docs/dev/architecture.md, https://rust-analyzer.github.io/blog, https://www.youtube.com/playlist?list=PLhb66M_x9UmrqXhQuIpWC5VgTdrGxMx3y)
Why do that? To be honest, for me the biggest reason is aesthetics: everytime someone opens an
.htmlfile in a text editor, html gets parsed with regexes, and that’s just horrible. See why an IDE for the list of most impactful things semantic understanding of the language provides.I do think that there are various degrees of collaboration-friendliness. On this axis, I think Rust (and Go as well, though I don’t have direct experience with that) is ahead of the average by a wide margin. One significant contribution is tooling:
git clone $rust_repo && cd $rust_repo && cargo testworks for 90% of rust projects without extra setup. For most other languages, it is “go read README to learn how we do things here, and then spend some time creating a non-hermetic dev environment”. The second significant contribution is that Rust is much better at interfaces (as “software components”, not as “dynamic dispatch”). This is most visible if we compare memory management between Rust and other sans-GC languages. In something like C++, every codebase has certain rules for lifecycles of objects, and its up to the programmer to ensure that distant parts of code agree on who frees stuff and when. This is a very significant chunk of project-specific knowledge, and is a barrier for contribution. In Rust, there are also project-specific rules about lifetimes, but then the compiler just tell you about them, you don’t need to bug the maintainer to learn how things work. But this goes beyond just memory: module&crate system is build around library as a first-class concept, different from a module, which helps tremendously with slicing large projects into independent chunks, and keeping the separation in place throughout refactors.On a more anecdotal note, IntelliJ Rust and rust-analyzer are similarly very contribution friendly projects, but setting that up with Rust was loads easier than with Kotlin, as gradle is a trainwreck.
It doesn’t matter very much what editor I use, because I try to view the problem from an objective perspective rather than entering the war on text editors. If we fight over which editing style/mode is better based on user preferences then what we are doing is politics, not science.
Complexity and performance are crucial aspects in developing software. It didn’t work “perfectly fine” because since 2000 a lot of hardware was deprecated to leave space to solutions that did not take into account complexity and performance as their fundamental problems. See Google et al. for reference. The micro-economical factors that you are talking about are there for a reason, i.e. to let everyone use the software on whatever software/hardware stack they want. Aesthetics is a second tier problem in this case.
Your collaboration-friendliness point is interesting. On one hand you can argue that it’s easier for users to “just use” the project as-is without making modifications to the project, and on the other hand you have people that want to make modifications to the project and they need to go to the README in order to actually understand how the project works under the hood. It depends very much on who is your audience. But I would argue that the idea of open-source works better with the second approach.
Helix uses tree-sitter under the hood, which is a fairly new project designed to enable incremental, fallible parsing. Basically, on every keystroke, Helix (through tree-sitter) efficiently updates the syntax tree it has parsed. There’s no compilation involved. Edits and selections work on ranges of text that represent pieces of syntax, like a whole function.
More is better because it lowers the barrier to entry for picking up the editor. I personally don’t enjoy spending a long time figuring out what Vim plugins to use and developing a config file hundreds of lines long just to get reasonable defaults that come standard with, e.g. VSCode and now Helix. My Helix config file is like four or five lines of TOML that change two config options.
I love helix and I’m now reaching for it in every scenario. Love it!
The only thing I’m not using it for is for more click-friendly debug functionality in VS Code.
cc @archseer, “run the test under cursor / rerun the last test” is a huge thing. Sadly, this isn’t supported by the LSP directly: https://github.com/microsoft/language-server-protocol/issues/944. rust-analyzer has a minimal custom extension for these, but I’d love something more fully fledged to be supported by different servers and editors:
https://github.com/rust-lang/rust-analyzer/blob/master/docs/dev/lsp-extensions.md#runnables
I really like Helix. I’ve unfortunately switched to Emacs, and I feel that Helix is more of a Neovim/Kakoune replacement. I’m still keenly following the development. The plugin system is the big thing they need to nail.