Plugin system, more questions

[KalinDimitrow]

The original topic is already closed, for that reason I open that one. Please don't hate me for that.
Whatever language the team decide to use as a plugin Im ok with it, but I want to suggest binary interface for loading so/dll which will open the gates for languages like c/c++/rust and more. It also will allow the community to write plugins that support other languages as plugin writing language and even support for vim plugins in helix (if someone desire to spend their time on that experiment)

I apologize if that was already suggested but I see few benefits into that approach

• Less over thinking what the perfect solution would look like and give something workable for the community to play with
• Provide feedback what need to be exposed and help/accelerate so called perfect solution
• Allow people to develop outside of helix project
• A lot less effort then full-fledged solution

Ofcourse that approach have drawbacks like loading binaries and so on but this could be mitigated by marking the feature as deprecated from the beginning and give clear sign that this is just early enabler of plugin system as developer play ground

[kirawi]

AFAIK this is being worked on/considered. #8675 supports this through Steel which can load dylibs.

[pascalkuthe]

yes this was proposed a long time ago (by me :P) this is definitely an angle I am interested in but the scripting language will take priority. Steel allows loading dylibs so it should already be covered by that. The plugin system implemented in #8675 is very generic so it may be possible one day to "cutout the middleman (steel)" but that is lower priority.

I don't think that makes sense as an intermediate solution since an important goal for the plugin system is close integration with the rest of the editor and particularly handling configuration. For those usecase compiled language like that C/rust are not suitable