helix integration speculation

[AngeloChecked]

Hey @mattwparas,

i'm here again -,-

I've been pondering the idea of integrating Steel with Helix, but I'm completely ignorant about the internal workings of Helix and Steel. It's a bit of a curiosity for me, and I'd want know what are your already thought about it.

I've been daydreaming about how an embedded language like Steel could interact with an editor. Here are some of my initial thoughts:

• The engine should have access to various editor resources, what i called 'Helix SDK library'. This might include reading the Helix toml config, understanding the working directory, and more.

• It should be able to interact with the display, such as creating drawers, opening menus, displaying alerts, adding search boxes, and managing windows.

• Interaction with the text editor, like getting information about the current file, retrieving selected text, determining the cursor position, and applying text styling.

• Reacting to events, including built-in events like completions, formatting, keymaps, and also custom events.

• Running parallel calculations, executing shell commands, and making HTTP requests...

in my dreams, the Steel VM should be able to listen to Helix events and respond to them by reading from the Helix state and applying side effects to it.

However, I'm speculate a lot to low-level details that I'm ignorant about. Should the VM be single-threaded? Does Helix have a main loop? Is it reasonable to think about listening to Helix events and having the Steel VM read and write to the Helix state? how different scripts/plugins should interact each others?

I expel my thoughts in a image:

I'd love to hear your thoughts on whether these my super speculations are practical and if you or someone else here has insights into how Helix works and how design a language embedding!

[mattwparas]

Well - if you'd like to see how I went about it, you can see here on my fork, here are some instructions for setup: https://github.com/mattwparas/helix/blob/mwp-steel-integration/STEEL.md

I've been using it as a daily driver for the last few months. Works great!

More or less what you've described is spot on with how its integrated in my fork at least (of course, it hasn't been officially adopted and may never will, but that won't stop me from maintaining my fork 😄 )

The only difference is currently there is no explicit event system, but that is coming in a PR for helix which I'll integrate with accordingly.

The way helix does commands is it exposes a Context which has access to the main guts of the editor state - once we have access to that in steel, the sky is the limit. I've done some toying with custom rendering and it does work, just a bit tricky. Mostly have stuck to the editor api in order to make some plugins.

This is where most of the integration is: https://github.com/mattwparas/helix/blob/mwp-steel-integration/helix-term/src/commands/engine/scheme.rs

Steel is single threaded (although you can spawn threads and communicate via channels, but its pretty experimental at the moment) - however steel supports returning futures, so I just integrate with helix's async event loop in order to drive those futures to completion.

[mattwparas]

Also, after some thinking I have a few other thoughts:

The way I structured the helix integration is that there is simply one engine instance - each "plugin" is simply a module in steel that exposes some set of functions to the helix environment. From what I understand, that model is relatively standard - I believe it is how the lua integration in neovim is done as well.

If you have multiple plugin engines, i.e. perhaps steel is supported and there are other engines also supported, things get a little bit more tricky