Onivim 2 - 0.5.0 Release

Hi, I'm pleased to announce the release of our 0.5.0 Alpha Build! 

Thanks for following the project - a lot has happened in the past few months!

Language Integrations

A key deliverable for 0.5.0 was expanding our compatibility for VSCode extensions - and adding additional language integrations. To that end, we've added several new language features:

Signature Help

When supported by a VSCode language extension, Onivim will automatically show signature help:


Hover can be triggered by hovering over an element with the mouse, or pressing gh in normal mode:


Format providers - like the Prettier extension - can be engaged using the = operator. For example, gg=G will format the entire document:

The Signature Help and Hover features were implemented by Zach as part of his internship this summer - thanks for the incredible work, Zach!

Not only did Zach build the hover / signature help experiences - he also implemented a Markdown Renderer in Revery, to support these features.

This markdown renderer is also used in our extension details UI:

VSCode Extension Protocol / Compatibility

A common question that comes up with Onivim - how is Onivim's strategy different from plugins like coc.nvim, vim-lsp, or the embedded language server support in Neovim?

This is a bird's eye view of our architecture (today):

In 0.6.0, we'll be exploring adding support for VimL plugins - so there will be some additions to this chart next milestone. But this is the current state of the world.

In the front-end process, it's a native ReasonML/OCaml executable, hosting libvim and using Revery for UI. We also take the back-end of VSCode (well, technically, Code - OSS) - in its entirety - a process called the 'extension host' - and use that to host VSCode extensions.

VSCode extensions provide syntax highlighting, streamlined installation (smart detection of tools), workspace detection - meaning they generally require little configuration to get up-and-running. For an idea of how sophisticated and intricate these plugins can be - it's worth checking out the vscode-python extension. Besides just the core language features, there is an extensive amount of functionality in discovering the virtual environment and setting up the proper interpreter environment.

Even the language features provided by VSCode are a superset of the language server protocol - at this time of this blog post, aspects like semantic highlighting and evaluatable expressions are not part of the language server specification. (To be clear - Onivim 0.5.0 doesn't support these yet, but I want to - and this technical foundation makes it an incremental change to support these - wiring up those APIs and exposing them in Onivim's UI).

By implementing the extension host protocol - we have a foundation in-place for Onivim to leverage all of these capabilities.

The main downside - it's a lot of work to implement this protocol ! It's a much larger API surface area than just the language server protocol. However, the benefit of this work is that we let the extension host handle the communication and management of extensions, and as long as we implement that protocol, we get the benefit of being compatible with every VSCode extension, without modification.

As far as I know - Onivim is the only editor with this hybrid approach: a native front-end combined with the Code extension host back-end.

The fact is - VSCode is ubiquitous and extremely popular - which means language support and plugins tend to receive significant investment and be prioritized first. I believe it makes sense to leverage that investment rather than try to duplicate it - there's just so much momentum in that extension ecosystem.

One other downside - we have to keep the extension host up-to-date. This was much more challenging prior to work done this milestone - we had hacked in a custom transport protocol over stdin/stdout that replaced VSCode's RPCProtocol. This was really tough to maintain and keep-in-sync, because it tended to necessitate resolving some gnarly merge conflicts.

However, we've streamlined this using libuv (via an OCaml wrapper called luv ) - this approach requires very little modification to the extension host, just some small tweaks to package for node vs electron - requires slightly different headers and compilation for native node dependencies.

The good news: We've gotten to the point where we've implemented enough of the protocol such that many extensions 'just work'!

If you find an extension that doesn't work, or a capability missing, please feel free to log an issue for us to track.

There are still many more features I'd like to integrate from the extension host, but at this point, with the technical foundation in-place, that can be done incrementally.

Some examples of extensions that are now unblocked in Onivim:

Go running the golang.Go extension:

Python running the ms-python.python extension:

Java running with the redhat.java extension:

Rust running with the matklad.rust-analyzer extension:

C/C++ running with the llvm-code-analyzer.clangd extension:

Text Rendering Improvements

In addition to his work on signature help and hover, Zach also made several improvements to the text rendering pipeline, including supporting bold/italic variants in our editor surface.

