Onivim might not be for you :) But our project under the hood, libvim [1], might be useful for you to start (if it's easy to create bindings from C in Go).
There's a cool non-Onivim usage of it called Paravim [2] (and the same author also used it for Vim-Cubed [3])
Thanks ComputerGuru! :) Certainly, Revery is just putting together the building blocks the ReasonML and OCaml communities have developed. Inspired by ReactJS and Elm.
Revery supports the same FFI as OCaml [1] - C-style linking. I believe Rust would be straightforward to integrate that way - I'm not sure about C#.
I'd highly recommend Jordan Walke's (creator of React) talk on the ideas behind ReasonML: React to the Future [1].
I think it's so cool that you can take the ideas of ReactJS - functional programming applied to UI - but then have a language (ReasonML [2]) that is essentially purpose built for it, with OCaml [3] powering it under the hood - a functional programming language that's been significantly invested in, both in academia and industry. And to be able to take React-the-Idea, compile it cross-platform, to native-code... and ship.
This is one of the biggest pieces feedback we've received both the tabs / splits in particular [1], and the more general issue of broader Vim compatibility [2].
We actually use a forked Vim implementation under the hood (libvim [3]) - as the modal-editing engine. So Onivim, in theory, _could_ support everything. The main issue is 'wiring up' features from libvim to our front-end.
We'll be focusing on this in our next milestone (July-Sep) - with the high level goals of supporting more traditional Vim workflows, Vim tab support, along with VimL plugin support and init.vim/vimrc compatibility.
Ultimately it's a prioritization problem - so having feedback like yours is really helpful, so that we can focus on the right priorities for that work.
It's inspired by ReactJS, and has a similar API, but actually compiles to native code (not javascript). So you have a React-like developer experience, but with native perf.
For sure... drafting EULAs, working with lawyers, setting up a sales pipeline is not the fun stuff.
Would much rather work on bug fixes and features! Just a necessary evil to be able to fund development. In an ideal world - could just write open source software and not worry about paying bills.
> Rather than invest time in working through the problem
I don't think this is a fair characterization. We've made significant investments in both Neovim and Vim, and carefully considered the trade-offs.
> Guts of it is that Neovim didn't play nicely with their OCaml build and Vim did
This was a smaller consideration - but more fundamentally, the model Neovim uses for input - queuing it on an event loop and handling it asynchronously - is at odds with what we required - to be able to process the input -> handle updates synchronously.
There was a significant amount of incidental complexity in the architecture of our V1 to fit that asynchronous model - we wanted to avoid that for V2, and we switched to Vim because it fit that model.
It's actually a bit different - VSCode has a 'front-end' process and a 'back-end' process (the extension host).
The extension host is larger than just handling language services - it handles additional functionality, like source control, menus, language configuration - the full protocol is defined here: https://github.com/microsoft/vscode/blob/master/src/vs/workb...
We aim to integrate with that back-end extension host process - in other words, to support the `vscode` extension API surface, not just language support.
Because of the ubiquity and popularity of VSCode - the extensions tend to have significant investment and be of very high-quality, so we'd like to be able to leverage that wholesale.
We decided to try a new approach to see how it works for funding - funding open source projects is _hard_!
We wanted a model where, unlike completely proprietary licenses, the source code could be available - and, worst case, if something happened to the project - users could still have full access to it. And that all the work is eventually available in general.
Our first OSS drops - from 18 months ago - are coming in next month (July 2nd), so that'll be exciting. It will be interesting to see how it works out.