It was a native IDE but fully supported VS Code plugin system.
https://web.archive.org/web/20210627210456/https://v2.onivim...
It was a native IDE but fully supported VS Code plugin system.
https://web.archive.org/web/20210627210456/https://v2.onivim...
neovim does not give a libneovim, but exposes an rpc where you communicate with neovim running as another process, this I would have thought have more latency but apparently is fast enough , this is how the vscode plugin for neovim is able to provide a near complete vim experience. Other neovim guis like neovide use this too
It isn't an Electron application*, that's why GP said native. The EULA part though was probably a block to adoption.
*It uses Revery, a, made by OniVim's devs, cross-platform GUI framework (similar to Flutter but build on Reason/OCaml).
The site doesn't stress the not-electron part enough, maybe that contributed to the failure.
I disagree. vim-navigation is imperative for a huge number of devs. It's an amazing, practical, beautiful model. I would've never tried emacs if Evil-mode wasn't so fantastic. And that yet another reason for why vscode never is appealing to me - every one and each vim extension for it has tons of glaring deficiencies.
I too can't take a seriously an editor which doesn't have Vim keybindigns at least in a very basic form.
> I too can't take a seriously an editor which doesn't have Vim keybindigns at least in a very basic form.
tbh, I can't take any experienced programmer seriously if they never even tried learning at least some basic vi-navigation commands. I'm like, "what? have they never used `sed`, `less`, `more` or never read man pages? have they never logged to a remote machine? why kind of a coder doesn't know any of this shit?" I mean I get it, it's not universally appealing to everyone, some prefer not to bother. But not knowing it at all? That's weird to me. And yes, I agree - If you're making an editor for coders (standalone, embedded, web or native), modal navigation must be possible.