Helix: Release 24.03 Highlights(helix-editor.com)
helix-editor.com
Helix: Release 24.03 Highlights
https://helix-editor.com/news/release-24-03-highlights/
46 comments
I do mind and not gonna use Helix just for this alone. Lips is the past (I've used it extensively in the '80s and '90s), not the future!
While I understood the maintainer's arguments for wanting to adopt a Scheme-like for plugins, I can't help but be a bit disappointed.
Helix being written in Rust meant that I felt very comfortable looking at the source code which gave me the confidence that if I wanted to implement something, I could reasonably do so. Furthermore, the idea that plugins could've been in Rust or Rust through WASM meant that I'd have an editor which was completely hackable in the least annoying way possible. Every time I have to learn one of these tool-specific languages I end up breathing a heavy sigh, spending a lot of time relearning things or working around weird quirks, and then ultimately giving up after writing the most basic version of what I want to do.
Ultimately, this is just a me problem and I really can't complain about something I haven't paid for or substantially contributed to. Maybe it'll actually be awesome and I'll change my mind completely, maybe they'll reconsider and add Rust-based plugins. Helix as an editor is awesome and I'm just going to have to trust the developers.
Helix being written in Rust meant that I felt very comfortable looking at the source code which gave me the confidence that if I wanted to implement something, I could reasonably do so. Furthermore, the idea that plugins could've been in Rust or Rust through WASM meant that I'd have an editor which was completely hackable in the least annoying way possible. Every time I have to learn one of these tool-specific languages I end up breathing a heavy sigh, spending a lot of time relearning things or working around weird quirks, and then ultimately giving up after writing the most basic version of what I want to do.
Ultimately, this is just a me problem and I really can't complain about something I haven't paid for or substantially contributed to. Maybe it'll actually be awesome and I'll change my mind completely, maybe they'll reconsider and add Rust-based plugins. Helix as an editor is awesome and I'm just going to have to trust the developers.
But you are also speaking as someone who already knows Rust. If we take a step back and imagine someone who knows neither, what's easier to learn, a high level language or a low level one? (I don't think pointing out that Rust has high level aspects alters the relative situation)
Take two programs with historical success in building this kind of plugin system: Emacs and Browser. The number of non-programmers who can write elisp (or javascript) but won't dare to touch C/C++ code in the core layer probably outweighs the opposite by a huge factor.
Take two programs with historical success in building this kind of plugin system: Emacs and Browser. The number of non-programmers who can write elisp (or javascript) but won't dare to touch C/C++ code in the core layer probably outweighs the opposite by a huge factor.
Just to be clear, this was one of the arguments of the Helix maintainers. I (sort of) agree and do think it's the _overall_ better approach in terms of general learnability and ease-of-use (bar WASM+WASI components, though that has it's own complexities).
However, my complaint was a bit more selfish-- for me personally, I'm a bit let down because I had gotten the idea in my head that I'd be able to use Rust from top to bottom. Following the discussion for the plugin system for a good while, many different options were on the table and I had gotten my hopes up for the ones which didn't pan out. Woe is me, but I'll live and I trust the maintainers to do what is ultimately right for the editor.
However, my complaint was a bit more selfish-- for me personally, I'm a bit let down because I had gotten the idea in my head that I'd be able to use Rust from top to bottom. Following the discussion for the plugin system for a good while, many different options were on the table and I had gotten my hopes up for the ones which didn't pan out. Woe is me, but I'll live and I trust the maintainers to do what is ultimately right for the editor.
The original issue wrt. WASM for the Helix project was that WASM currently only exposes a very barebones, C-like FFI for communicating with plugins. This should be solved in the future by the WASM component model, so these choices could well be revisited.
Agreed -- I've been putting in some significant effort to learn helix / break my nvim habits specifically because it's written in rust so I feel like I could hack on it / contribute back.
[deleted]
Steel can load cdylibs (this is used for the integrated terminal POC plugin I think) so Rust plugins are already possible with that PR.
This is actually really good information, thanks for pointing it out!
> Furthermore, the idea that plugins could've been in Rust or Rust through WASM meant that I'd have an editor which was completely hackable in the least annoying way possible. Every time I have to learn one of these tool-specific languages I end up breathing a heavy sigh, spending a lot of time relearning things or working around weird quirks, and then ultimately giving up after writing the most basic version of what I want to do.
I very much understand this. However I'd argue using Scheme is a great tradeoff. Because in the end programming is about tradeoffs. Scheme will not overcomplicate plugins for the maintainers, and as a write you have to learn a tiny DSL for configuring your editor.
As we speak, I'm trying to write a plugin for Zed, and as awesome all the niceties about Zed is, plugins are not easy, and frankly speaking, I feel like I wasted my time with all this nonsense about WASM, while in Helix the same plugin (language support) was really, really simple, even as somebody who knew nothing about Rust or Scheme.
I very much understand this. However I'd argue using Scheme is a great tradeoff. Because in the end programming is about tradeoffs. Scheme will not overcomplicate plugins for the maintainers, and as a write you have to learn a tiny DSL for configuring your editor.
As we speak, I'm trying to write a plugin for Zed, and as awesome all the niceties about Zed is, plugins are not easy, and frankly speaking, I feel like I wasted my time with all this nonsense about WASM, while in Helix the same plugin (language support) was really, really simple, even as somebody who knew nothing about Rust or Scheme.
I love Helix as a vim user for decades. It brings fresh wind in a pretty entrenched world for people that think neovim is not neo enough.
That being said, I'm pretty disappointed by the decision for an obscure plugin language. Moreover, I'm disappointed even more, that the necessity of a strong and tried and proven sandbox is not given enough attention.
The recent xz disaster just proves once more that we cannot go on like this.
An editor that requires tens of plugins from tens of different parties just to be usable will not have a future if it has no answer to the supply chain question. This is really not just vim and neovim, Visual Code Studio is equally bad and most full IDEs are only marginally better.
In my opinion zellij is on the right track here and I had wished Helix had adopted a similar solution.
That being said, I'm pretty disappointed by the decision for an obscure plugin language. Moreover, I'm disappointed even more, that the necessity of a strong and tried and proven sandbox is not given enough attention.
The recent xz disaster just proves once more that we cannot go on like this.
An editor that requires tens of plugins from tens of different parties just to be usable will not have a future if it has no answer to the supply chain question. This is really not just vim and neovim, Visual Code Studio is equally bad and most full IDEs are only marginally better.
In my opinion zellij is on the right track here and I had wished Helix had adopted a similar solution.
I didn't think Helix supported plugins, and I don't see any mention of it in the documentation. What language does it use?
(Edit: I see a bit of Scheme in the GitHub repo, but to call them "plugins" are a bit of a stretch; it seems limited to mostly-declarative syntax highlighting stuff.)
(Edit: I see a bit of Scheme in the GitHub repo, but to call them "plugins" are a bit of a stretch; it seems limited to mostly-declarative syntax highlighting stuff.)
It doesn't yet have a plugin system but they're thinking of adding one for the Steel programming language (a lisp).
https://github.com/mattwparas/steel
https://github.com/mattwparas/steel
Yes, and from what I understand there was plenty of discussion and they carefully analyzed different options. The discussion seems to be is closed now.
I respect that, you cannot ponder these things forever and sometimes any decision is better than none. It's just that, unfortunately, my priorities are different from those of the Helix devs in that respect.
I respect that, you cannot ponder these things forever and sometimes any decision is better than none. It's just that, unfortunately, my priorities are different from those of the Helix devs in that respect.
Are you referring to Scheme or to wasm/wasi? The sandboxing would be one of the the biggest benefits with a wasm-based plugin system, but they were waiting for the component model spec to be finalised last time I had a look.
edit: looks like the plugin work is being done here https://github.com/helix-editor/helix/pull/8675
edit: looks like the plugin work is being done here https://github.com/helix-editor/helix/pull/8675
There was a long discussion regarding this in the community, I am sure they came up with the best idea
Good discussion with good reasons, very much like the other design decisions that they made so far. I just believe that when it comes to the plug-in idea that their priorities are not the ones that will be important in the long run and that they vastly underestimate the importance as well as the effort of a practical and useable sandbox implementation.
I think the xz disaster would be a reason why Wasm-based plugins would be bad. People would be forced to use plugins written in a language they may not know and would not be able to audit for themselves.
A WASM setup should completely sandbox the plugin so even with malicious code, it would not have access to anything sensitive.
Depends. if the editor is given permission to edit files, like say, many people do `sudo helix` when they want to edit some system config file, you could imagine a rogue wasm plugin doing a lot of harm.
Sandboxing isn't magic, if you need the permissions to do something, then the things in the sandbox get access to them.
Sandboxing isn't magic, if you need the permissions to do something, then the things in the sandbox get access to them.
That’s not how the WASM sandbox usually works - it has a very limited API surface and can only take specified inputs.
https://docs.wasmtime.dev/security.html
https://docs.wasmtime.dev/security.html
Right, but it can control the editor indirectly through that API surface, and the editor can write to the filesystem.
It's definitely more secure than running a non-sandboxed executable, but the entire point of a plugin is to have an effect on the editing process, and the entire point of the editor is to modify files on the filesystem. As long as that's true there's a casual mechanism for an untrusted plugin to do damage.
It's definitely more secure than running a non-sandboxed executable, but the entire point of a plugin is to have an effect on the editing process, and the entire point of the editor is to modify files on the filesystem. As long as that's true there's a casual mechanism for an untrusted plugin to do damage.
If this is true, it’s a sad day for software. Not sure why some actors are intent on ruining it for the rest of us.
A code editor that doesn't support plugins is destined to die.
Thank you. I love Helix. It’s my daily driver.
What do you use it for i.e what kind of codebases are you typically working with?
Everything. Rails, Haskell, Rust… I care about speed/performance above all and Helix is just faster than everything else. Zero config is icing on the cake.
Not op, but I use it for ruby/er/rails/graphql/SQL/typescript/css/html/Vue and various markdown mostly. Oh and shell, tofu/terraform, yaml - k8s/docker.
Rust and TypeScript for me.
My daily driver is emacs with evil. Is Helix’s modal editing worth learning?
Helix's modal editing is based on Kakoune's modal editing which is like an evolution to Vim's modal editing. You can think of it as being always in selection (visual) mode. https://github.com/mawww/kakoune?tab=readme-ov-file#selectio...
I moved to helix after using vim/neovim for a long time. I much prefer helix' kakoune-inspired object>verb/select>action to vi(m) verb>object.
As others have said, I recommend giving it a try, eg with the tutorial.
That said - if you enjoy the view from the emacs mountain top, you might find helix hill to be too small - helix is not an operating system.
I prefer it that way, others might not.
As others have said, I recommend giving it a try, eg with the tutorial.
That said - if you enjoy the view from the emacs mountain top, you might find helix hill to be too small - helix is not an operating system.
I prefer it that way, others might not.
It couldn't hurt to try a different editing paradigm but as a daily Helix user but I wouldn't switch over just for that. It's different, not better or worse than Vim's.
On eMacs there’s kakoune.el and meow that you can try out.
Thanks for the tip, meow looks interesting. I never got comfortable in evil-mode, but perhaps meow could be a gateway to trying emacs in anger.
Still waiting for kakoune/helix mode for gnu readline...
https://github.com/meow-edit/meow
https://github.com/jmorag/kakoune.el
Still waiting for kakoune/helix mode for gnu readline...
https://github.com/meow-edit/meow
https://github.com/jmorag/kakoune.el
Quite frankly, reading these release notes addressing basic features like toggling block comments is just…
Makes me wonder why we engineers love reinventing the wheel with new text editors, all at various levels of brokenness.
Makes me wonder why we engineers love reinventing the wheel with new text editors, all at various levels of brokenness.
It's called progress.
Helix does a lot of things better than other editors, so cherry-picking some minor thing to make it look not worthwhile is just silly.
Helix does a lot of things better than other editors, so cherry-picking some minor thing to make it look not worthwhile is just silly.
I’m not cherry picking. It’s just weird to see yet-another-editor in 2024, with developers having to reinvent everything from scratch.
I mean, half the comments here are disappointed that plugins will need to be coded in Steel/Scheme. That basically renders the entire world of editor plugins unusable. I just can’t wrap my head around that decision!
I mean, half the comments here are disappointed that plugins will need to be coded in Steel/Scheme. That basically renders the entire world of editor plugins unusable. I just can’t wrap my head around that decision!
> basic features like toggling block comments
Whether this is a basic feature depends on the languages you're using, I'm pretty sure I haven't toggled a block comment in 10+ years. Some languages don't even have them (Zig), others do but you are encouraged not to use them (Rust) and some only have those e.g. OCaml.
Whether this is a basic feature depends on the languages you're using, I'm pretty sure I haven't toggled a block comment in 10+ years. Some languages don't even have them (Zig), others do but you are encouraged not to use them (Rust) and some only have those e.g. OCaml.
My point is less around usage and prevalence, and more around reimplementing basic paradigms ad infinitum.
It's hardly just us engineers. Plenty of startups try to radically improve things instead of just joining companies that are already doing the thing. I think this is analogous.
By subscribing to the latest of web tech, we now get nice on/off buttons and horizontal bars in select menus. So by comparison this stuff is light years ahead!
Different needs/requirements. If there is demand for something then someone will eventually become the supplier.
No, I think devs just love pointlessly tinkering with new tools all the time - I’m guilty of this myself too.
[deleted]
But besides all that, Helix learned be that I don't need fancy plugins or endless finicking with config files and toolchains. Using a combination of other tools, like yazi and lazygit, helps me not only inside my editor but outside of it as well. And Kakoune does this even better. In that regard it has been a real eye-opener and refreshing. The downside is, it's hard to go back to other editors!