Onivim 2 is a retro-futuristic modal editor
v2.onivim.io
v2.onivim.io
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 have a hard time believing that's the main motivation
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.
>It's basically an early bird discount.
When has that not been a marketing tactic
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."
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.
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 think it’s something they really should fix, because it screams “poor judgment”, which gives a bad first impression of their work.
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.
> 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...
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/
Anyway - one can always create a perfect scheme for them to use.
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.
Why would you need this (unless your language is not in https://github.com/nvim-treesitter/nvim-treesitter#supported... ?)
Yes, it's not using native widgets (so no built-in accessibility), but that might be fine in many cases.
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 currently, Tauri seems like a more viable option.
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.
[1]: https://github.com/VSCodium/vscodium/issues/196#issuecomment...
Yes, this is basically the entire point of Onivim (use vscode extensions with vim). https://open-vsx.org/
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.
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.
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
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 :)
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.
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
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!
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!
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.
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...
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.
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.
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...
0: https://github.com/onivim/libvim#why-is-libvim-based-on-vim-...
1: https://www.reddit.com/r/neovim/comments/cdf36v/onivim2_chan...
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.
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.
Is there a particular reason why do you need such an amount of dependencies for building an editor?
https://onivim.github.io/docs/other/faq#is-there-a-trial-ver...
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.
I really like the "Outline" view, as I'm often editing large files and would find this extremely useful.
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.
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.
I guess it also looks kind of neat.
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!
Intriguing idea, though not sure how viable.
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,042sI 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.
(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.)
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 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!
I actually never thought of it in the context of Id Software, that’s an interesting comparison!
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!
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.
*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!
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).