We've changed our default theme to show it off:

In addition, a major missing feature was the lack of font-fallback handling - needed for CJK and Emoji rendering! Font-fallback is not a trivial problem, as this blog post by Raph Levien describes.

It's a case where browsers and terminals handle this already - but using our own UI framework, we have to take care of it, too!

As an example - we used a CJK test file - tofu.md - and before font-fallback, this file was rendering in Onivim as:

...not very useful.

After Zach's work to implement font-fallback, the test file now renders like this:

So much better!

In order to support variable-width characters - so that CJK characters would be rendered properly (when falling back to a font - there's no guarantee it will be monospace or a multiple of the current font size) - Zach implemented support for non-monospace font rendering:

Zach wrote up an excellent blog post about this work: Adding Font Fallback to Revery 

Extension Installation & Management

With all the work done to support VSCode extension compatibility... it's important to make them easy-to-use and install!

A challenge, though, is that the primary marketplace for acquiring extensions - the Visual Studio Code Marketplace - is proprietary:

This means that, unfortunately, Onivim may not utilize the VSCode extension marketplace - only Microsoft products and services may use these APIs.

Luckily, though, as an alternative - the Eclipse organization has stood up a freely available store for VSCode extension - called open-vsx.

We use open-vsx as our endpoint for searching and installing extension. If you download a theme, we'll let you try it out immediately:

Other extensions require restarting the editor... but will activate the next time Onivim opens (we'd like to remove this restriction in a later build!)

I've also published an existing extension called Exuberant Ctags (note: I didn't create it, that's Chris Wheeldon - just wanted to make it available in Onivim) to the open-vsx store, and it's an easy process. The team behind open-vsx has done a great job seeding the store with many popular extensions, as well.


This post has already gotten quite a long, but a few other notable features made it in to 0.5.0:

  • Custom titlebar on Windows
  • Smooth scroll on by default 
  • File drop handler
  • Improved mouse restrictions (resizable windows / panes)
  • Persistence

In addition, Onivim follows a time-delay dual-license model - after 18 months, commits get re-licensed to master. We've started dual-licensing commits here: https://github.com/onivim/oni2-mit


I'll be doing a talk in September at vimconf.live, which is really exciting!

If you haven't already... check it out - there will be a lot of great speakers, talks, and workshops.

Next Steps

There were a couple of language features that didn't make it for 0.5.0, so we'll pushing those as a stretch goal for 0.6.0:

  • Codelens
  • Snippets
  • Output (useful for debugging extension issues)

There is still a lot of work left, or missing functionality to wire up, in terms of the extension host:

  • Tasks
  • Tree views
  • Debug adapters
  • Notebooks
  • Custom editors

But these will be further out - post 0.6.0. Our primary goal for 0.60 is improving our Vim integration, and providing a first-class experience - taking into account feedback we've received:

This is the main goal for 0.6.0 - to  improve the vim-ness of Onivim.

We'll be continuing the on-going work of tackling daily-editor-blockers and bugs - I've kept the 'Alpha' moniker for 0.5.0, because there are still some crash / daily editor blockers. Once we've worked through those - I'll upgrade our status to 'Beta' - hopefully for 0.6.0!

The VimL support  & keyboard mapping support is the last major technical blocker to realizing our vision of an editor with the best of Vim & VSCode - an editor that is maximally productive. I'm very excited to be taking that on this milestone.

You can head over to our Early Access Portal to grab the latest builds.

Thank you!

I want to thank everyone who has helped us with the project - pre-ordering, supporting on Patreon, contributing PRs, logging issues, giving feedback, helped us troubleshoot issues... THANK YOU for helping us to get this far!

Huge thanks to Zach & Ryan for all their help in the 0.50 milestone, and Glenn for the window layout and persistence contributions.

This is a very ambitious project - and we wouldn't have made it this far with your help. I hope everyone is staying safe and healthy. Cheers!

- The Onivim 2 Team (Bryan, Ryan, Zach)

Become a patron to

Unlock 4 exclusive posts
Be part of the community
Connect via private message