-
This is a discussion for the future plugin system, created in order to prevent further clutter of #122. Latest update: #3806 (comment)
The plugin system is being worked on at #8675. The language will remain scheme, but the implementation will make it possible to easily swap languages if for example we choose to implement our own scheme. If we decide to stick with Steel, it can also load cdylibs (see https://github.com/mattwparas/helix-config/blob/master/term.scm as an example).
|
Beta Was this translation helpful? Give feedback.
Replies: 64 comments 252 replies
-
what is the current status? it is hard to follow the issue. is wasm still on the table? i think it was a great idea. if not what other alternatives are taken into account? |
Beta Was this translation helpful? Give feedback.
-
Proposing a candidate for a plugin system: rhai. |
Beta Was this translation helpful? Give feedback.
-
Would Javascript be an option? Active development and its probably rather easy to expose an API. |
Beta Was this translation helpful? Give feedback.
-
@kirawi Can we start a curated list of plugin ideas right away. It might seem too early but if we have a list right now then it might be useful for future devs to take suggestions from. We could ask users to suggest neovim/emacs plugins they would like to see in helix and after a huge list gets created, we could put it in a poll where the devs can get a clear idea of what plugins or plugin ideas are necessary. |
Beta Was this translation helpful? Give feedback.
-
Hi, Just as a quick preface to understand where I am coming from: to me, the most important benefit of a plugin system would be bringing some features that are critical to me in an editor to helix (most notably VCS integration, something like nvim-lightspeed and a filetree). It seems the current plan is to embed scheme, because WASM component models are not stable enough yet. Therefore, I would like to propose a rust based plugin system: This approach allows plugin developers to use the full rust ecosystem. Furthermore, plugin authors could easily write "library plugins". These would be crates that depend on the The obvious drawback to rust based plugins would be the need for compiling these plugins. For people unfamiliar with rust/simple plugins, a scripting language could still be added to helix in the future (WASM, scheme or something else). I have many more thoughts/ideas regarding the detailed design and comparisons to other approaches, but I just wanted to share my basic idea and gather your feedback. Could you see this as an approach being a good fit for helix? Because this is a pretty long post, a short summary (with some added points):
|
Beta Was this translation helpful? Give feedback.
-
I'm Just ordinary user chiming in. From the description from on https://github.com/bytecodealliance/cargo-component , the components model came up because they needed to wrap WebAssembly modules. It seems like there is some need to make a wit-bindgen like tool for the components model, so some solution should arrive soon. Herein, I try collect in one place, summary of sub-discussions for quick reference, with links included inline to the actual sub-discussions. Plugin language options
The case for plugin-provided-feature
The case for in-core-feature
List of candidate plugins
List of conventional-plugin-features gone in-core
Desirable characteristics of a plugin system
Projects that are noteworthy for their plugin system implementation
Other discussions
so... where we at? Q1) Is choosing a plugin language now, just a temporary stop gap for small simple plugins until wasm matures, just to buy time for an eventual later migration? Q2) neovim has both a lua and vimscript engine. Would helix be able to have multiple simultaneous plugin language engines, perhaps aiding transition if the afore-said stop-gap were to be retired? Q3) Would the plugin api be designed to be so that it mimics vscode so that as many plugins from vscode eco-system be easily ported? Q4) If lapce (a gui code-editor like vscode) is going with wasm, wouldn't that also allow easy script sharing and porting with helix (and also kakoune if it gets a wasm plugin engine)? Q5) Would plugin system allow for dynamic load/unload or one time load on startup? notes
Helix holds much promise. thx to the developers P.S.
|
Beta Was this translation helpful? Give feedback.
-
I say this with zero interest in attempting to rush or apply pressure on any of the maintainers of this project, only as someone who is considering using helix as my primary editor(because its really cool, and of all of the things I've tried is the only one that "just works"): is there any kind of rough estimate on when a plugin system might emerge? I don't mean dates, just the general scope of it. Are we talking weeks/months/years? |
Beta Was this translation helpful? Give feedback.
-
Also: stick with WASM plugins, IMO :) If we want to take Helix with us into the future, we should lean into WASM. |
Beta Was this translation helpful? Give feedback.
-
I have a question... I don't have a terribly strong opinion about what language helix ends up using long-term. However, it appears to me that no matter what ends up happening, it will take a significant amount of time. Is there any possibility for any sort of short-term solution? In particular one idea I had was to be able to write something in rust that has access to all of the helix commands as functions, and just be able to compile that to some target and put it in the .config/helix directory. I'm far from an expert on rust development in general or helix's development specifically, but since the codebase is written in rust it doesn't seem like much work would have to be done to expose these functions. No need to write a whole api spec or anything like that. It definitely wouldn't be the best idea in the long run, but the idea would just be to give the users some way to script until a more formal solution comes about. It obviously wouldn't have to be that idea either. I just would like to know if there's any possibility of something to give us the ability to script something until the plugin system is ready. Because it looks like it may be a long time before that happens. |
Beta Was this translation helpful? Give feedback.
-
https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe-and-production-ready |
Beta Was this translation helpful? Give feedback.
-
EDIT: I seem to have come across as trolling or hurtful to some people and for that I apologize. I did not mean to sound overly critical, and should not have implied that overall progress has stagnated, which is obviously wrong: What I meant was that progress on this particular issue seems to be slow, and I can't wait to find out what direction this will take and in what time frame it will happen. First of all: I love the Helix project and wish it nothing but the best. I personally haven't yet invested that much time into learning vim (only dabbled so far), but I really want to learn one modal editor to use for most of/all of my programming in the future. I have been following Helix since the beginning of this year, and really like what it already is! Totally fine if "competing" with Neovim is not a goal of this project, but I would really like to know if that's the case and what the vision for this project really is. If a plugin system is something that's far off, like potentially years away, I would like that to be clarified as that would mean that this is not the right fit for me, personally. ThePrimeagen pointed out in one of his recent videos that one of the great points about learning vim is its ubiquity on all platforms. Of course that grew out of it having been used for decades, and helix might never reach that point – but I'd like to know if helix even aims that high or if this is just kind of an experimental project that's not really intended for mainstream use. Fine either way, but I'd really like to know where the project's core developers stand with regards to this. |
Beta Was this translation helpful? Give feedback.
-
[Summarizing a conversation from Matrix for informational purposes] Unless I misinterpreted something, it looks like the decision to not use wasm was mainly due to the lack of a standardized interface. Using wasm only opens up the possibility of multi-language support, but it's not automatic due to the lack of the interface types. So I shared what looks like a workaround of this issue that I've seen in the past. graph-node has a wasm runtime. It's not exactly a plugin system, but it does expose a wasm API and runs user wasm code (so sandboxing is a hard requirement). Instead of defining the interface in Rust, they're actually doing it in their target language AssemblyScript here in graph-ts, and in turn use a custom codegen tool to turn it back to Rust for use in the wasm host. This way AssemblyScript gets direct access to the API, and for any other language, they just have to implement another codegen tool for bridging the gap. Generalizing this approach further, we can declare the interface in a format like Obviously with this approach there's gonna be extra effort for supporting more languages. For that, @archseer acknowledged the value of settling on a single plugin language, and I agree. However, wasm has a lot more benefits other than just "multi-language". Performance and sandboxing (and thus a permission system) are extremely important in a plugin system too. We can totally settle on a single "officially supported" plugin language, and only maintain the codegen tool for that language. It's also future-proof if the plugin author community decides that another language is better - no backward compatibility concern at all. |
Beta Was this translation helpful? Give feedback.
This thread has devolved into language popularity discussions and most options have been mentioned multiple times already (and no, we won't pick XYZ because it's your favourite language).
I've kept the discussion open because there's occasionally been an interesting comment or project mention. But as the discussion grew older ideas would get buried in the backlog and brought up again several times. Since each post on this thread pings a couple hundred of us subscribed to the discussion I'm going to lock the issue for the time being. If you'd like to have a technical discussion on the implementation we're always available on Matrix.
I plan to write a longer post that discusses alternative…