Onivim 2 is a retro-futuristic modal editor(v2.onivim.io)
v2.onivim.io
Onivim 2 is a retro-futuristic modal editor
https://v2.onivim.io
135 comments
Hey, Onivim contributor here.
I assume by FOMO you mean the increased license price as time goes on, but as far as I understand (that decision was made before me), the idea is that the product becomes more valuable over time as a result of more features being added. You can still buy a one time license as of right now.
As far as abandonment is concerned, I can let you know that hasn’t been discussed. Bryan recently went on his first vacation since working on Oni, but work has resumed since he returned.
Feel free to let me know if you have any other questions — the Discord is always open!
I assume by FOMO you mean the increased license price as time goes on, but as far as I understand (that decision was made before me), the idea is that the product becomes more valuable over time as a result of more features being added. You can still buy a one time license as of right now.
As far as abandonment is concerned, I can let you know that hasn’t been discussed. Bryan recently went on his first vacation since working on Oni, but work has resumed since he returned.
Feel free to let me know if you have any other questions — the Discord is always open!
>the idea is that the product becomes more valuable over time as a result of more features being added
I have a hard time believing that's the main motivation
I have a hard time believing that's the main motivation
Why?
I backed it early and paid less for a half-implemented editor but wanted to show support.
The later you back the more that's actually built.
What main motivation do you think the seller has? It's basically an early bird discount.
I backed it early and paid less for a half-implemented editor but wanted to show support.
The later you back the more that's actually built.
What main motivation do you think the seller has? It's basically an early bird discount.
Many things improve but go down in price. Can't articulate fully but it instinctively feels like a rationalisation rather than a reason.
>It's basically an early bird discount.
When has that not been a marketing tactic
>It's basically an early bird discount.
When has that not been a marketing tactic
Exactly. It is a marketing tactic. A very fair and obvious one, at that. So what? Hardworking programmers are not allowed to market their stuff?
Was the same licensing method for Minecraft in beta
And is the same model used by many 'early access' titles, pay less up front for the incomplete game to fund the completion of the future full-price game.
Interestingly, I've seen some devs turn the concept on its head and charge more up front, kind of to say "only buy in now if you are really doing this to support development, and in return you'll get an early release build - but you aren't buying the game early."
Interestingly, I've seen some devs turn the concept on its head and charge more up front, kind of to say "only buy in now if you are really doing this to support development, and in return you'll get an early release build - but you aren't buying the game early."
How can we get a one time license? I tried it when it was still the oni repo 2 years ago and would be keen to try again. And is there a summary of how it was different from oni (1?)
You can do a one-time purchase, IIRC it was ~$45 around a month ago when I purchased it. I wanted to buy outright instead of go the Patreon route.
As far as abandonment, I had a fairly subtle issue with it shortly after starting to try it, and on github I opened an issue and got help troubleshooting it in a day, we were able to identify the problem and there was a fix in the build the following day.
As far as abandonment, I had a fairly subtle issue with it shortly after starting to try it, and on github I opened an issue and got help troubleshooting it in a day, we were able to identify the problem and there was a fix in the build the following day.
> I really wanted to like Onivim 2, but went back to Visual Studio code after supporting the creator on Patreon for a while.
Same, though I went back to MacVim. I thought they might bring something new to the table, bit it felt so much like VSCode + a vim plug-in, except with a subscription.
I was really just hoping for MacVim bit with a nicer UI.
Same, though I went back to MacVim. I thought they might bring something new to the table, bit it felt so much like VSCode + a vim plug-in, except with a subscription.
I was really just hoping for MacVim bit with a nicer UI.
I stared at the landing page for a good 15 seconds wondering "why is that picture... breathing?"
It made it so much hard to just take in and understand the UI. Glad I'm not the only one that felt that way.
Someone had to make the conscious choice to make it do that, then add the code for it — I’d love to know what their rationale was. I find it difficult to imagine how they thought it’d make things better, and how they could have missed the downsides of it.
I think it’s something they really should fix, because it screams “poor judgment”, which gives a bad first impression of their work.
I think it’s something they really should fix, because it screams “poor judgment”, which gives a bad first impression of their work.
The animation up and down causes blurriness on my monitor, presumably from aliasing or something
Thanks for the feedback! I removed the animation... hopefully not as jarring now.
Same here!
I've been trying some vim "alternatives" recently. Onivim has been on my radar for years, but I only recently started trying it out. No real opinion on it yet other than: I like the idea of VSCode plugins (the Ansible plugin is apparently quite good, and I've been wanting to try it).
Other alternatives I'm playing with: Kakoune, SpaceVim, and LunarVim. The last two are vim configs with plugins.
LunarVim and Kakoune (kak) have TreeSitter, for really, really good syntax highlighting. Kak needs a plugin for it.
Kak has a fairly interesting multi-cursor setup that reminds me in some ways of "sam" (the little I've played with it). For doing some sorts of macro-like functions to modify many lines, it's pretty slick.
Other alternatives I'm playing with: Kakoune, SpaceVim, and LunarVim. The last two are vim configs with plugins.
LunarVim and Kakoune (kak) have TreeSitter, for really, really good syntax highlighting. Kak needs a plugin for it.
Kak has a fairly interesting multi-cursor setup that reminds me in some ways of "sam" (the little I've played with it). For doing some sorts of macro-like functions to modify many lines, it's pretty slick.
Does Kakoune really have a plugin for syntax highlighting with Tree-sitter? I was under the impression that there was only a plugin for structural selections (kak-tree). I would really like more accurate syntax highlighting in Kakoune, particularly in Markdown.
I guess I misunderstood kak-tree. Seems like you are correct. Thanks for that pointer.
If you like Kak and are vaguely familiar with Sam I suggest trying out vis:
> Vis aims to be a modern, legacy-free, simple yet efficient editor, combining the strengths of both vi(m) and sam.
https://github.com/martanne/vis
"Differences from Kakoune": https://github.com/martanne/vis/wiki/Differences-from-Kakoun...
> Vis aims to be a modern, legacy-free, simple yet efficient editor, combining the strengths of both vi(m) and sam.
https://github.com/martanne/vis
"Differences from Kakoune": https://github.com/martanne/vis/wiki/Differences-from-Kakoun...
Thanks, that was the other one I was actually trying to remember but could only come up with sam. Went through the Wikipedia text editors page a few times and just couldn't remember it.
> LunarVim and Kakoune (kak) have TreeSitter, for really, really good syntax highlighting.
While Vim's regexp-based syntax highlights certainly has limitations even in fairly simple cases, and I would love to see something better, the downside of these things is that people get carried away and add colours to everything.
A little bit of colour is very helpful. Ten different colours seemingly chosen at random is not.
I tried that LunarVim thing, which was a somewhat frustrating experience as it doesn't work on light terminals at all (setting background=light and :colorscheme default seems completely broken), somewhat ironic that a project which bills "better colours" as one of its main points doesn't actually work with a common background colour, but okay.
The colours for Go are ... not great. Is there any point in highlighting string literals in a different colour than numbers, and bools yet another colour? What extra information does that convey? Or what's the point of highlighting operators in blue? Giving _ its own special colour? That doesn't make it easier to read – quite the opposite as there's an overload of information.
There are 10 unique colours with the default Go colorscheme (vs. 4). This alone is noisy and distracting, but they're not even especially well chosen as there's significant overlap with completely unrelated things highlighted in a different colour (escape sequences the same as functions, or nil the same as func; no idea what the point of that is as it's not even a keyword).
In short, these tools are nice, but I fear it will lead to an explosion of extremely badly designed colour schemes where people add stuff "because they can" and "ohhh, colours!" without actually thinking if it's a good idea or not. I saw this with vim-go where people constantly sent in patches for dubious colour scheme changes, and you spend forever argueing why it's not a good idea, and at least "it's very slow and will complicate things a lot" was a meaningful barrier.
Darn I sound like a grumpy old man... But really, these are design issues I don't see enough consideration of. No colours is bad; some colours is super helpful, but loads of random colours is even worse than no colours. There's some research on it too; NASA did research for colour usage in flight control systems for example and came to the same conclusion (which I can't seem to find right now). Another fun example is the "count the triangles" vs "count the red shapes" in [1]; counting the red shapes is easier, but counting the triangles is easier in the monochrome version vs. the coloured one.
[1]: https://homepages.cwi.nl/~steven/Talks/2019/11-21-dijkstra/
While Vim's regexp-based syntax highlights certainly has limitations even in fairly simple cases, and I would love to see something better, the downside of these things is that people get carried away and add colours to everything.
A little bit of colour is very helpful. Ten different colours seemingly chosen at random is not.
I tried that LunarVim thing, which was a somewhat frustrating experience as it doesn't work on light terminals at all (setting background=light and :colorscheme default seems completely broken), somewhat ironic that a project which bills "better colours" as one of its main points doesn't actually work with a common background colour, but okay.
The colours for Go are ... not great. Is there any point in highlighting string literals in a different colour than numbers, and bools yet another colour? What extra information does that convey? Or what's the point of highlighting operators in blue? Giving _ its own special colour? That doesn't make it easier to read – quite the opposite as there's an overload of information.
There are 10 unique colours with the default Go colorscheme (vs. 4). This alone is noisy and distracting, but they're not even especially well chosen as there's significant overlap with completely unrelated things highlighted in a different colour (escape sequences the same as functions, or nil the same as func; no idea what the point of that is as it's not even a keyword).
In short, these tools are nice, but I fear it will lead to an explosion of extremely badly designed colour schemes where people add stuff "because they can" and "ohhh, colours!" without actually thinking if it's a good idea or not. I saw this with vim-go where people constantly sent in patches for dubious colour scheme changes, and you spend forever argueing why it's not a good idea, and at least "it's very slow and will complicate things a lot" was a meaningful barrier.
Darn I sound like a grumpy old man... But really, these are design issues I don't see enough consideration of. No colours is bad; some colours is super helpful, but loads of random colours is even worse than no colours. There's some research on it too; NASA did research for colour usage in flight control systems for example and came to the same conclusion (which I can't seem to find right now). Another fun example is the "count the triangles" vs "count the red shapes" in [1]; counting the red shapes is easier, but counting the triangles is easier in the monochrome version vs. the coloured one.
[1]: https://homepages.cwi.nl/~steven/Talks/2019/11-21-dijkstra/
Fully agree on the color issue. Most color schemes in any editor today look like rainbows, very distracting for day to day usage. I ended up building my own color scheme for vim using only 4 colors.
I've used lapis256 for ages because it's built on subtle differences in the shades of blue instead of so much hue contrast.
Well, that's not the problem with TreeSitter. There is enough of this even with the default regexp-based syntax highlights.
Anyway - one can always create a perfect scheme for them to use.
Anyway - one can always create a perfect scheme for them to use.
No, it's not; I never intended to imply it was. Like I said: "I would love to see something better". Making a syntax file right now that's 1) truly fully correct, and 2) fast is often quite hard to create and maintain.
Most Vim defaults are fairly timid in comparison to what I've seen of tree-sitter. Right now the limitations often prevent too much "shizzle" from being added, which is useful in a kind of perverse sort of way.
> Anyway - one can always create a perfect scheme for them to use.
It requires making my own syntax files for every language I use, and starting or opening a new language now needs to begin with configuring this. Not really looking forward to such a future.
Most Vim defaults are fairly timid in comparison to what I've seen of tree-sitter. Right now the limitations often prevent too much "shizzle" from being added, which is useful in a kind of perverse sort of way.
> Anyway - one can always create a perfect scheme for them to use.
It requires making my own syntax files for every language I use, and starting or opening a new language now needs to begin with configuring this. Not really looking forward to such a future.
>It requires making my own syntax files for every language I use, and starting or opening a new language now needs to begin with configuring this. Not really looking forward to such a future.
Why would you need this (unless your language is not in https://github.com/nvim-treesitter/nvim-treesitter#supported... ?)
Why would you need this (unless your language is not in https://github.com/nvim-treesitter/nvim-treesitter#supported... ?)
What's most interesting for me here is Revery, the GUI framework. React-like, cross-platform, native-code, MIT-licensed.
Yes, it's not using native widgets (so no built-in accessibility), but that might be fine in many cases.
Yes, it's not using native widgets (so no built-in accessibility), but that might be fine in many cases.
I’ve actually been working on adding more support for native widgets in Revery, mostly focusing on macOS since thats my daily OS, but Windows too. You can now use native buttons and menus, and I’m looking into adding other native inputs (like text fields).
This is great news. Native text inputs have a lot of important affordances like navigation keys, selection, and spelling.
Looking forward to seeing it displace Electron.
Back in the days, I would have bet on Revery as Electron replacement.
But currently, Tauri seems like a more viable option.
But currently, Tauri seems like a more viable option.
Not soon: however I like ML-style languages, it's JS / TS what has the mass market adoption now.
It's not even the language, it's not much harder to learn than TS. It's the smaller library ecosystem of Reason / OCaml.
It's not even the language, it's not much harder to learn than TS. It's the smaller library ecosystem of Reason / OCaml.
But they get a simpler, sounder type system in OCaml as a result which should make maintenance easier for them. Given that they want this style of programming the ergonomics should be a lot easier than TypeScript as well.
Is it still running through javascript? I get confused by all the different interpretations of native.
Its written mostly in ReasonML (syntax for OCaml) with a bunch of C-libs wrapped in OCaml (Skia/Harfbuzz/SDL2 etc), so it compiles properly to native in the same way that normal OCaml code would.
The only JS in Revery is for some utility scripts and some aroud an option to compile to JS (which isn't functional at the moment, but the idea being you could compile to JS if you wished, with stubs to fill in the blanks for API calls that would normally hit Skia etc).
The only JS in Revery is for some utility scripts and some aroud an option to compile to JS (which isn't functional at the moment, but the idea being you could compile to JS if you wished, with stubs to fill in the blanks for API calls that would normally hit Skia etc).
How fast does this feel compared to VS Code?
I went into the whole onivim -> revery -> reason rabbit hole and the native code compilation is compelling, but Flutter does the same thing and is pretty slow.
I went into the whole onivim -> revery -> reason rabbit hole and the native code compilation is compelling, but Flutter does the same thing and is pretty slow.
It feels faster than VSCode, but I would wait until at least 0.6 before trying it out more.
Startup time is almost instantaneous. It's very responsive and works well on an old machine with only 4Go Ram. Not ready to abandon the terminal yet but if I ever do, this will be my choice.
I tried it and it's buttery smooth. Feels like notepad.
It's unfortunate that some VS Code extensions, e.g. remote development extensions, can't be used in Onivim 2 due to license restrictions[1].
[1]: https://github.com/VSCodium/vscodium/issues/196#issuecomment...
[1]: https://github.com/VSCodium/vscodium/issues/196#issuecomment...
Can any VS Code extensions be used in Onivim 2? Despite appearances, Onivim isn't a VS Code fork, it doesn't use Electron, and it's not written in Javascript-- it just happens to take substantial inspiration from VS Code's UI.
We host the VSCode extension host, which is how Oni2 can use VSCode extensions.
I.e, the whole front end and core editor is native code (ReasonML/C), and then there is a nicely typed interface where we communicate with a node instance to run VSCode extensions. We broadly end up with Oni2 <-> Ext Host <-> Extension.
We have to implement the Oni2 side for each thing, so parse the message sent, and how to action on that and render it, but it lets us run VSCode extensions, still in a native editor.
There are some caveats, like the license issue mentioned, the largest being that extensions that heavily depend on rendering custom components / web pages aren't possible, just since Revery has no browser etc to render anything like that with.
We've focused on language ones to start though, and that has meant we support a decent selection of langauges as adding one feature unblocks loads of extensions.
I.e, the whole front end and core editor is native code (ReasonML/C), and then there is a nicely typed interface where we communicate with a node instance to run VSCode extensions. We broadly end up with Oni2 <-> Ext Host <-> Extension.
We have to implement the Oni2 side for each thing, so parse the message sent, and how to action on that and render it, but it lets us run VSCode extensions, still in a native editor.
There are some caveats, like the license issue mentioned, the largest being that extensions that heavily depend on rendering custom components / web pages aren't possible, just since Revery has no browser etc to render anything like that with.
We've focused on language ones to start though, and that has meant we support a decent selection of langauges as adding one feature unblocks loads of extensions.
> Can any VS Code extensions be used in Onivim 2?
Yes, this is basically the entire point of Onivim (use vscode extensions with vim). https://open-vsx.org/
Yes, this is basically the entire point of Onivim (use vscode extensions with vim). https://open-vsx.org/
Was an early adopter in 2019, right now not so much. No proper channel distributions, no hidpi support, UI clone/copy/paste of vscode - all things which actually makes user sad... After all going in the wrong direction, sorry.
So, an open source editor based on neovim is being replaced with a proprietary editor with it's own fork of vim as a backend? That's a little disappointing to me.
I managed to build it and test it a little bit and damn, it's not just marketing to describe it as having an insanely fast start up time. It launched almost as quick as I can spawn new client windows from my Emacs daemon and scrolling and text editing seems to be buttery smooth as well.
However, I really don't like the fact that there is no way to navigate tabs using vim's commands.
I also find the VSCode similarities distracting and it seems to be causing confusion to would be investors of this due to the assumption it's some branch of it as opposed to a completely new editor.
Finally, is there a way to remove the system bar on the top in the configuration? I can toggle most elements of the UI but that system bar is visible even in zen mode and I never use it in any text editor with support for keyboard driven commands.
However, I really don't like the fact that there is no way to navigate tabs using vim's commands.
I also find the VSCode similarities distracting and it seems to be causing confusion to would be investors of this due to the assumption it's some branch of it as opposed to a completely new editor.
Finally, is there a way to remove the system bar on the top in the configuration? I can toggle most elements of the UI but that system bar is visible even in zen mode and I never use it in any text editor with support for keyboard driven commands.
Thanks for trying it out and sharing your feedback, appreciate it!
> However, I really don't like the fact that there is no way to navigate tabs using vim's commands.
There's a related feature request here: https://github.com/onivim/oni2/issues/3673
> I also find the VSCode similarities distracting and it seems to be causing confusion to would be investors of this due to the assumption it's some branch of it as opposed to a completely new editor.
I agree, this is consistent feedback we get... There's a ton of potential to have a built-for-modal-editing UX that we're missing at the moment.
> Finally, is there a way to remove the system bar on the top in the configuration? I can toggle most elements of the UI but that system bar is visible even in zen mode and I never use it in any text editor with support for keyboard driven commands.
Yes, there is a `window.menuBarVisibility` configuration setting: https://onivim.github.io/docs/configuration/settings#layout
> However, I really don't like the fact that there is no way to navigate tabs using vim's commands.
There's a related feature request here: https://github.com/onivim/oni2/issues/3673
> I also find the VSCode similarities distracting and it seems to be causing confusion to would be investors of this due to the assumption it's some branch of it as opposed to a completely new editor.
I agree, this is consistent feedback we get... There's a ton of potential to have a built-for-modal-editing UX that we're missing at the moment.
> Finally, is there a way to remove the system bar on the top in the configuration? I can toggle most elements of the UI but that system bar is visible even in zen mode and I never use it in any text editor with support for keyboard driven commands.
Yes, there is a `window.menuBarVisibility` configuration setting: https://onivim.github.io/docs/configuration/settings#layout
As others stated the new neovim is crazy cool (Lua scripting etc.).
Was also playing with amp (nice defaults) and helix (my favourite of the week) https://helix-editor.com/
Looking for a modern editor written in go or rust :)
Was also playing with amp (nice defaults) and helix (my favourite of the week) https://helix-editor.com/
Looking for a modern editor written in go or rust :)
I bought a license like 6 months ago and have tried a couple of times back and forth during this period. I thought this was exactly what I was looking for. A modern mix on Vim and VSCode. I was pretty disappointed though tbh. You can really just VSCode with the Vim extension, or just use actual Vim. I think there is space for a product like this though, so A for effort!
Much like you, I think I'm probably the target audience for this.
One of the things that stops me from using neovim - regardless of any changes I'd like - is the removal of gvim. I like my gvim candy; SVG icons in sign columns, better modifier support in maps, drag and drop when in command line, $things_ive_forgot_i_use.
Likewise, I also believe the idea of onivim is worth a licence fee, even it turns out I can't get behind it. It just feels like one of those projects I want to see succeed, even if it isn't for me.
One of the things that stops me from using neovim - regardless of any changes I'd like - is the removal of gvim. I like my gvim candy; SVG icons in sign columns, better modifier support in maps, drag and drop when in command line, $things_ive_forgot_i_use.
Likewise, I also believe the idea of onivim is worth a licence fee, even it turns out I can't get behind it. It just feels like one of those projects I want to see succeed, even if it isn't for me.
Onivim has a high chance of becoming the best heavyweight GUI Vim IDE distribution over the coming years. I bought a once-off lifetime commercial license a good while ago and now get nightly updates. I wish the team all the success in the world.
There are external NeoVim GUIs though, for example Neovide[1].
[1] https://github.com/Kethku/neovide
[1] https://github.com/Kethku/neovide
Yeah, I've tried a few. I can't quite put my finger on what is wrong, but the ones I've tried just don't feel right.
gnvim¹ was the most usable for me. However, it isn't without problems for my use case. To use my earlier example, switching would mean patching fonts or using overrides in fonts.conf to fake the use of icons in signs.
I did take another look just now², and there a few more for me to try out ;)
¹ https://github.com/vhakulinen/gnvim ² https://github.com/neovim/neovim/wiki/Related-projects
gnvim¹ was the most usable for me. However, it isn't without problems for my use case. To use my earlier example, switching would mean patching fonts or using overrides in fonts.conf to fake the use of icons in signs.
I did take another look just now², and there a few more for me to try out ;)
¹ https://github.com/vhakulinen/gnvim ² https://github.com/neovim/neovim/wiki/Related-projects
They need to move abandoned projects into another table to avoid confusion.
Why does it try to look like vscode clone?
I understand that the vscode ecosystem is awesome. However, I always felt like the UI was severaly lacking behind proper IDE like intellij.
Give me intellij-like documentation popup, run, build & debug buttons and debug UI, and I will switch in an instant!
I understand that the vscode ecosystem is awesome. However, I always felt like the UI was severaly lacking behind proper IDE like intellij.
Give me intellij-like documentation popup, run, build & debug buttons and debug UI, and I will switch in an instant!
Hey, Onivim contributor here.
Unfortunately none of the main contributors are designers. I think we end up with a very VSCode-similar look because in terms of UX that’s our main inspiration. We do diverge in some areas, though.
Debug functionality is on our radar and it will hopefully be in relatively soon!
Unfortunately none of the main contributors are designers. I think we end up with a very VSCode-similar look because in terms of UX that’s our main inspiration. We do diverge in some areas, though.
Debug functionality is on our radar and it will hopefully be in relatively soon!
look at something like Obsidian for modern editor UX
This is what irked me about it. We already have VS Code. For me the defaults there are tolerable, but not the pinnacle of ergonomics.
Buying software without a trial makes me disinterested. I still want to learn using vim every day, but won't commit to this text editor/vsx-powered IDE, unless I find out that I have the guts to use it every day.
Also, there is VIM mode for VS Code, I guess.
> Also, there is VIM mode for VS Code, I guess.
I feel like this is something said by people who are more invested in VS Code than vim. The main vim plugin for VS Code is straight trash.* It's slow, buggy, and unintuitive; while lacking the extensibility that vim has. At least IDEAVim, which has the same limitations of being built in another IDE, replicates enough of the common plugins to be pleasant.
It's also worth noting that onivim is not VS Code repackaged. It is not an electron app, and it doesn't appear to use the monaco editor. They have apparently taken great design inspiration from VS Code, which I think is a fairly diffident decision.
Overall, I'm looking at neovim nightly and not knowing why onivim is a thing. I can understand the appeal of a GUI vim, but implementing a vim backend is a monumental task if you intend to be compatible with existing vim plugins (and you should). Nvim 0.5 has native lua, and now freed from vimscript the quality of plugins is improving continuously. I just can't see a way for a 'third vim' - if you don't start with vimscript you won't be compatible, but if you do you're already outdated.
* There are a few attempts to splice VS Code and neovim, all of these are awful.
I feel like this is something said by people who are more invested in VS Code than vim. The main vim plugin for VS Code is straight trash.* It's slow, buggy, and unintuitive; while lacking the extensibility that vim has. At least IDEAVim, which has the same limitations of being built in another IDE, replicates enough of the common plugins to be pleasant.
It's also worth noting that onivim is not VS Code repackaged. It is not an electron app, and it doesn't appear to use the monaco editor. They have apparently taken great design inspiration from VS Code, which I think is a fairly diffident decision.
Overall, I'm looking at neovim nightly and not knowing why onivim is a thing. I can understand the appeal of a GUI vim, but implementing a vim backend is a monumental task if you intend to be compatible with existing vim plugins (and you should). Nvim 0.5 has native lua, and now freed from vimscript the quality of plugins is improving continuously. I just can't see a way for a 'third vim' - if you don't start with vimscript you won't be compatible, but if you do you're already outdated.
* There are a few attempts to splice VS Code and neovim, all of these are awful.
> but implementing a vim backend is a monumental task if you intend to be compatible with existing vim plugins
We skipped that and haven't implemented any vim backend at all!
We use/made libvim[1], which is just the vim source, that we've essentially turned into a library. So its the vim code base with terminal UI stuff stripped out, and an interface added for us to hook into it. The README of that repo has some good insight into that (including why we didn't use neovim here, as much as the team all loves nvim).
We don't support vimscript stuff at the moment, but its in progress as all the vim source code is there to load/run it as normal, its just about integrating is properly into Oni2 (making sure keybinds are working, commands are properly loaded, packing stuff up nicely for distrib etc).
(There is some other motivation bits in this doc[2]. Its outdated since we haven't edited it since before the project started, but it outlines the motivations we went in with etc).
[1]: https://github.com/onivim/libvim [2]: https://github.com/onivim/oni2/blob/master/docs/MOTIVATION.m...
We skipped that and haven't implemented any vim backend at all!
We use/made libvim[1], which is just the vim source, that we've essentially turned into a library. So its the vim code base with terminal UI stuff stripped out, and an interface added for us to hook into it. The README of that repo has some good insight into that (including why we didn't use neovim here, as much as the team all loves nvim).
We don't support vimscript stuff at the moment, but its in progress as all the vim source code is there to load/run it as normal, its just about integrating is properly into Oni2 (making sure keybinds are working, commands are properly loaded, packing stuff up nicely for distrib etc).
(There is some other motivation bits in this doc[2]. Its outdated since we haven't edited it since before the project started, but it outlines the motivations we went in with etc).
[1]: https://github.com/onivim/libvim [2]: https://github.com/onivim/oni2/blob/master/docs/MOTIVATION.m...
It is my understanding that one of the initial driving forces behind NeoVim was to allow for easier embedding, such as what you appear to be doing here. If this is true, why did you decide to go with traditional vim rather than NeoVim? Additionally, since nvim lets you choose between Lua or Vimscript for configuration/extension, and I personally find Lua far more intuitive than Vimscript...
> If this is true, why did you decide to go with traditional vim rather than NeoVim?
Answered here [1].
> I personally find Lua far more intuitive than Vimscript...
One of the biggest motivating factors for the rewrite of Oni was the limitations imposed by Vim/Neovim of a terminal grid of characters in the rendering layer: “Neovim treats the visible screen as a grid of cells” [2]. This precluded implementing CodeLens amongst other things [3].
I’m also a fan of Lua — I’ve written a substantial amount of Fennel — but given Oni’s goals, revamping Vim’s rendering layer is of higher importance than Lua support, particularly since the VSCode extension ecosystem is being relied upon anyway. Onivim is designed as more of a direct challenge to heavyweight IDEs than as a substitute for Vim. I already switch between Vim and VSCode depending on requirements, but it’d be great to have the best possible support for modal editing in VSCode.
[1]: https://github.com/onivim/libvim#why-is-libvim-based-on-vim-...
[2]: https://onivim.github.io/docs/other/motivation#a-new-view-la...
[3]: https://onivim.github.io/blog/2021/02/03/release-0.5.3
Answered here [1].
> I personally find Lua far more intuitive than Vimscript...
One of the biggest motivating factors for the rewrite of Oni was the limitations imposed by Vim/Neovim of a terminal grid of characters in the rendering layer: “Neovim treats the visible screen as a grid of cells” [2]. This precluded implementing CodeLens amongst other things [3].
I’m also a fan of Lua — I’ve written a substantial amount of Fennel — but given Oni’s goals, revamping Vim’s rendering layer is of higher importance than Lua support, particularly since the VSCode extension ecosystem is being relied upon anyway. Onivim is designed as more of a direct challenge to heavyweight IDEs than as a substitute for Vim. I already switch between Vim and VSCode depending on requirements, but it’d be great to have the best possible support for modal editing in VSCode.
[1]: https://github.com/onivim/libvim#why-is-libvim-based-on-vim-...
[2]: https://onivim.github.io/docs/other/motivation#a-new-view-la...
[3]: https://onivim.github.io/blog/2021/02/03/release-0.5.3
Seems they had trouble implementing that with Neovim[0]. Relevant reddit thread[1]
0: https://github.com/onivim/libvim#why-is-libvim-based-on-vim-...
1: https://www.reddit.com/r/neovim/comments/cdf36v/onivim2_chan...
0: https://github.com/onivim/libvim#why-is-libvim-based-on-vim-...
1: https://www.reddit.com/r/neovim/comments/cdf36v/onivim2_chan...
Interesting. For once I am interested in compiling something to wasm. Thanks for the libvim link! :)
“We skipped that and haven't implemented any vim backend at all ... so its the vim code base with terminal UI stuff stripped out, and an interface added for us to hook into it.”
You took out the most important part!
I don’t know about other people, but I became a vim user because I found myself configuring servers and needed to know a better text editor than nano.
Vim is also my primary code editor these days but portability is still a killer feature.
You took out the most important part!
I don’t know about other people, but I became a vim user because I found myself configuring servers and needed to know a better text editor than nano.
Vim is also my primary code editor these days but portability is still a killer feature.
You are mis-interpreting what they did. They literally took vim, and built a ui around it. No re-implementation. It's Vim with a more modern frontend stack. You can go look at the libvim source and see it for yourself.
The point of this is to bring Vim into more modern workflows, not but "vim compat" but literally... vim.
Source: had some pull requests into libvim a while back to remove a lot of the various legacy compat features that don't make sense for libvim.
The point of this is to bring Vim into more modern workflows, not but "vim compat" but literally... vim.
Source: had some pull requests into libvim a while back to remove a lot of the various legacy compat features that don't make sense for libvim.
I feel like this is something said by people who are more invested in VS Code than vim. The main vim plugin for VS Code is straight trash. It's slow, buggy, and unintuitive; while lacking the extensibility that vim has.
I like vim and use plugins in all my IDEs because I like the idea of a modal editor and the basic vim is super powerful.
But it’s way easier to get IntelliJ or VSCode setup than your custom vim.
It would be great if there was a reference core engine of sorts that everyone could use in whatever editor.
I like vim and use plugins in all my IDEs because I like the idea of a modal editor and the basic vim is super powerful.
But it’s way easier to get IntelliJ or VSCode setup than your custom vim.
It would be great if there was a reference core engine of sorts that everyone could use in whatever editor.
VScode's vim plugin is actually what got me using vscode in the first place. I pretty much never left the terminal until vscodevim.
Oni2 is available for use for free for non-commercial usage, it just needs building from source at the moment. The steps are in the user manual if anyone is interested: https://onivim.github.io/docs/for-developers/building
Partially that is a thank you to those who have supported our development, and partially its to help put up a small barrier to entry, just so we don't get too flooded with issues and feature requests!
A public release is coming soon-ish, and can be used for non-commercial use.
Partially that is a thank you to those who have supported our development, and partially its to help put up a small barrier to entry, just so we don't get too flooded with issues and feature requests!
A public release is coming soon-ish, and can be used for non-commercial use.
I found that it was incredibly painstaking to build though, it's quite a barrier. I wanted to try it out a bit before buying, but it seemed to consume a considerable amount of disk space (>20GB), along with downloading tons of NPM dependencies and giving out weird errors during building.
Is there a particular reason why do you need such an amount of dependencies for building an editor?
Is there a particular reason why do you need such an amount of dependencies for building an editor?
I use the vim mode for VS: Code as my daily driver, and unlike the one sibling comment, don't think it sucks. I still purchased an Onivim 2 license. It's not far along enough for me to use daily yet, or at least, it wasn't last time I tried it out and I haven't had the time to look again, but I am excited for when it is.
That said, when I did this it was a one-time cost, and it looks like now it's a Patreon thing. Still though, $10 is pretty cheap, and if you hate it, you can always cancel. Or at least, that's how I think about these things these days. Not everyone has $10 to spare on stuff like this, but I am fortunate to.
That said, when I did this it was a one-time cost, and it looks like now it's a Patreon thing. Still though, $10 is pretty cheap, and if you hate it, you can always cancel. Or at least, that's how I think about these things these days. Not everyone has $10 to spare on stuff like this, but I am fortunate to.
According to their FAQ it looks like they'll be offering a trial version once they hit v1.
https://onivim.github.io/docs/other/faq#is-there-a-trial-ver...
https://onivim.github.io/docs/other/faq#is-there-a-trial-ver...
Hand holding is still a thing here I guess. https://onivim.github.io/docs/for-developers/building
It's pretty nice to see such beginner-friendly documentation tbh.
it seems to be open source there's a link in the page to the project's GitHub page.
https://github.com/onivim/oni2
https://github.com/onivim/oni2
Pedantically, I believe it's closer to "source available" than open source, since their license specifically adds a lot of restrictions on the end user
How does this compare to vscode-neovim?, which is a FULL neovim embedded instance. Wouldn't this be enough?
https://github.com/asvetliakov/vscode-neovim
https://github.com/asvetliakov/vscode-neovim
I'm interested. I don't think it's far enough along for me yet (.vimrc support), but I'll be keeping an eye on it.
I really like the "Outline" view, as I'm often editing large files and would find this extremely useful.
I really like the "Outline" view, as I'm often editing large files and would find this extremely useful.
Aside, I see it has tabs as defaults- what are people’s thoughts on tabbed editors?
Tabs are fine as long as they represent workspaces instead of a one-to-one mapping to files or buffers. I think the browser tab metaphor does not work very well in a text editor without some modification since you often want to do split layouts and I really don't like the messiness of multiple tab bars.
I think Emacs still has the most advanced system for window management and the only thing it should do is maybe modernise the UI surrounding it a bit.
I think Emacs still has the most advanced system for window management and the only thing it should do is maybe modernise the UI surrounding it a bit.
My thought on them is that people have no thoughts on it. Use automated formatting tools to completely remove the argument or discussion about tabs/spaces.
I think he meant tabs as in browser tabs.
can someone explain to me what the minimap is? other than a very big scrollbar? Every damn editor since sublime has this useless "feature", annoying.
I don't think it should ever be on by default but I do find it useful situationally, when scrolling through very large files (which ideally you want to avoid in your codebase in the first place) and when I don't necessarily have a specific search term or keyword in mind.
> I don't think it should ever be on by default
Yet every single one of them has it on by default (not even autohide by default). As if they're afraid the user finds out how useless it is.
Yet every single one of them has it on by default (not even autohide by default). As if they're afraid the user finds out how useless it is.
You're overthinking this. It's on by default because many users now expect it and it's surprising (at least to me as an Emacs user) how little people tend to dive into configuring their editors.
I guess it also looks kind of neat.
I guess it also looks kind of neat.
i want onivim to success. i tried it several times but it's not quite there yet, still getting in the way several times during the day.
I've been trying to figure out what are they using (in terms of npm packages / projects) to re-create that vscode ui. Any ideas?
the source code is available here https://github.com/onivim/oni2
Saw it but didn't find anything. I guess it's a complete re-implementation of the UI. The comments seem to suggest that as well.
Yeah the UI is completely custom built using Revery (a custom-built Electron alternative). Similarities to VSCode are just a result of it being the main inspiration. I would say Sublime also has a large influence on our design, i.e. in the minimap
Isn’t this VS Code with the Vim extension?
No, it is actually using the real vim in the background. So while you might not be able to use all vim plugins/scripts, it should give you a much more complete vim experience. See also https://github.com/onivim/libvim
Is it better than (the AFAIK newer) https://github.com/asvetliakov/vscode-neovim ?
Seems like it's Vim with a VS Code extension/adapter instead.
Intriguing idea, though not sure how viable.
Intriguing idea, though not sure how viable.
Took far too long for me to figure out that this isn't just a VS Code extension. I'm not even entirely sure this isn't.
No, likely out of diffidence onivim has a very similar design to VSC. It doesn't appear to share any code with VS Code though.
This isn't technically true, the extension host we use is directly the one from VSCode, such that we can support their extensions (well...a subset as we fill in the gaps in for the Oni2 <-> ExtHost communication).
But the actual core editor is all seperate, written in ReasonML (or OCaml if you know that instead), with a bunch of C libs in the background we've wrapped (Skia/Harfbuzz/We wrap real vim etc).
So the core editing experience has no code sharing, but the extension side of things does!
But the actual core editor is all seperate, written in ReasonML (or OCaml if you know that instead), with a bunch of C libs in the background we've wrapped (Skia/Harfbuzz/We wrap real vim etc).
So the core editing experience has no code sharing, but the extension side of things does!
Does it really have INSTANT startup time (i.e. Sublime Text)?
If it has, I'm interested.
Was not able to find the trial though.
If it has, I'm interested.
Was not able to find the trial though.
$ time /opt/oni/Onivim2.AppDir/usr/bin/Oni2 --nofork --silent -c qa
real 0m0,360s
user 0m0,280s
sys 0m0,042sYes, the startup time is amazing. You can build from source if you want to try it out without paying. I bought a license and I've been using it on and off for personal projects but it is still in development so don't expect everything to be perfect. Still really good though, actually feels like (is) Vim with a modern UI.
Though it's incredibly painstaking to do a source build; at least in my Arch setup it needed about 20GB of disk space and a lot of time and patience (it needs the Ocaml compiler and also downloads a ton of NPM dependencies!!!), and the PKGBUILD script failed due to a reason I've yet to figure out.
I was thinking about trying out Onivim someday but this one thing was the whole dealbreaker. I thought that if your program is advertised to be light and fast it would also be easy to build, but welp that's unfortunately not the case.
I was thinking about trying out Onivim someday but this one thing was the whole dealbreaker. I thought that if your program is advertised to be light and fast it would also be easy to build, but welp that's unfortunately not the case.
> I was thinking about trying out Onivim someday but this one thing was the whole dealbreaker. I thought that if your program is advertised to be light and fast it would also be easy to build, but welp that's unfortunately not the case.
This is not really a reasonable expectation to have for non-free software. The software is made for those willing to pay the licensing fee to download a prebuilt binary, not those that will end up wanting to compile it themselves. Fast performance != fast build times.
I personally appreciate the fact that the source is even provided - though obviously with a non free license.
This is not really a reasonable expectation to have for non-free software. The software is made for those willing to pay the licensing fee to download a prebuilt binary, not those that will end up wanting to compile it themselves. Fast performance != fast build times.
I personally appreciate the fact that the source is even provided - though obviously with a non free license.
I am actually willing to pay it if I can try a demo of it beforehand and confirm that it’s good (like I have paid for Sublime Merge). The problem is that I can’t try it without paying first.
(And I’m also disappointed at the fact that a software that strives for fastness and lightness is so much of a monstrous hassle to build. This has nothing to do with free/non-free software.)
(And I’m also disappointed at the fact that a software that strives for fastness and lightness is so much of a monstrous hassle to build. This has nothing to do with free/non-free software.)
There's a middle ground: they have a cloud based build descriptors (currently reporting as failing, but exists), so one could make use of GitHub's disk and cpu if dedicating that much of a local computer is annoying
I wrote a reddit post[0] about why Oni takes so much space to build, but the TLDR is that we build a bunch of native libraries from scratch on a fresh build, namely Skia.
I would like to note that we don’t maintain/support/promote the Oni package on AUR. Builds from scratch are mostly for “trial” or contribution purposes. We do try to help with build issues in the Discord, though!
I would also disagree with the idea that a light and fast program must be easy/quick to build. C++ is notorious for having huge resource/time requirements to compile, but the end result (assuming good code) can be faster than some C code! Consequently, it takes relatively little time to spin up a node interpreter but the resulting program is orders of magnitude slower.
Oni is written in OCaml, so naturally it requires the OCaml compiler to build. Those NPM packages aren’t JS — we just leverage the existing NPM ecosystem for our native code.
We do recognize that building from scratch is not ideal, which is why we provide prebuilt binaries for purchase. I can’t give an exact timeline, but we’ve discussed publishing public trial builds probably before the end of the year, which further reduces the need to build from scratch.
Feel free to ask any other questions in the Discord!
[0] https://reddit.com/r/onivim/comments/n05pqz/_/gw8hw8p/?conte...
I would like to note that we don’t maintain/support/promote the Oni package on AUR. Builds from scratch are mostly for “trial” or contribution purposes. We do try to help with build issues in the Discord, though!
I would also disagree with the idea that a light and fast program must be easy/quick to build. C++ is notorious for having huge resource/time requirements to compile, but the end result (assuming good code) can be faster than some C code! Consequently, it takes relatively little time to spin up a node interpreter but the resulting program is orders of magnitude slower.
Oni is written in OCaml, so naturally it requires the OCaml compiler to build. Those NPM packages aren’t JS — we just leverage the existing NPM ecosystem for our native code.
We do recognize that building from scratch is not ideal, which is why we provide prebuilt binaries for purchase. I can’t give an exact timeline, but we’ve discussed publishing public trial builds probably before the end of the year, which further reduces the need to build from scratch.
Feel free to ask any other questions in the Discord!
[0] https://reddit.com/r/onivim/comments/n05pqz/_/gw8hw8p/?conte...
[deleted]
I won't touch anything that is almost open source with a ten-foot pole. The two main sticking points for me are A) contributors working for free but not retaining equal rights to the product and B) the tendency of leaders of projects that are not-quite-open source to undermine the Open Source Definition and the Open Source Initiative.
IMO the model they have is the best kind of not-quite-Open-Source, at least. It looks to be every commit to master is MIT licensed after 18 months. Better than "only this bit is Open Source, the rest isn't and never will be".
I couldn't work out if the time delay was encoded in the license and the commits are already public even before they're MIT licensed or if it just depends on manual action.
I couldn't work out if the time delay was encoded in the license and the commits are already public even before they're MIT licensed or if it just depends on manual action.
Hey, Onivim contributor here!
I think Oni is in a hard place where it’s the primary source of income for Outrun Labs. Oni is open source in two senses
- the source is available online (technically doesn’t meet some definitions of open source, but the source is open)
- we MIT commits after 18 months.
In terms of contributors retaining rights to the product, we do have a bug bounty program where if you fix a bug with a PR, you get a license for free. Not quite what you mean I’m sure, but it’s essentially payment for contributions.
We definitely aren’t deliberately trying to undermine the OSD. The reality of open source software at the moment is that most of it is either created or sponsored by large companies who have a ton of money to throw at it. We are trying a new model of making money from open source software to allow us (well, Bryan) to work on Oni full time. We’re definitely open to suggestions, though!
I think Oni is in a hard place where it’s the primary source of income for Outrun Labs. Oni is open source in two senses
- the source is available online (technically doesn’t meet some definitions of open source, but the source is open)
- we MIT commits after 18 months.
In terms of contributors retaining rights to the product, we do have a bug bounty program where if you fix a bug with a PR, you get a license for free. Not quite what you mean I’m sure, but it’s essentially payment for contributions.
We definitely aren’t deliberately trying to undermine the OSD. The reality of open source software at the moment is that most of it is either created or sponsored by large companies who have a ton of money to throw at it. We are trying a new model of making money from open source software to allow us (well, Bryan) to work on Oni full time. We’re definitely open to suggestions, though!
Just so I understand this correctly, the version of Onivim 2 from 18 months ago will be open source? That's not the worst solution if true. John Carmack would do something similar with many of his game engines back when he was working with Id Tech (albeit with a much longer lag time).
Yep! You can find the MIT repo here: https://github.com/onivim/oni2-mit
I actually never thought of it in the context of Id Software, that’s an interesting comparison!
I actually never thought of it in the context of Id Software, that’s an interesting comparison!
Does it have mouse support out of the box?
[deleted]
This on iOS would be a killer application.
What does this offer that evil-mode emacs, or even vscode, has to offer...?
If every text editor has to implement full emacs functionality, every alternate text editor project should just stop now.
Having something to offer != implementing every single feature of emacs. Sometimes NOT having all the stuff emacs has can be a good decision.
evil-mode emacs isn't as snappy, vscode is harder to wrangle for a really pure-like vim setup. Someone else in this thread mentioned nvim, and while I like nvim a lot, i like the vscode extension ecosystem also prefer a gui vim editor (ive tried many).
long story short, i really like the product roadmap for onivim2, even though it isn't quite feature-full/polished enough to make as my daily driver. i've been a monthly Patreon supporter since last fall, though, and am guessing it'll be my main editor sometime this year!
long story short, i really like the product roadmap for onivim2, even though it isn't quite feature-full/polished enough to make as my daily driver. i've been a monthly Patreon supporter since last fall, though, and am guessing it'll be my main editor sometime this year!
This perhaps used to be true if evil-mode was around in the 90s. I've used to use vim and eventually made the switch to emacs about 10 years ago, initially using viper and then becoming an early adopter of evil-mode - and it never felt less snappy than native vim, except for rare occasions when executing complex macros to do things that can't be achieved using regular expression. And the new native compilation makes any perceivable performance difference even more unlikely.
I asked what it has to offer which is different than asking "does it do exactly what emacs can do". I am never going to find a more powerful editor than emacs, at least not for a while, but that doesn't mean other editors don't have anything to offer. I still prefer intellij idea when doing Java. VS Code is a lot quicker at certain things than emacs and certain IDE features don't stop working after running it for a while (happens with my emacs setup), among other things. I also use vim for editing things when I'm already in the terminal because of its advantages in that realm.
Snappyness is definitely something emacs lacks. Usually it doesn't bother me, but sometimes I know what I want to do and it gets in the way. I'm definitely. Interested in onivim2, I'll probably compile at some point and check it out.
For me, my Emacs runs fine up till I try using lsp for java development and then it's a bloody nightmare. Currently, I'm being forced to resort to the indignity that is Eclipse as a result of that.
I'm frankly ready for a total reimagining of Emacs even if it means that extension support might be compromised for a while. The last time there was a major divide, we had XEmacs and a lot of the massive improvements that made eventually made it to mainline Emacs so it could only be a good thing for this project long term.
I'm frankly ready for a total reimagining of Emacs even if it means that extension support might be compromised for a while. The last time there was a major divide, we had XEmacs and a lot of the massive improvements that made eventually made it to mainline Emacs so it could only be a good thing for this project long term.
I've had good luck with meghanada mode for Java development but I still stick with idea most of the time (mainly because I haven't set up binds to build or do things automatically yet). Still, I have issues with emacs as an IDE sometimes. For example when doing python, I forget the backend I'm using right now, after having it running for a while a ton of processes start to get spun up and it stops being able to properly do code completions. I'm sure I could solve these problems, I just haven't yet since I usually restart emacs often anyways.
Put this color scheme in vim or neovim and get a couple plugins and you basically have 90% of this, but better
«retro-futuristic modal editor» not helpful for marketing, what is the meaning here? maybe some correlation with «outrun labs» name and outrun look, but not clear. it also has advertisement for «native code» but this not always means fast. text editor problem is more latency than «speed», any latency benchmark made yet?
I might have cared 2 years ago, but I'm not about to drop forty hard-earned American dollars to try a text editor that I might end up hating. Hell, I probably wouldn't even buy Sublime if it was $40.
Honestly, melting two open source editors together (or rather cloning one while integrating the other) and ask for that amount of money for it is in my opinion unacceptable. The only thing that would make this a bit more acceptable is when the developers are promising to spend a lot of their earnings for vim development (and maybe VSCode, too).
*edit:* Just saw that it is actually open source and will be available for non-commercial use for free. I'm more than fine with that model!
*edit:* Just saw that it is actually open source and will be available for non-commercial use for free. I'm more than fine with that model!
Onivim doesn’t use vscode. It’s a from scratch implementation that doesn’t use electron, but they do replicate the vscode plugin system so they can be compatible with it.
> Just saw that it is actually open source and will be available for non-commercial use for free. I'm more than fine with that model!
Yeah, we are using the dual-licensing model that some other projects use.
Source available may be a more accurate description, since it can be somewhat controversial to claim to be open source and use our licensing model.
Tl;dr:
- Commits from the core team are licensed under an EULA for 18 months. You can use Oni2 for free for non-commercial stuff, but need a license for commercial use.
- After 18 months, commits are re-licensed to MIT license, and appear in the Oni2-MIT repo, where they are then subject to the normal rules of that license.
We do also periodically give to the upstream projects that power us, i.e. you'll see our name in the Vim leaderboard thingy since we give money to the charity that Vim asks for donations to.
And to be clear, whilst we use the vim source code as the editing experience base, the UI is our own, thought obviously looks very similar to VSCode, though no UI code is shared etc (Oni2 is written in Reason, VSCode in Typescript).
Yeah, we are using the dual-licensing model that some other projects use.
Source available may be a more accurate description, since it can be somewhat controversial to claim to be open source and use our licensing model.
Tl;dr:
- Commits from the core team are licensed under an EULA for 18 months. You can use Oni2 for free for non-commercial stuff, but need a license for commercial use.
- After 18 months, commits are re-licensed to MIT license, and appear in the Oni2-MIT repo, where they are then subject to the normal rules of that license.
We do also periodically give to the upstream projects that power us, i.e. you'll see our name in the Vim leaderboard thingy since we give money to the charity that Vim asks for donations to.
And to be clear, whilst we use the vim source code as the editing experience base, the UI is our own, thought obviously looks very similar to VSCode, though no UI code is shared etc (Oni2 is written in Reason, VSCode in Typescript).
I also wanted to vote against the pricing model, because I think it should be a one time purchase. The creator and his company behind the editor tries to create a serious FOMO on likely customers. I considered it to be a red flag on a potential abandonment. Additionally, I felt it would be easier for Visual Studio code become faster than Onivim 2 can have support for all Visual Studio code extensions.
On the plus side, Onivim 2 has some smart defaults which made it a joy to use. I encourage anyone who thinks about buying Onivim 2 to first learn how to fine tune VS Code to look and feel like Onivim 2 because you can.