Oni: Modern Modal Editing – Powered by Neovim
github.com
github.com
It's a fairly new project, but it's under _very_ active development. There's an excellent community building around it and I think we will be seeing some really great progress over the next year. That said, it isn't anywhere close to feature parity with vscode, but the value proposition is: neovim, with vscode compatible snippets and typescript-language-server-driven autocomplete (also works with vanilla JS) out of the box. AFAIK it works with any language language server with a few lines of configuration. I have tried several times to get You Complete Me working to my satisfaction and never quite got there despite spending several weekends working on it. Oni just works.
The bonus value proposition is: since it is a GUI wrapper around neovim, you get to retain all of the muscle memory you have built up in your years of using vim, but potentially also get all of the goodies that a graphical IDE like vscode provides. I have tried the vscode vim extensions, and they are really impressive, but they are still limited by the vscode extension api and at the end of the day it's not a real vim. For me, it was just not-vimish enough to constantly interrupt my flow; I believe the original inspiration for Oni was the creator's frustrations with vscode vim extensions.
I have been digging into the development process and I've been _really_ impressed with how brilliant and industrious the main contributors are; features are getting added at a breakneck pace. A few things that are in the works: real-time browser pane with auto-refresh (I just tried out the browser feature and it works like it's just another vim buffer... pretty awesome stuff!), markdown preview, and a gamified tutor mode for newbies.
For some of the stuff I do right now it's not as convenient or stylish as tmux + vim (don't laugh about the stylish part - for example I like a minimalist look and I tend to remove all toolbar and VS Code can't do that; well, it can, in Zen mode, but that's also full screen only, sets some other options I don't want, etc.).
For the convenience part, I'd want proper window splits, both horizontal and vertical at the same time and I'd want the panels and windows to become sort of interchangeable. I.e. you'd have 1 universal kind of pane which could host a terminal or a editing window or a problem panel or whatever.
If this is stable enough it might be just what I was looking for :)
Is this based on the VS Code code base? They'd be getting a ton of high quality UI code for free, IMO.
Perhaps a dumb question, but wouldn’t it be a better idea to make a proper vscode/neovim plugin?
Code is a great editor/IDE and has a huge amount of development backing and now a pretty large market share as well, which means inertia. But the vim bindings for it are just garbage. They are slow, make the editor feel sluggish, they don't work "quite right", etc.
No kidding this sparked some inspiration, but now I'm just going to have to either look at Oni and be jealous forever until VSCode catches up (if it ever does), or switch to Oni and end up missing out on all the features and inertia of VSCode :/
Hopefully the work that goes into this newer editor will spark some inspiration and get some of the work offloaded to libraries which VSCode can use as well.
They are planning to use neovim as a backend for it too.
I like the idea of Oni, but I also love that Sublime is native (I'm already running FF Quantum, I can't burn too much more battery!). I know Sublime's Vim keybindings aren't that complete.
Sublime's vintage mode is, in my experience, light years better, if not in completeness, at least in stability.
The escape key issue you mentioned was the only problem I've also had, but it's due to conflicting keybinds between the vim plugin and the vscode bindings for dismissing notifications and context help. I rebound all of those to shift-esc (and I believe the plugin's bindings now do this by default) and the problem went away.
At least Microsoft knows how not to make it suck so much.
I have been keeping Oni and VSCode open while I work so I can use Oni for editing and VSCode for the nice diffs and replace in project functionality.
Also neovim rewrite: https://github.com/Chillee/VSCodeNeovim
How's that compare to emacs? It sounds like it can be extended with Vimscript or JavaScript? Emacs has several snippet/templating options, and of course it also has several autocomplete options.
> The bonus value proposition is: since it is a GUI wrapper around neovim, you get to retain all of the muscle memory you have built up in your years of using vim, but potentially also get all of the goodies that a graphical IDE like vscode provides.
Emacs has had a X GUI for about 25 years (and of course vim has had various GUIs, too — although I think less powerful & extensible).
I really don't understand what the value proposition is here. Rather than using Electron and JavaScript and Vimscript and an ancient C core, why not use X/Cocoa/WinAPI, elisp & a relatively thin C VM? I always thought that the value proposition of the vi family was small, lightweight, fast-booting, found-everywhere, clean — not arcane, baroque, complex, hyper-extensible, flexible & hairy (that's emacs's value proposition!).
From my point of view, all of these huge environments built atop vi are simply reinventing emacs, poorly — and worse, they're destroying the wonderful things I always loved & respected about vi!
Just as an example, if you want to build a 'gamified tutor mode,' maybe the original AI language might be a good choice?
Certainly, folks should be free to follow their bliss. I don't really begrudge the Oni guys their project (although I'd obviously love it if they spent that energy & brilliance a little further up the stack, e.g. by making a great text/GUI browser mode for emacs) — I just don't get it.
> Emacs has several snippet/templating options, and of course it also has several autocomplete options.
So does vanilla vim, and you can script vim or emacs to do _anything_, but not everybody wants to put that kind of effort into extending their text editor.
> Emacs has had a X GUI for about 25 years (and of course vim has had various GUIs, too — although I think less powerful & extensible).
That's true, and those are great bits of kit, but there's always room for something new, right? :)
> Rather than using Electron and JavaScript and Vimscript and an ancient C core...
Oni is built on top of neovim, which is a modern C core and very nice from what I've heard. :) Also, I don't think Oni would be as far along as it is today if the creator had used native languages and frameworks; at least it wouldn't be available on my mac because IIRC he is primarily a windows user. :D
> How's that compare to emacs? It sounds like it can be extended with Vimscript or JavaScript? Emacs has several snippet/templating options, and of course it also has several autocomplete options.
Every editor is an exercise in trade-offs. Emacs, Vim, VSCode, Sublime, Atom - what defines them is their trade-offs and execution. The strength that modern editors have is that you get a lot working out of-the-box - when I boot up Emacs on Windows (or gVim for that matter), I get a (subjectively) ugly UI with no language support. That's not to say I can't configure it to look and function beautifully - but the trend with the modern editors like Atom & VSCode is to have an 'it just works' mentality. If you have a finely-honed Emacs config, sure, there might not be appreciable benefits for you. But a new user may not want to distill the several snippet/templating options.
I'd compare it to a car - a passionate driver might buy a kit car and finely hone the transmission, handling, etc. They probably won't be happy with the automatic transmission they find in a car at the Nissan dealership... But the automatic transmission ends up being convenient enough for a lot of people.
> I really don't understand what the value proposition is here. Rather than using Electron and JavaScript and Vimscript and an ancient C core, why not use X/Cocoa/WinAPI, elisp & a relatively thin C VM?
The reason I open-sourced the project was because I wanted help developing it. That's part of the joy of open source. And when you look at technology trends, like the [StackOverflow Developer Survey](https://insights.stackoverflow.com/survey/2018#technology), if I want others to help me, it makes sense to use the most popular technology today.
> From my point of view, all of these huge environments built atop vi are simply reinventing emacs, poorly — and worse, they're destroying the wonderful things I always loved & respected about vi!
Yes, I think we have two different perspectives here, and that's okay. What I love about vi & vim is the modal editing aspect - I think the composable, modal language is a beautiful and efficient way to manipulate text. That's the piece that's important to me.
> Certainly, folks should be free to follow their bliss. I don't really begrudge the Oni guys their project (although I'd obviously love it if they spent that energy & brilliance a little further up the stack, e.g. by making a great text/GUI browser mode for emacs) — I just don't get it.
Cheers :) FYI, our 'editor' implementation is extensible, so it doesn't preclude having another sort of driver - it'd be technically feasible to plug something else in there, too (in fact, we have some pure javascript 'editors' that we use as test cases). Not inconceivable that someone could drop-in an editor that talks to Emacs, Xi, etc.
But at the end of the day, I recognize that the trade-offs we make for Oni are only going to appeal to a niche of users. Having new editors exploring different possibilities can help the whole ecosystem, even if it doesn't directly target your niche - as other editors get inspired by the 'good parts' - and at the end of the day we all end up with better tools.
Some new stuff in the unreleased/development version (hidden behind feature-flags):
* Keyboard-driven navigation of embedded web browser: https://twitter.com/oni_vim/status/977280220234268673
* Live reload with embedded browser: https://twitter.com/oni_vim/status/976502172891299840
However personally I just love the scrollbar: it shows viewport-relative position _inside_ the file-relative scrollbar. (maybe this idea was borrowed from some other IDE, but I haven't seen it before.)
P.S.: Yes, it's electron, but if you're not using terminal Vim/Nvim then you already have given up "minimalism" in favor of ... whatever advantage you ascribe to gVim.
The only thing that makes me hesitate is because I run FreeBSD on some of my computers and FreeBSD support wasn't quite there yet for Electron apps last I checked. It may have changed in the meantime.
If I were to begin using an Electron app, I need to be sure that I will be able to use it on my FreeBSD computers also. This is especially important for editors and IDEs given that writing software is rather central among the things that I do. Currently I use Neovim for a lot of things and I use PyCharm for bigger Python projects.
I am wondering though, would it be feasible for one person (me) to rewrite Oni so that one can use it from within their web browser instead of with Electron?
Interesting project that did something similiar for Vim: https://github.com/coolwanglu/vim.js/
I like the idea of the same group of people maintaining the kernel and the userland utilities.
Also I am strongly in favor of the family of BSD/MIT/ISC licenses over GPL.
I love ZFS. I think dtrace is neat. I think jails are nice. I like pf. Nowadays there are equivalents for pretty much all of that on Linux. In fact you don’t even have to go with btrfs to get something like ZFS on Linux — the ZFS on Linux project makes ZFS available on Linux too. But on FreeBSD all of these things are there in the base install without having to do anything special and they will continue to be there for a very long time.
All in all, I just like FreeBSD a lot, and I feel at home with it in a way that few other systems make me feel.
I have not looked into the way neovim communication works but from their site it seems to be using named pipes which are again, not available from a browser.
I seriously doubt it would be impossible to use Electron as it really is, a Web App.
The answer to "would it be feasible/easy to port an Electron app to a pure browser app" is no. Unless all of the communication between the frontend part and the native tooling is done via sockets.
I agree that native apps should be sandboxed, however sandboxing something like an IDE will be quite difficult. Even Apple does not sandbox Xcode.
Admittedly I have not developed any Electron apps, but I have developed serious web apps and worked a little bit with NodeJS also.
Why don’t people do exactly that when they write their code — make all communication happen over regular HTTP and websockets?
For comparison, the same data transfer using Electron native plugin took well under 1ms.
I don't mind electron myself, but that ps sounds fairly disingenuous to me.
For instance, native undo is time and word sensitive. I don't know its exact heuristics, but it always seems to do what you meant.
Gmail's Chrome and Electron, on the other hand, will often undo letter by letter or leave you in mid typed words, which is nuts.
If you want another example, I often write in multiple languages, something that's beautifully handled for you on native apps. Since Skype changed to Electron, it puts a red underline on every single non english word I type and there is nothing that can be done about it, besides changing the default system language and restarting the app.
There's also CoreText's sharp line width in retina displays no matter which background/foreground color combination you choose, built in dictionary a tap away, etc.
It's just a dreadful experience otherwise, once you get used.
Neovim has been a joy to build on - fast, performant, and stable. Great example of a high-quality OSS project!
People here claim this is a lot better for performance. I've no personal experience to verify this.
I'll give it a try, although not with great hopes performance-wise but oni may be a good compromise between nvim and good lsp designed for vscode (like haxe lsp which struggles on nvim).
If you are one of those types that often switch between editors, like me, then you might want to retain some of the muscle memory you've built up in stuff like Atom/VSCode/Whatever.
I started creating a layer[0] for SpaceNeovim to replicate some of the common keybindings, such as Cmd+s for save, Cmd+w for closing tabs, Cmd+[1-9] for switching tabs etc. If anyone is interested in getting this, without going full in with SpaceNeovim, they can extract it from [1], which currently handles both VimR and Oni (different key for CMD), but you could simplify it to not use exe if you wanted to.
It requires that you load your init.vim, so "oni.loadInitVim": true needs to be set in the Oni config.
Another thing, you can quickly add support for an LSP in the Oni config with just,
"language.haskell.languageServer.command": "stack",
"language.haskell.languageServer.arguments": ["exec", "--", "hie", "--lsp"],
"language.haskell.languageServer.rootFiles": [".git"],
"language.haskell.languageServer.configuration": {},
[0] https://github.com/Tehnix/spaceneovim-layers/tree/master/lay...
[1] https://github.com/Tehnix/spaceneovim-layers/blob/master/lay...
Nvim desparetely needs a good GUI. Ever GUI I've tried (I think I've tried all of them) lags when calling snippets.
But there's one thing I can't really understand and, for me at least, is not an advantage working with code: why using tabs?
It feels like an anti-pattern when I'm using (g)vim, I use buffers and I split in few windows, list buffers, change buffer, etc; and I never leave the keyboard. I guess it is "modern" to use the mouse, including the file explorer (I use :find mostly, then ctags navigation), but it is something that doesn't work for me at all.
Personally, I like being able to see the filename in the tab and just hit gt or Gt a few times than to bring up the buffers list (with or without Ctrl-P) and type the filename.
That being said, I love spacemacs and it doesn't have tabs (or I haven't researched that enough) where I make do with fuzzy searching through buffers.
I use tabs in vim because opening more than 2 buffers on my laptop gets really crowded.
How do plugins work? Do neovim plugins work out of the box with Oni, do you have to write a wrapper, or are they completely incompatible? This is really the make or break part of it.
Yes it should be able to do that. Neovim runs separately from frontends like the one in the OP.
https://github.com/neovim/neovim/wiki/Plugin-UI-architecture
Edit: it's worth pointing out that while the rendering is done with electron/canvas, everything else is delegated to neovim. I haven't noticed any slowdown with 1000+ line files, but if you're talking tens of thousands... maybe.
Most neovim plugins work great with Oni :) Just set the `oni.loadInitVim` configuration value to `true`: https://github.com/onivim/oni/wiki/Configuration#oni
Why do I need NPM to install vue.js as a language for Oni? Can anyone explain why I would want to bother with this editor if it requires Node.js?
Edit: I've tried all the other Electron based editors, and I don't recall a single one requiring Node.js/NPM to install anything.
What immediately struck me as "this project is not ready to use to actually code in" was trying to scroll with my Macbook's touchpad and it working pretty awfully. It seems like an obvious enough issue that it _has_ to be being worked in, but maybe not and I should report it.
Unfortunately is not an easy task to accomplish at the moment, due to the way vim scrolling is tied with the terminal approach (line by line), does not seem as a hard block though and hopefully can be improved.
Since most of the time you are scrolling with keybindings when using vim this may not be as big of an issue for most vim users (I never had issues in my experience), but certainly desirable to fix as it's a dealbreaker some.
If you're looking for a beefed-up version of vim as an IDE spacevim has a package manager and a curated set of over 200 plugins dialed in to work well together for gvim or terminal.
I'm just trying to understand the differentiator
Being able to finally have good looking autocompletions, tabs, file explorer and widgets for all related vim features (autocomplete, quickinfo, statusbar, etc) and also having first-class LSP compatibility made using Oni for ~ 6 months a joy.
I don't really enjoy the commitment to appease IDE oriented users but it's pretty easy to have a bare configuration (https://github.com/onivim/oni/wiki/How-To:-Make-Oni-closer-t...) and if it makes it easier and viable for more people to enjoy vim, more power to it!
Also, @bryphe is a very considerate project leader, making hard work to understand different use cases and open to new ideas, which makes collaboration very straightforward with the growing number of contributors. I am very excited for Oni's future and am sure that it'll only improve forward.
in old version SpaceVim has many plugins, but we just release v0.7.0, and the default plugins is only 50.
you can checkout our release note:
1. I wonder though why you/team didn't opt for extending the vim emulation - via a plugin - on VS Code. Did the exposed API limit you from doing so? Edit: Having used the extensions of VSCode, I am wondering if that is the case.
2. Does it support installation of sublime/atom/vscode plugins?
Thanks for contributing to the VS Code ecosystem.
There were two challenges I faced:
1. Performance - I'm very sensitive to typing latency. I wanted to leverage Neovim to its full potential. IMO, there is a tremendous benefit to having the buffer management delegated to a native layer (similiar to what the Atom team is exploring with Xray). We also use a canvas renderer for the editor surface, unlike VSCode/Atom which use the DOM. We still have low-hanging fruit to address in terms of performance, but we gain significant benefits from this architecture, vs other electron apps.
2. Functionality- I wanted to explore some new input methods, inspired by browser plugins like Vimium and cVim. I also wanted to explore ways to gamify the editor experience and make it fun to learn modal editing and become more productive. I found VSCode's API's limiting in these aspects, and wasn't able to realize it within the confines of their API.
I believe VSCode is making the right set of trade-offs for their user base - there is benefit to the sandboxing of the APIs as it helps lift the overall quality of plugins. Every editor is a different exercise in trade-offs, and I wanted to explore a different set, targeting a more niche group.
The VSCode team has done awesome work and we've been able to leverage several core components - their language server client, their snippet parser, their textmate highlighting parser / engine. It's wonderful that they are contributing so much to the open source community. I hope to hook up their debug adapter protocol in the near term, too!
To answer your second question - we'd like to support VSCode plugins at some point. They have a great ecosystem of plugins. We support their snippet syntax and textmate highlighting syntax, but hopefully we can have more a complete compatibility story. Still have a lot of work to do on our plugin story in general :)
1. Syntax (missing for Elixir)
2. Shortcuts (even preferences shortcut is missing)
3. Easier configuration API; I think currently, you give us the "entire React app", rather get something simple.
I have the application downloaded; assuming you have autoupdates. I will keep an eye out; excited to see where this goes.
1. If you're coming from regular vim you should expect having to bundle syntax files for languages that aren't hugely popular.
2. Shortcuts on a vim frontend should be pretty self-evident for a regular vim user. And some reading on the documentation as well until the 1.0 release.
3. This is a good point, but you did not clarify your point well as I assume you meant discoverability and ease-of-use of configuration.
Still, I think it's valuable feedback and actually captures some issues that are being worked now:
1. People coming from IDEs expect everything to work out-of-box and perhaps in the future some plugins will be bundled by default (configurable to not be the case for veteran users).
2. Recently a lot of features out of regular vim were added such as markdown preview, browser tab, file explorer and sneak mode; which have particular keybindings. For the moment they should be visible when you run the 'Quick Open' menu (`<c-p>`) but seems like there should be another way to discover these. An issue will be opened for this case.
3. Discoverability of options and configuration UI is a current issue indeed and there are plans to improve it (https://github.com/onivim/oni/issues/976).
I hope the downvotes do not discourage you from giving further feedback as it's best when given sincerely, issues are very welcome, thanks!
https://news.ycombinator.com/item?id=16674641
I belive that there is no "Perfect" software, but there is a software that is Perfect for me (or anyone else)
I tried it on my macbook, and for some reason I can't keep 'j' pressed to scroll down - I have to press it once per row. This works fine in MacVim and Terminal.app vim. Does anyone know why this won't work?
> To enable key repeat when pressing & holding a key in Oni, write the following in your terminal:
defaults write com.extropy.oni ApplePressAndHoldEnabled -bool false
* neovim-gtk for Linux: supports using a file tree, tabs, a nice open dialogue menu for recent files, support for working with Plug for new plug-ins.
* VimR on Mac OS: has a file tree, buffer menu, and support for HTML/Markdown Preview.
People mention it is better than Atom due to how it leverages Electron which is nice but still, what is the value proposition of this IDE?
"Modern UX - The Vim experience should not be compromised by terminal limitations."
Could someone expand upon this goal?
Isn't the entirety of Vim built for - and around - terminal limitations?