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])
Just to be clear, I was making my comment more in the context of vim than Onivim. I maybe should have said that originally, my bad. I backed Onivim and am keeping a close eye on it. Maybe I won't need to (try to) make my editor :)
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.
That looks really nice - great job! There’s been a great amount of innovation in GUI libraries in the past two years. What’s the ffi story here? Can it be used as the frontend for a rust or C# application?
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#.
> 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.
Apologies, I didn't mean to insinuate that you were taking shortcuts or making frivolous choices. My attempt to summarize obviously lost the nuance of the decision.
I think the link summed it up well, near the end
> this was purely a constraint-based technical decision
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.
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.
> worst case, if something happened to the project - users could still have full access to it
Can you put in a formal license statement saying that each change will become mit-licensed 18 months after it's committed? That way, there's no ambiguity if development stops and releases stop getting put in the oni2-mit repository.
