I didn't try it. But I surfed the website and watched the animations.
I am using stock Neovim on the console. For completion I switched to nvim-cmp https://github.com/hrsh7th/nvim-cmp. Onivim also provides (based on the screencasts) completion. Do they leverage their own coded completion engine or are they using nvim-plugins and only render the UI over this completion?
My point is there will always be an impedance mismatch between functionality provided by plugins compared to what a UI provider thinks has to be coded in their respective implementation.
It's on the homepage - they aim to support the full VS Code extensions API and that is how they power language features like completion.
I've been keeping an eye on onivim for a long time and think it has a lot of potential. Last time I tried it it still had too many rough edges to try and use as a daily driver, though.
I have a onivim2 licence and thus try it from time to time. Speed etc is impressive. Currently I think it is about getting the last 20% done and development has been slowing down a bit. Really hope this get done. I still cannot really get a grasp on how viml and vscode extensions might interplay. It is btw interesting to note that onivim 1 was neovim but the author decided that it was better to wrap the vim source code.
Cool, but vim-for-money? When there's normal vim and neovim and vscode and evil-emacs? I think that text editors, even with fancy chrome are a pretty busy market with lots of good free-beer offerings.
That's cool too. Of course I can also build those other ones myself (except all the nonfree vscode plugins that make it good of course). And if I understand correctly, the Free Software repo is promised to be just 18 months behind the commercially licensed product. This is all great, and makes it better (in my opinion) than stuff like Sublime or whatever.
Competing with something that's even more free though? That's going to be a challenge, and something would definitely have put me off of starting a business to sell this product.
This looks cool - I hope that the model of "pay for binaries but free to compile yourself" works out even without making the build process too convoluted.
I'd rather stick to Neovim with support for LSP (language server protocol) and DAP (debug adapter protocol). See a demo here: https://youtu.be/CcgO_CV3iDo
However, I like tinkering with my dev environment quite a lot to make it exactly how I want it. I imagine the target market of Onivim is those users who don't want to tinker quite as much.
One good thing about about Neovim is that it forces vim to keep up. I don't really stay up to date, but I think Vim 8 was mostly updates to keep on par with Neovim.
It's a bit more friendly than that (according to TJ DeVries from the Neovim team). It's more like both teams bouncing ideas off of one another and inspiring each other. And that can result in one release or another just looking like implementing features from the other project.
Yup, Neovim has become very interesting again due to LSP. Still requires quite a bit of config though.
For anyone interested there's also vscode-neovim [1] if you like what VSCode comes with out of the box but want a full-on nvim instance interpreting your keystrokes.
I'm currently using a combination of terminal nvim and this vscode plugin depending on language.
Works reasonably well. Multi-cursor/renaming is not as good as VSCodeVim. On the plus side, you have the full set of vim commands available to you such as`:norm`.
I've never used multi-cursors, so I don't think I'll miss them. On the other hand, whenever I want to type Vim commands and the editor doesn't want to, it always jars me.
I personally like them for resolving merge conflicts by hand. It really helps just clicking on a section in blueish to instantly jump to a conflict in large-ish files.
I agree, it's a waste of screen estate and focus estate, I can't see the benefit of a minimap. I usually use imenu in Emacs so any definition is 0.1s away with a keypress
I don't tend to find horizontal screen estate to be all that useful, unless A). You have your editor massively zoomed in or B). your lines are (subjectively) too long
I dont find them massively useful, but its nice to have
Not sure I like VS Code enough to cop to pay for it rather than just continuing into invest into Jetbrains. Their vik plugins blow VSC out of the water.
Something weird is going on. They used to also sell licenses on the website, but it disappeared. Now they have a sold out $5 tier on Patreon, unless you visit the site's direct link? It's just odd.
> I'd like to re-license the source code to MIT. This will happen soon (ie, for 0.5.8). It'd be great to make it easier to contribute the project, and I know the current license is a potential blocker. I'll need development help more now than ever.
> I plan on turning off Patreon shortly - I can't justify keeping it active if I'm not able to work full-time. (I plan on doing something similar to when I transitioned from Onivim v1 -> Onivim v2 - convert all current patrons to a lifetime license).
So that's why you can't buy a license anymore ? I had been hesitating for a long time, the only thing I'd want from onivim is an easy to use debugger for php/node like the on vscode has. With easy to move into variables and inspect content with the mouse, stopping the debugger, etc.
Every time I tried that with vim or neovim I can't get over the buffer management and keyboard navigation thing and generally get a lot of errors. I usually manage to see the value of a variable and then it all crumbles down in error messages. Probably pebcak but still :/.
I think they are doing quite a good job, the editor is blazing fast and you can already use almost seamlessly many VScode plugins. It is clearly still a developer preview, with a number of rough edges, but the devs are very reactive on the issues and on the discord channel.
I bought it in the very early days to support the project. I still cannot use it as my main editor, but I have been using it more and more recently (I am using the nightly version).
I see, I don’t know but its license is pretty clear in saying that you cannot use it outside of Microsoft stuff: “You may install and use any number of copies of the software to use solely with Microsoft Visual Studio family of products.”
I think they're trying to be a bit too clever, with vim being the retro part and "futuristic" being used to signify contemporary/modern/IDE-ish.
Not really how retrofuturism actually works, as that would imply that a part of the editor would be how people in the past imagined the future to be. Which would be an interesting concept, but I'm not aware of any kind of editing interface like that. Too menial for pop culture. Retro-futuristic image manipulation would be in Blade Runner, but text editing?
It's ergonomic once you have memorized all the required keystrokes, but the discoverability of the UI for new users is... I can't even say bad, more like non-existent. Ok, maybe it's debatable if you can call that "ergonomics"...
This seems pointless. You can have a modern UI for neovim, they literally have a section on their github page showing you the alternatives. Pick Rust, not electron, and you won't have to do any funky config stuff.
> if your app looks or behaves differently on another platform, that's a bug! As a consequence, Revery is like flutter in that it does not use native widgets.
No native widgets is a hard pass. One of the biggest advantages of native code is using native widgets, that look, feel and function as all other widgets om that platform. Doing native code but rolling your own widgets is missing the point completely.
Apps should look and behave differently on different platforms, they should look and behave like native apps for that platform. Why would I care if an app looks the same on Windows, macOS and Linux when I'm not using all those OSes at the same time ? This feels like a benefit for the developer, not the end-user.
> Why would I care if an app looks the same on Windows, macOS and Linux when I'm not using all those OSes at the same time ?
Sometimes you do switch, and having everything be the same in your editor is nice. I normally work in linux on a desktop and have a windows machine due to corporate policy. Because of COVID, I started working from home on my laptop and VNC'ed into my linux machine to do work. It worked fine until my ISP decided to be shit, so out of frustration I just switched to developing on windows. Since I was using IntelliJ, I just exported my settings from Linux, imported to windows and everything just worked and looked the same.
In theory, I kind of agree with you. But in practice, having a consistent experience across all OS'es is nice. The ship has sailed anyway, nothing looks consistent across different applications on the same platform anyway. Might as well have applications be consistent across different platforms instead.
Considering how many people are annoyed by the trend of Electron everywhere, it's a bit sad to see an ambitious native editor like this unable to secure funding.
Vast majority of the general users of Electron apps don't know what Electron is. Neither whether the apps use it. It's better to have an official support through electron than to have none.
Genuine question: if it looks so much like VSCode and it behaves close to VSCode + VIm extension, and it supports VSCode extensions... what is the audience and/or use case?
Not a big fan of Microsoft.. but VSCode is good. It's actually really fast so even in terms of performance I'm not sure what is to be gained?
Vim has that one advantage is I can drop a 10 GB SQL file in it and it'll work somehow. But that's a really niche use case.
ps: I do wish there was the ONE... I'm still alt-tabbing between Sublime Text, VSCode AND MacVim :)
In the software development process, many constraints must be considered before software is released. The software requirements dictate the scope of the software development with https://mlsdev.com/services/custom-software-development. It is important for software engineers to determine the "what", "where", and "when" of the software development process. All constraints must be understood and communicated throughout the software development process, which includes the scope, number of user accounts, the type of software that will be developed, budget, time lines, and any final user interface specifications.
77 comments
[ 2.9 ms ] story [ 166 ms ] threadI am using stock Neovim on the console. For completion I switched to nvim-cmp https://github.com/hrsh7th/nvim-cmp. Onivim also provides (based on the screencasts) completion. Do they leverage their own coded completion engine or are they using nvim-plugins and only render the UI over this completion?
My point is there will always be an impedance mismatch between functionality provided by plugins compared to what a UI provider thinks has to be coded in their respective implementation.
I've been keeping an eye on onivim for a long time and think it has a lot of potential. Last time I tried it it still had too many rough edges to try and use as a daily driver, though.
> Onivim is capable of loading VSCode extensions
Given how free the alternatives are, I think I'm paying a lot for Sublime, but given how much I like and use it ... it's a small price to pay.
Competing with something that's even more free though? That's going to be a challenge, and something would definitely have put me off of starting a business to sell this product.
I agree with you anyway. I checked it out, it seems neat enough, but I'm happy to be going back to emacs :)
but, but... vim is a native app?
You also didn't quote the important part. It should reads like this
> the quick and responsive feel of a native app, and the vast extension ecosystem of VS Code.
Essentially, you are in the market for onivim if
- You like vim
- You hate the sluggishness of VSCode
- Your workflow depends on specific VSCode extensions (may be because all your teammates use VSCode?)
However it has a "time delay dual" licence so eventually everything becomes MIT.
However, I like tinkering with my dev environment quite a lot to make it exactly how I want it. I imagine the target market of Onivim is those users who don't want to tinker quite as much.
For anyone interested there's also vscode-neovim [1] if you like what VSCode comes with out of the box but want a full-on nvim instance interpreting your keystrokes.
I'm currently using a combination of terminal nvim and this vscode plugin depending on language.
[1]: https://github.com/asvetliakov/vscode-neovim
I will give this a shot, thanks!
I dont find them massively useful, but its nice to have
Anyone got the inside scoop?
e: Status update from project lead as of 2021-09-01: https://github.com/onivim/oni2/issues/3811#issuecomment-9103....
> I'd like to re-license the source code to MIT. This will happen soon (ie, for 0.5.8). It'd be great to make it easier to contribute the project, and I know the current license is a potential blocker. I'll need development help more now than ever. > I plan on turning off Patreon shortly - I can't justify keeping it active if I'm not able to work full-time. (I plan on doing something similar to when I transitioned from Onivim v1 -> Onivim v2 - convert all current patrons to a lifetime license).
So that's why you can't buy a license anymore ? I had been hesitating for a long time, the only thing I'd want from onivim is an easy to use debugger for php/node like the on vscode has. With easy to move into variables and inspect content with the mouse, stopping the debugger, etc.
Every time I tried that with vim or neovim I can't get over the buffer management and keyboard navigation thing and generally get a lot of errors. I usually manage to see the value of a variable and then it all crumbles down in error messages. Probably pebcak but still :/.
> €4.50 per month (sold out!)
> Thank you for your monthly support of Onivim 2!
> This tier gets:
> - Access to downloadable builds
> - Month-to-month commercial use license
This information was not on the donation page, so I went with 1 buck. Never used Patreon before and I now don't know how to change my donation.
This is a pretty bad onboarding. I'm willing to pay, at least for a month, just to try this, but it is ... hard.
edit: I found it, upped my donation to 5€, still can't download. Somethings broken here.
I think they are doing quite a good job, the editor is blazing fast and you can already use almost seamlessly many VScode plugins. It is clearly still a developer preview, with a number of rough edges, but the devs are very reactive on the issues and on the discord channel.
I bought it in the very early days to support the project. I still cannot use it as my main editor, but I have been using it more and more recently (I am using the nightly version).
I find funny that they label modal editing, or vim compatibility, or whatever they want to achieve as a retro thing.
Not really how retrofuturism actually works, as that would imply that a part of the editor would be how people in the past imagined the future to be. Which would be an interesting concept, but I'm not aware of any kind of editing interface like that. Too menial for pop culture. Retro-futuristic image manipulation would be in Blade Runner, but text editing?
Maybe the Tron 2 quasi-Emacs ;)
https://www.robscanlon.com/encom-boardroom/
https://github.com/GitSquared/edex-ui
It’s no longer funny.
Edit: comment retracted. I am an idiot. Left here because I’m not a revisionist.
Vim is highly ergnomic for the task it was made to do. Whether it was designed as such or it was a happy accident is orthogonal.
https://news.ycombinator.com/item?id=27655998
> if your app looks or behaves differently on another platform, that's a bug! As a consequence, Revery is like flutter in that it does not use native widgets.
No native widgets is a hard pass. One of the biggest advantages of native code is using native widgets, that look, feel and function as all other widgets om that platform. Doing native code but rolling your own widgets is missing the point completely.
Apps should look and behave differently on different platforms, they should look and behave like native apps for that platform. Why would I care if an app looks the same on Windows, macOS and Linux when I'm not using all those OSes at the same time ? This feels like a benefit for the developer, not the end-user.
Sometimes you do switch, and having everything be the same in your editor is nice. I normally work in linux on a desktop and have a windows machine due to corporate policy. Because of COVID, I started working from home on my laptop and VNC'ed into my linux machine to do work. It worked fine until my ISP decided to be shit, so out of frustration I just switched to developing on windows. Since I was using IntelliJ, I just exported my settings from Linux, imported to windows and everything just worked and looked the same.
In theory, I kind of agree with you. But in practice, having a consistent experience across all OS'es is nice. The ship has sailed anyway, nothing looks consistent across different applications on the same platform anyway. Might as well have applications be consistent across different platforms instead.
Considering how many people are annoyed by the trend of Electron everywhere, it's a bit sad to see an ambitious native editor like this unable to secure funding.
Not a big fan of Microsoft.. but VSCode is good. It's actually really fast so even in terms of performance I'm not sure what is to be gained?
Vim has that one advantage is I can drop a 10 GB SQL file in it and it'll work somehow. But that's a really niche use case.
ps: I do wish there was the ONE... I'm still alt-tabbing between Sublime Text, VSCode AND MacVim :)