CenTdemeern1 commented 2026年07月10日 21:30:55 +02:00

This is a proposal to replace Helix's upcoming Steel/Scheme-based plugin system with our own Rust-focused one, codenamed Spellbook.

Why?

After internal discussion on Zulip, it seems pretty clear that we want Volute (or whatever its name ends up being) to have a working plugin system.

Helix has an upcoming system (which has been in development hell for ages now) which uses Steel, a Scheme (lisp) dialect.

I would personally prefer to write plugins in Rust.

Key points

• A while ago I designed a plugin system for Rust projects which has the concept of "adapter plugins"; plugins with the capability to load and manage other plugins, possibly written in different languages.
• It loads cdylibs and uses symbol lookup to call a plugin's functions.
  • There is a predefined API which follows semantic versioning
  • Plugins are able to decide whether they're compatible with the version of the loader/API that is loading them before initialization
    • This should help prevent undefined behavior between incompatible API versions
  • The public API is defined in a single place, in a single crate shared by both the loader and plugins
    • This helps avoid discrepancies and thus UB ("oops I forgot to edit this on the loader side and now everything is broken")
    • This crate exposes a macro for automatically generating this interface in the plugin crate
      • This is convenient and helps quickly bootstrap projects
  • You can theoretically write plugins in anything that can expose a C interface, not just Rust
    • Rust is what it's designed for though, with stuff like the aforementioned macro
• Adapter plugins are used to add compatibility with other systems or programming language
  • We could make an official neovim adapter plugin to allow for loading neovim plugins
  • We could be backward compatible with Helix's Steel plugins via an adapter plugin, if that ecosystem ever takes off.
    • It might very well not take off, so the need may not arise
  • If we ever have a major version bump that makes all previous plugins incompatible, an adapter plugin to load older plugins could be developed
  • If anyone wants to write plugins in their favorite programming language, they can make an adapter plugin without having to fork the editor

Unresolved questions

• If we're using native cdylibs, this would require compiling a plugin from source if it's not normally distributed for the architecture you need.
  • Should all plugins be compiled for a specific shared architecture, like WASM/WASI? Should we support both WASM/WASI and native?
• Will having too many languages and adapter plugins fragment the plugin ecosystem?

This is a proposal to replace Helix's upcoming Steel/Scheme-based plugin system with our own Rust-focused one, codenamed Spellbook. # Why? After internal discussion on Zulip, it seems pretty clear that we want Volute (or whatever its name ends up being) to have a working plugin system. Helix has an upcoming system (which has been in development hell for ages now) which uses Steel, a Scheme (lisp) dialect. I would personally prefer to write plugins in Rust. # Key points - A while ago I designed [a plugin system for Rust projects](https://codeberg.org/CenTdemeern1/plugin-loader) which has the concept of "adapter plugins"; plugins with the capability to load and manage other plugins, possibly written in different languages. - It loads cdylibs and uses symbol lookup to call a plugin's functions. - There is a predefined API which follows semantic versioning - Plugins are able to decide whether they're compatible with the version of the loader/API that is loading them before initialization - This should help prevent undefined behavior between incompatible API versions - The public API is defined in a single place, in a single crate shared by both the loader and plugins - This helps avoid discrepancies and thus UB ("oops I forgot to edit this on the loader side and now everything is broken") - This crate exposes a macro for automatically generating this interface in the plugin crate - This is convenient and helps quickly bootstrap projects - You can theoretically write plugins in anything that can expose a C interface, not just Rust - Rust is what it's designed for though, with stuff like the aforementioned macro - Adapter plugins are used to add compatibility with other systems or programming language - We could make an official neovim adapter plugin to allow for loading neovim plugins - We could be backward compatible with Helix's Steel plugins via an adapter plugin, if that ecosystem ever takes off. - It might very well not take off, so the need may not arise - If we ever have a major version bump that makes all previous plugins incompatible, an adapter plugin to load older plugins could be developed - If anyone wants to write plugins in their favorite programming language, they can make an adapter plugin without having to fork the editor # Unresolved questions - [ ] If we're using native cdylibs, this would require compiling a plugin from source if it's not normally distributed for the architecture you need. - Should all plugins be compiled for a specific shared architecture, like WASM/WASI? Should we support *both* WASM/WASI and native? - [ ] Will having too many languages and adapter plugins fragment the plugin ecosystem?

