I absolutely don't mind the plugin system being a Scheme. It's a plugin for a text editor, and Steel(https://github.com/mattwparas/steel) seems to be a lot less of a maintenance burden than WASM plugins(besides that I find the WASM tooling to be extremely complex).
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!
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.
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.
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.
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.
> 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 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.
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.)
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.
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.
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.
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.
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 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.
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.
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!
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.
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!
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!