XaiJu
onivim
onivim

patreon


Oni v2 - Update #2

Hey all,

First off - want to say a huge THANK YOU for your support! It's so helpful in getting this project off the ground.

Been a while since the last update, so wanted to share news in a few areas - Oni v2, Branding, and Revery.

Oni v2

I'll start this out by sharing a gif of the latest build of Oni2:

Previous posts were all static screenshots (because the UI was static...) - but it feels great to actually be able to share something in motion :)  Just to set expectations - the editor is still not really usable yet; but hopefully within a month or two it could start to be usable and useful. 

The takeaway though - we're slowly making progress! A few things that have come in:

- Initial integration with the command line / wild menu (thanks to Akin!)
- Integration with Neovim's buffer updates API
- Pixel-level scrolling (maybe not smooth yet.... but soon!)
- Mini-map scrollbar

Some of the architecture investments and up-front investigation we did are starting to pay off - the pixel-level scrolling and mini-map in particular are two things that we were never able to accomplish in Oni v1's architecture. It's very exciting to see progress in these areas!

We've also invested in performance profiling so that we can verify perf build-over-build:

We still have a lot of work to do with perf to meet our goals - but a cool thing about OCaml/ReasonML is that the garbage collector is deterministic - meaning, these allocations will always be the same each run. That means we can set up our benchmarking tools to run on CI and verify changes don't regress memory performance... deterministically. We were never able to set up these types of performance tests in Oni1.

The items next up on my roadmap are:

Branding

Thank you all everyone who helped participate in our logo / design poll and gave feedback! 

I'm pleased to announce that we chose a winning direction - 

It was a pretty tough call... opinions were spread across the board regarding the logo / branding.

We decided to pursue this direction because we felt the "retrofuturistic" vibe fit well with what we were trying to do with Onivim2 - a lot of the technology we're using in our new stack is 'retro' but, in a sense, reimagined: Vi -> Vim -> Neovim, Ocaml -> ReasonML... it's like we're taking a step back, re-evaluating our foundation, and building a new future for Onivim.

We also liked that it is a different and unique branding compared to other editors. So hopefully we can carve a niche as this 'retrofuturistic' vim.

Revery

I've mentioned in some previous posts about how we built out a 'core' platform for the editor UI - called Revery - and there's actually been a lot of progress on this front. We've been very fortunate to have some tremendous help from the ReasonML community - help implementing features like text wrapping, additional UI components, examples, bug fixes, etc. 

We built out some of the core tech in January, and it can even run in the browser , but it's really meant for native (and it's much faster in native, too).

Revery's fast, flutter-like, platform agnostic approach - preserving the ergonomics and developer experience of React - seemed to resonate with some people.

We teamed up with a similar project called Brisk, and they've helped us build out the native React implementation we use for Revery and Onivim 2.

We're investigating several items in terms of next steps with Revery - but items top of mind for Onivim 2 include better text rendering (ie, supporting subpixel anti-aliasing where it makes sense, texture atlasing for perf), and continuing to improve performance. Manuel is investigating moving from our home-grown renderer to the Skia renderer, which is actually the same one used by Flutter. We're very excited about the progress and potential of the platform so far.

I'll be talking about Revery at ReactEurope - let me know if you'll be around :)

Cheers &  THANK YOU again for your support!

- Bryan







Comments

Thanks Parker! :) We're benefiting in this case from the significant engineering investment that has gone into the OCaml toolchain! We'll hopefully start on the VSCode extension API shortly (within a couple weeks). It's a moonshot but we're also making good progress!

Wow, this is all really impressive stuff. Deterministic profiling in the CI pipeline is something I never would have thought possible. You know you're onto something when a benefit (I was going to say side effect but it didn't seem appropriate :) like that pops out of your architecture (the determinism, not the pipeline :). I'm really curious how porting the vscode extension API was managed. I'll have to look for that in the repo. I have a feeling you guys are going to be internet famous in the near future. :)

Just Parker


More Creators