lumi commented 2026年07月10日 22:09:24 +02:00

I love the idea, thanks for the write-up! The plugin loader system you've created is very cool.

Using native cdylibs may have some performance advantages, but I think it will have more issues than it's worth, so I would err on the side of WASM or similar with this.

I would like to add something else to think about: the plugin system supporting many languages will mean that plugins will be in many languages, and will cause the plugin ecosystem to be very heterogeneous. Settling on one language has the benefit of avoiding this situation.

My own view on plugins is also that I would like for the core editor to support most things people want, and that plugins are mostly just some glue over existing things.

I love the idea, thanks for the write-up! The plugin loader system you've created is very cool. Using native cdylibs may have some performance advantages, but I think it will have more issues than it's worth, so I would err on the side of WASM or similar with this. I would like to add something else to think about: the plugin system supporting many languages will mean that plugins will be in many languages, and will cause the plugin ecosystem to be very heterogeneous. Settling on one language has the benefit of avoiding this situation. My own view on plugins is also that I would like for the core editor to support most things people want, and that plugins are mostly just some glue over existing things.

CenTdemeern1 commented 2026年07月10日 23:01:44 +02:00

@lumi wrote in #2 (comment):

I love the idea, thanks for the write-up! The plugin loader system you've created is very cool.

Thank you <3

Using native cdylibs may have some performance advantages, but I think it will have more issues than it's worth, so I would err on the side of WASM or similar with this.

The problem with WASM is that it doesn't have access to stuff like the filesystem. We would either need to require our users to write #[no_std] and then provide our own extensive API for access to OS features like the filesystem or shell, or use something like WASI, which isn't stable yet, and rather limited.
WASM or WASI would be really great for portability but not as good for performance or for operations that require nontrivial integration with other programs or the OS.

I would like to add something else to think about: the plugin system supporting many languages will mean that plugins will be in many languages, and will cause the plugin ecosystem to be very heterogeneous. Settling on one language has the benefit of avoiding this situation.

I've added this to the unresolved questions!

My own view on plugins is also that I would like for the core editor to support most things people want, and that plugins are mostly just some glue over existing things.

I agree; a user shouldn't have to go out of their way to find and install plugins to get basic features, but for some really niche situations or integrations with other software that doesn't fit into the main project having a plugin system is nice.

@lumi wrote in https://codeberg.org/polyphony/volute/issues/2#issuecomment-18968519: > I love the idea, thanks for the write-up! The plugin loader system you've created is very cool. Thank you <3 > Using native cdylibs may have some performance advantages, but I think it will have more issues than it's worth, so I would err on the side of WASM or similar with this. The problem with WASM is that it doesn't have access to stuff like the filesystem. We would either need to require our users to write `#[no_std]` and then provide our own extensive API for access to OS features like the filesystem or shell, or use something like WASI, which isn't stable yet, and rather limited. WASM or WASI would be really great for portability but not as good for performance or for operations that require nontrivial integration with other programs or the OS. > I would like to add something else to think about: the plugin system supporting many languages will mean that plugins will be in many languages, and will cause the plugin ecosystem to be very heterogeneous. Settling on one language has the benefit of avoiding this situation. I've added this to the unresolved questions! > My own view on plugins is also that I would like for the core editor to support most things people want, and that plugins are mostly just some glue over existing things. I agree; a user shouldn't have to go out of their way to find and install plugins to get basic features, but for some really niche situations or integrations with other software that doesn't fit into the main project having a plugin system is nice.