onivim
patreon
Update (Oni v2)
🕑 Added 2018-12-01 17:52:19 +0000 UTCHey backers!
There hasn't been an update from me for a while - so I wanted to share with you what I've been working on.
First off - I wanted to thank our core contributor __Akin__ for giving a talk at VimConf! Akin said they are still working on getting that stream uploaded, but once it's up I'll share it out.
I've been spending my time on the project prototyping what an 'Oni v2' could look like - re-imagined taking what we've learned from Oni v1.
I've written up my thoughts here that touch on both the Technical aspects as well as Sustainability here: https://gist.github.com/bryphe/ca3260914818a1293864e9fa6422a69c
Some key highlights:
- Leverage complete VSCode Extension Host (that means, eventually, full compatibility with VSCode plugins - including debuggers, etc).
- A fully-native rendering core for the front-end
- A more sustainable model helping us to focus on the right priorities (selling licenses for commercial use - any backers, though, will always get this commercial use license for free).
I view Oni v2 as the next stage of the experiment that Oni started - building the fastest way to go from thought to code.
The past few weeks, I've been doing a few prototypes - some progress there:
- Native text rendering by Revery - DONE
- A standalone extension host - the initial extension host runs. Next step is to test with basic plugins and add tests that run cross-platform.
- Neovim integration - I prototyped using the `libnvim` API, but unfortunately ran into hurdles integrating this into our native OCaml/Reason stack. I'm switching back to MsgPack and looking at performance comparisons in the native vs Node sides.
It will take some time - my hope is that end of January we can have a usable prototype of this new architecture, and focus on the next set of priorities (Also, I hope to have binaries available for download earlier than that). I'll keep you updated as this work progresses.
As stakeholders in the project - your feedback matters to me, so please let me know if you have ideas/questions/concerns! Feel free to reach out via discord or e-mail me directly (bryphe@outlook.com).
I'm excited about the direction we're heading and feel like we have the foundation for an editor that brings together the best of the tech we have today.
Also - for the past few months, I've been splitting our Patreon funds with the core contributors that have been active on the project.
THANK YOU for supporting the project!
- Bryan
Comments
Hey Stefan! Great question, as it's something I'm still thinking through (so maybe you or others might have feedback). One of the motivating factors for pursuing a new architecture was some functionality we exposed via plugins was hard to get right performance wise - like the 'Buffer Layers' - the ability to render UI dynamically on top of the editor would be pretty janky with scrolling. VSCode 'fixes' this by limiting their extension model. However, I think we can do better: - One option is to allow JavaScript extension to still use the Oni API (which allows more customization). This could be specified by the 'engine' property in the plugins package json - whether it works against VSCode's API or Oni's API. The performance might be better, because it would never block rendering, but it would still be hard to get real-time performance for things like rendering, because of the interop between the reason JS/node process hosting the plugin - so the 'jank' for plugins that need to render real-time would still be unsolved in this approach. - Another option is to allow for _native code plugins_ - essentially DLLs that could be written in Reason/OCaml to directly extend the editor process natively. I think this is an exciting direction, but there are a few concerns - like how do you protect against malicious native plugins? But it's an avenue I'd like to pursue further. Let me know if you have any thoughts.
A lot of good ideas! I had a look at Reason and I find it amazing, but (back at that time) the available BuckleScript binding with existing JS packages wasn't enough to try it in more depth. I have one fear with the "VSCode's extension host" idea: Would this limit "Oni extensions" to only the API VSCode has? Because with modal editing and neovims (not finished) grid support, I guess, the VSCode API wouldn't be enough to use all features of Oni as a plugin author.
Thanks Christopher! Will keep you posted. I'll be putting a repo up in the next week or so, but won't be usable to start (focusing on the test infra / validating extension host + neovim integration). I'll definitely post another update when it is in a usable state. I think it makes a lot of sense to reuse the great work the VSCode team is doing + the excellent ecosystem of language integration, as opposed to trying to reinvent the wheel like in Oni v1.
Awesome! Especially full integration with VSCode Plugins! As soon as you have something to test, I am on it!
