Helix: Release 24.03 Highlights
helix-editor.com
helix-editor.com
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!
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.
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.
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.
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.
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.
(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.)
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.
edit: looks like the plugin work is being done here https://github.com/helix-editor/helix/pull/8675
Sandboxing isn't magic, if you need the permissions to do something, then the things in the sandbox get access to them.
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.
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.
Still waiting for kakoune/helix mode for gnu readline...
Makes me wonder why we engineers love reinventing the wheel with new text editors, all at various levels of brokenness.
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 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!
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.