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.
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.
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.
> 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.
I think comparing it to emacs is kind of missing the point; Oni is primarily targeting two groups of users: long time vim users who want to spend less time configuring plugins and who want some of the modern features that newer IDEs provide; and users of said IDEs who want to experiment with vim but find the learning curve to be a little too steep.
> 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
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), 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.
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.
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.
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)
>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?
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.
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.
MacVim or gvim is still a regular native app without a js vm and a web enviroment. It's less minimal then terminal vim, but way more minimal than electron.
I don't mind electron myself, but that ps sounds fairly disingenuous to me.
The kinds of things in your comment are the kind of things that make me consider actually installing Oni rather than just going "oh neat, people are making Neovim frontends" like I did when I first saw this post.
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?
I liked the irony in this post, considering that the main draw of Electron apps is that they are supposed to be cross-platform. (To be fair though, FreeBSD is pretty niche.)
Would be interesting to see if we could compile Neovim via WebAssembly... If that's the case, it would certainly be feasible to run Oni in the browser with a few (minor) tweaks. The UI layer is react-based and would be trivial to run in a browser.
Electron does provide quite a lot of apis that do not exist (and hopefully never will) in browsers. Namely, complete access to the filesystem. It also does provide a way of creating native plugins.
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.
Native Mac apps can be crazy fast. Haven’t seen a reasonably fast Electron app yet. Plus you lose wonderful native Cocoa text features, such spelling, dictionary, undo, etc.
Note that, according to others in this thread, it is not running in full browser mode, with the backend using javascript.
Instead, it is using electron just for rendering.
People here claim this is a lot better for performance. I've no personal experience to verify this.
I'd tend to agree with GP, but this seems interesting.
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).
While Oni is still very young, it looks like one of the more promising Neovim frontends, and the development is progressing quite fast!
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,
I installed it and loaded my init.vim. It is just so slow. I'm a pretty heavy user of snippets, and it honestly takes like 1 second for my snippets to appear after I call them.
Nvim desparetely needs a good GUI. Ever GUI I've tried (I think I've tried all of them) lags when calling snippets.
I've been very happy with gvim for many years, so I don't think I will change any time soon (although Emacs + evil is very sweet too, specially writing Clojure).
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.
For me, it is to avoid context switch. I'll have all the files I need open in different tabs and switch between them. If I need to cross reference something, I'll open it in a new pane.
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.
One Vim to rule them all? Looks nice, will have to try it. Will never be a daily driver for me, as it’s not a terminal editor, but I like their thinking.
It says it's powered by React and (presumable) Electron - does it have the same kind of issues that Atom does? Can it open big files, how responsive is it, etc.
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.
If you're comparing Oni to Atom, the architecture is actually quite different. Oni uses Neovim at the core to manage buffers & buffer manipulation (in other words, a native layer vs JavaScript in Atom) - this is a major benefit when working with large files. In addition, Oni uses a canvas renderer for the editor surface vs the DOM used by Atom. Together, these significantly improve the responsiveness of the tool. Architecturally, Oni is more similiar to the Xray project being investigated by the GitHub team: https://github.com/atom/xray.
By default it doesn't load your init.vim, but if you change that flag in the config it will behave exactly like your regular neovim install (since that is in fact exactly what it is: a very light canvas renderer wrapped around neovim). I have been using it for a couple of weeks with all of my vim plugins with no issues (ctrl-p, buffer gator, easy motion, etc).
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.
I don't have any problem with 1000 line files in Atom either. It sucks at 100,000 line files, but I only ever open them in an editor by accident (Atom gives a warning). That is what grep and tail are for
Readit News
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.
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.
At least Microsoft knows how not to make it suck so much.
They are planning to use neovim as a backend for it too.
Also neovim rewrite: https://github.com/Chillee/VSCodeNeovim
Deleted Comment
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.
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.
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.
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.
[1]: https://twitter.com/oni_vim/status/969315834626695168
Perhaps a dumb question, but wouldn’t it be a better idea to make a proper vscode/neovim plugin?
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.
I don't mind electron myself, but that ps sounds fairly disingenuous to me.
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 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.
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,
which adds support for the Haskell LSP, hie, behind stack.[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.
Most neovim plugins work great with Oni :) Just set the `oni.loadInitVim` configuration value to `true`: https://github.com/onivim/oni/wiki/Configuration#oni
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
Deleted Comment
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.
Deleted Comment