8 ms·

I've been using Oni for the last few weeks as my daily driver (I liked it so much I signed up as a monthly sponsor), and here's my take on it: It's a fairly ne

by pault 9y ago

I've been using Oni for the last few weeks as my daily driver (I liked it so much I signed up as a monthly sponsor), and here's my take on it: 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.

oblio 9y ago
Interesting. I'm a vim/gvim user myself, outside of IDEs, but I've been trying VS Code recently. 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.
- pault 9y ago
  It is not based on vscode as far as I know, but it does use the vscode language servers and snippets. Regarding splits, if you set "tabs.mode" to "tabs" it will behave just like regular vim tabs, so each "tab" is just a neovim instance that behaves exactly as you would expect it to. There is a feature in development that creates a GUI "tab" for each split[1], but I found it difficult to use so I'm sticking with native vim splits for now. [1]: https://twitter.com/oni_vim/status/969315834626695168 https://twitter.com/oni_vim/status/969315834626695168
- rstat1 9y ago
  Zen mode in VSCode is very configurable. You can disable the full screen mode, and also disable the dumb centering thing it does in the most recent release(s)
  - YuukiRey 9y ago
    Interesting that you consider it dumb. For me centering the editor content is crucial and I was extremely happy when they let us center the editor content outside of Zen mode. I was also a big fan of Goyo and Limelight in Vim.
xienze 9y ago
>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. Perhaps a dumb question, but wouldn’t it be a better idea to make a proper vscode/neovim plugin?
- pault 9y ago
  It's not really the same use case though, a vscode extension is limited by the vscode API, but I imagine if someone manages to make an extension that is just a wrapper around a neovim process it will be pretty compelling. Making a neovim plugin wouldn't get you the graphical IDE features like an embedded browser and/or graphical debugger.
  - PuercoPop 9y ago
    The current vim plugin from VSCode uses neovim under the hood, at least for some operations
scrollaway 9y ago
Urgh, this is so infuriating. Oni looks fantastic if it can deliver on what it does, but the infuriating part really is VSCode in all this. 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.
- deleted 9y ago
  [deleted]
- curioussavage 9y ago
  I don’t think I would be that harsh in the com plugin for vscode. It works fine for me. I’m not a vim power user though. They are planning to use neovim as a backend for it too.
  - thomasahle 9y ago
    That looks really exciting actually! https://github.com/VSCodeVim/Vim/issues/1735 https://github.com/VSCodeVim/Vim/issues/1735
- jakecopp 9y ago
  How does VSCode Vim bindings compare to Vintage mode in Sublime? 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.
  - ubercore 9y ago
    I've found VSCode Vim bindings _really_ buggy. Sometimes non-responsive to the escape key until I press it a few times, sometimes it will kill highlighting of code blocks until I switch modes, sometimes enters `<tab>` in the source code instead of tab when I press the tab button. I still use it, because I've used modal editors for so long and I like everything else about VSCode, but the vim bindings are my biggest point of frustration with it. Sublime's vintage mode is, in my experience, light years better, if not in completeness, at least in stability.
zeveb 9y ago
> the value proposition is: neovim, with vscode compatible snippets and typescript-language-server-driven autocomplete (also works with vanilla JS) out of the box 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.
- bryphe 9y ago
  Maintainer here. Thank you for the thoughtful and articulate feedback! I appreciate you sharing your perspective and I'll give you some of my thoughts. > 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 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.

by pault 9y ago

oblio 9y ago

Interesting. I'm a vim/gvim user myself, outside of IDEs, but I've been trying VS Code recently. 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.

pault 9y ago
It is not based on vscode as far as I know, but it does use the vscode language servers and snippets. Regarding splits, if you set "tabs.mode" to "tabs" it will behave just like regular vim tabs, so each "tab" is just a neovim instance that behaves exactly as you would expect it to. There is a feature in development that creates a GUI "tab" for each split[1], but I found it difficult to use so I'm sticking with native vim splits for now. [1]: https://twitter.com/oni_vim/status/969315834626695168 https://twitter.com/oni_vim/status/969315834626695168
rstat1 9y ago
Zen mode in VSCode is very configurable. You can disable the full screen mode, and also disable the dumb centering thing it does in the most recent release(s)
- YuukiRey 9y ago
  Interesting that you consider it dumb. For me centering the editor content is crucial and I was extremely happy when they let us center the editor content outside of Zen mode. I was also a big fan of Goyo and Limelight in Vim.

xienze 9y ago

>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. Perhaps a dumb question, but wouldn’t it be a better idea to make a proper vscode/neovim plugin?

pault 9y ago
It's not really the same use case though, a vscode extension is limited by the vscode API, but I imagine if someone manages to make an extension that is just a wrapper around a neovim process it will be pretty compelling. Making a neovim plugin wouldn't get you the graphical IDE features like an embedded browser and/or graphical debugger.
- PuercoPop 9y ago
  The current vim plugin from VSCode uses neovim under the hood, at least for some operations

scrollaway 9y ago

Urgh, this is so infuriating. Oni looks fantastic if it can deliver on what it does, but the infuriating part really is VSCode in all this. 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.

deleted 9y ago
[deleted]
curioussavage 9y ago
I don’t think I would be that harsh in the com plugin for vscode. It works fine for me. I’m not a vim power user though. They are planning to use neovim as a backend for it too.
- thomasahle 9y ago
  That looks really exciting actually! https://github.com/VSCodeVim/Vim/issues/1735 https://github.com/VSCodeVim/Vim/issues/1735
jakecopp 9y ago
How does VSCode Vim bindings compare to Vintage mode in Sublime? 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.
- ubercore 9y ago
  I've found VSCode Vim bindings _really_ buggy. Sometimes non-responsive to the escape key until I press it a few times, sometimes it will kill highlighting of code blocks until I switch modes, sometimes enters `<tab>` in the source code instead of tab when I press the tab button. I still use it, because I've used modal editors for so long and I like everything else about VSCode, but the vim bindings are my biggest point of frustration with it. Sublime's vintage mode is, in my experience, light years better, if not in completeness, at least in stability.

zeveb 9y ago

> the value proposition is: neovim, with vscode compatible snippets and typescript-language-server-driven autocomplete (also works with vanilla JS) out of the box 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.

bryphe 9y ago
Maintainer here. Thank you for the thoughtful and articulate feedback! I appreciate you sharing your perspective and I'll give you some of my thoughts. > 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 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.