←back to thread

301 points nogajun | 9 comments | | HN request time: 0.001s | source | bottom
1. tiffanyh ◴[] No.45941935[source]
I was always bummed OniVim v2 didn't take off.

It was a native IDE but fully supported VS Code plugin system.

https://web.archive.org/web/20210627210456/https://v2.onivim...

replies(2): >>45943097 #>>45943304 #
2. arbitrandomuser ◴[] No.45943097[source]
onivim also seperated the core functionality of the vim editor into a seperate library libvim , this would have been great for other people looking to make their own gui frontend to vim .

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

3. koiueo ◴[] No.45943304[source]
From a quick glance, I can't understand the target audience.

Vim users would be annoyed by bizarre input lag of an electron application and perhaps by EULA. VS code users don't really care about Vim...

replies(2): >>45943434 #>>45960270 #
4. forgotpwd16 ◴[] No.45943434[source]
>of an electron application

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).

replies(1): >>45944218 #
5. koiueo ◴[] No.45944218{3}[source]
Oh, ok, now I'm curious to try it despite EULA (although these days the wide choice of (neo)vim distributions utilizing LSP makes their offering less appealing). Thanks for the clarification.

The site doesn't stress the not-electron part enough, maybe that contributed to the failure.

replies(1): >>45946071 #
6. forgotpwd16 ◴[] No.45946071{4}[source]
Should've probably mentioned it before but it actually used a dual-license model by having an MIT version that lagged behind upstream for 18 months (could be found in oni2-mit repo). During last month when development stopped it was fully re-licensed under MIT (hence oni2-mit repo no longer exists).
7. iLemming ◴[] No.45960270[source]
> VS code users don't really care about Vim

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.

replies(1): >>45970002 #
8. koiueo ◴[] No.45970002{3}[source]
I'm not sure what you disagree with. I'm saying VS Code isn't targeting Vim users, and core VS Code user base doesn't care about Vim.

I too can't take a seriously an editor which doesn't have Vim keybindigns at least in a very basic form.

replies(1): >>45970842 #
9. iLemming ◴[] No.45970842{4}[source]
Ah, I've misinterpreted it then.

> 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.