Support reasonml/ocaml as a plugin language

[dinosaur-lin]

Thanks for working on onivim2. I already purchased the license two weeks ago:)

I am personally a fan of reasonml/ocaml. I understand currently the priority is supporting visual studio code's plugin ecosystem, which is great.

But visual studio code is written in typescript. There might be some communication overhead between onivim2 and vscode plugins? For performance reason and the community hacking on onivim2, should onivim2 support native plugin in reasonml in the long term? Is there a remote interest to do that?

[bryphe]

Hi @dinosaur-lin ! Thanks a lot for supporting for the project 😄

And appreciate you starting this conversation - this is actually something that I've been thinking about so I'd be happy to share my thoughts and get feedback.

I understand currently the priority is supporting visual studio code's plugin ecosystem, which is great.

Indeed - the main motivator is the fact that there is such breadth of high-quality plugins. It's a way to jump start the capabilities of our editor.

There might be some communication overhead between onivim2 and vscode plugins?

There is for sure. To accommodate VSCode extensions, we actually will run a separate node process and communicate it via IPC or stdin/stdout with the main renderer. This isn't cheap (requires serialization to JSON back-and-forth, etc)

For performance reason and the community hacking on onivim2, should onivim2 support native plugin in reasonml in the long term? Is there a remote interest to do that?

I am definitely interested in this down the road. I believe we could do some pretty neat things either with [dynlink] or even a built in OCaml/ReasonML REPL....

The main use case I thought of off the top of my head for this sort of integration is for custom renderers, ie:

• being able to visualize filetypes in a custom way (ie, render images, or PDFs, etc). Native plugins would open up interesting possibilities for this.
• being able to override certain UI elements (ie, custom statusbar - a plugin could provide its own statusbar component)

However, even for language integrations like completion, go-to definition, hover - it could offer a significant performance boost by bypassing that interop with the JS world. One thing I could imagine in the ReasonML/OCaml ecosystem, for example, is direct integration of merlin.

Unfortunately it probably won't be something that makes it in the next couple of milestones - but it is indeed something I'm interested in, and would love to hear thoughts around.

[yunti]

"a built in OCaml/ReasonML REPL...." - that would be an amazing addition. It's a great plus to have consistency in eg completion in the editor and the REPL

I would definitely be keen to write plugins directly in reason/ocaml rather than have those compiled and supported via vscode extension.

Would we also get a benefit using the reason-language-server directly rather than as a vscode plugin?

[Khady]

Emacs can have ocaml plugins because it can load some .so as plugins. And those .so can come from any language. Might be way to support ocaml but not only.