I really wanted to like Onivim 2, but went back to Visual Studio code after supporting the creator on Patreon for a while. The last build and creator update was provided months ago for supporters.
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.
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 don't see the issue. Price of a company's stock goes up as the company continues to become more useful over time and no one thinks this is unreasonable. Why not same for a product?
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."
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.
> 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.
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'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.
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.
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.
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.
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.
>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.
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).
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.
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).
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.
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.
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.
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.
> 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.
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.
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.
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 ;)
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!
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.
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).
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.
“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 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.
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.
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.
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?
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.
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
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.
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 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.
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.
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
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
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!
Yes, 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.
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.)
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!
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 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).
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!
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'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.
«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!
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).
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.