Oni: Modern Modal Editing – Powered by Neovim(github.com)
github.com
Oni: Modern Modal Editing – Powered by Neovim
https://github.com/onivim/oni
114 comments
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.
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.
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.
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.
"tabs" does not mean that you have to use the mouse at all.
I use Tabs extensively in browser and other apps, completely with the keyboard
gt still works in Oni. You can also <C-w>h over to file explorer.
I use tabs in vim because opening more than 2 buffers on my laptop gets really crowded.
I use tabs in vim because opening more than 2 buffers on my laptop gets really crowded.
Eight acknowledgements, but no love for Bram? That's pretty cold, even if you don't like the way he runs the vim project.
The challenge with building a new editor, is that it has to be superior to those editors already available. In this case that means beating Emacs which Im not seeing Oni doing yet. Will be interesting to follow though.
Qoute from a comment from the dev down the threads
"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."
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)
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)
Fair point
From the Goals section:
"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?
"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?
Not really, it’s certainly capable of terminal use but the various graphical frontends are a lot more convenient to use. It has never been the aim to only serve terminal usage.
Looks great. Two questions:
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?
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?
Author here - that's a great question on VSCode. I actually tried really hard to get my 'Vim workflow' to work with VSCode - even creating a plugin for relative numbering. I'm a big fan of the work that the VSCodeVim / VSCodeNeovim teams are doing as well!
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 :)
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 :)
Thanks for a response. I just installed it and do think that it is missing a few features that are important to me (as in, these are my opinions):
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. 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.
For 1, there's https://github.com/elixir-editors/vim-elixir.
Is that compatible with the editor OP is talking about? To clarify, that’s what above feedback was for. I don’t understand why people downvote comments without even knowing the context of the conversation.
I did not downvote you but here are some possible reasons:
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!
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!
Yes, Oni is just an alternate frontend for vim and is compatible with Vim plugins (instructions here: https://github.com/onivim/oni/wiki/Plugins#installing-a-vim-...). I don't think there was anything wrong with your comment that merited downvotes.
As a developer of the VSCodeVim plugin, Oni is a great inspiration and we are hoping they pave the way for the Neovim API (which is starting to mature). We have started using neovim for a few things, the command line for example. So while we have started getting our feet wet, hopefully something like Oni (or Oni) replaces us...soon :)
Thanks xconverge, it's great to hear from you and appreciate the kind words! I'm a big fan of the work you're doing as well - really impressed with the VSCodeVim plugin.
Hey xconverge. Just an update, I reinstalled the plugin and configured it to work with neovim and am very happy with the results.
Thanks for contributing to the VS Code ecosystem.
Thanks for contributing to the VS Code ecosystem.
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.
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.
Most neovim plugins work great with Oni :) Just set the `oni.loadInitVim` configuration value to `true`: https://github.com/onivim/oni/wiki/Configuration#oni
Most neovim plugins work great with Oni :) Just set the `oni.loadInitVim` configuration value to `true`: https://github.com/onivim/oni/wiki/Configuration#oni
> Can it open big files
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
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]
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.
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
The latency and memory usage is arguably far worse than Atom but that would be expected given its infantile state.
[deleted]
not really impressed, quite far behind from geany and vscode, vim is handy enough too, so what's the selling point that I have missed?
The project README.md doesn't do justice to the improvements that Oni has been pumping out.
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.
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.
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.
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?
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?
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.
Interesting project that did something similiar for Vim: https://github.com/coolwanglu/vim.js/
Interesting project that did something similiar for Vim: https://github.com/coolwanglu/vim.js/
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.
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.
Access to the file system can be done via HTML 5 File API.
The File API is very limited in comparison what can be done with the Electron fs API which has direct access to the file system.
Which is a lame excuse for using Electron disguised as native app, in a connected world, even native apps should be sandboxed by default.
I seriously doubt it would be impossible to use Electron as it really is, a Web App.
I seriously doubt it would be impossible to use Electron as it really is, a Web App.
As much as I prefer real native applications and like hating on electron, I have to give it some credit. It is not just chromium, it is chromium+nodejs and all the stuff that comes with it.
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.
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.
> Unless all of the communication between the frontend part and the native tooling is done via sockets.
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?
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?
Some data is not suited to go through asynchronous streams with a lot of parsing. At some point I needed to pass real-time eeg data to an application and we were exploring Cordova as an option. The jitter and absurd latency (over 15ms) was a non-starter. Things might have gone better but not everything can be solved by immutable data structures.
For comparison, the same data transfer using Electron native plugin took well under 1ms.
For comparison, the same data transfer using Electron native plugin took well under 1ms.
Can you tell us the benefits of running freebsd on a development machine?
I just feel at home with FreeBSD. I mean it’s not perfect. That’s why I run FreeBSD on some and not all of my computers and instead run Linux on the rest (and also macOS on one of them).
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 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.
Thanks for your support, Justin! Oni wouldn't be here without the awesome work you've done:)
Neovim has been a joy to build on - fast, performant, and stable. Great example of a high-quality OSS project!
Neovim has been a joy to build on - fast, performant, and stable. Great example of a high-quality OSS project!
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.
Sorry I never used a Mac, but how can undo be a "wonderful" features ???
Undo on native Cocoa apps have a few delightful “smarts” that you begin to take for granted and can be infuriating when absent.
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.
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.
The features mentioned are built into the standard macOS toolkit, which makes them handily available and consistent between applications. I don't think they were listing them for being unique as much as pointing out the feature consistency.
you can use nvim-qt or neovim-gtk and keep having a minimalism experience.
This cropped up several months ago on here, see here for the comments from back then: https://news.ycombinator.com/item?id=15060417
It's disappointing to see that 90% of the comments there are people arguing about electron.
It’s a valid point. Lots of people use vim for its sheer speed, which you throw out with the bath water when switch to electron.
I haven’t tried the app yet but it seems that this is not true for this editor as NeoVim is the backend, not JavaScript.
1.5G for a fresh startup with no files open is unacceptable when looking for a lightweight editor. That's what made me go back to vim; my previous laptop with 4G RAM couldn't handle vscode + a browser without going out of RAM.
I had some hopes for oni but so far it doesn't solve any issue I have either with nvim or with vscode.
This looks really cool.
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?
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?
The Mac install guide [1] references needing the following in order to use "PressAndHold".
> To enable key repeat when pressing & holding a key in Oni, write the following in your terminal:
> 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
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.
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.
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.
If I have to deal with yet another Electron based editor, there is no reason to go beyond VSCode.
At least Microsoft knows how not to make it suck so much.
At least Microsoft knows how not to make it suck so much.
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.
They are planning to use neovim as a backend for it too.
That looks really exciting actually!
https://github.com/VSCodeVim/Vim/issues/1735
VSCodeVIM has neovim support too https://github.com/VSCodeVim/Vim/issues/1735. It's still an experimental feature though.
Also neovim rewrite: https://github.com/Chillee/VSCodeNeovim
Also neovim rewrite: https://github.com/Chillee/VSCodeNeovim
[deleted]
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.
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'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.
Sublime's vintage mode is, in my experience, light years better, if not in completeness, at least in stability.
What platform are you on? I've experienced no major issues with the vscode vim plugin on Mac or Windows.
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.
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.
I'll have to check out the key bindings, thanks for the tip. This is on OS X (High Sierra)
I feel your pain :)
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.
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 does VSCode vim plugins compared to evil-mode of emacs?
evil-mode is actually useful. VSCode's vim plugin loads really slow when you change project, doesn't have proper insert/normal/visual mode map, etc.
Have you used it recently? It works pretty well (?)
It works pretty well for movement, selection, etc. Anything that uses longer key chords is out—vscode is limited to two keystrokes afaict. It's really frustrating trying to replicate a highly customized spacemacs or vim setup.
Some time ago I used to work on VSCode with vim plugin and to tell the truth all those vim plugins were nothing compared to spacemacs or evil-mode on vanilla emacs.
the vscodevim plugin still has problems with things like scrolling (c-e, c-y, c-d, c-u) and is missing ex commands. Evil is more comprehensive
The slow scrolling key-repeat issue was recently fixed.
> 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.
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
> 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.
> 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.
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.
[1]: https://twitter.com/oni_vim/status/969315834626695168
[1]: https://twitter.com/oni_vim/status/969315834626695168
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)
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.
>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?
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.
The current vim plugin from VSCode uses neovim under the hood, at least for some operations
Electron frontend is precisely the thing I really don't want from a tool like vim...
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.
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).
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).
You might not, other people might.
What is the sweet spot of Oni? If you're looking for a full-blown IDE with vim UI on top then the vs code IntelliJ Visual Studio does reasonably good job at that.
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
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
I can't speak for the IDE-oriented folks, but as a veteran vim user, never really satisfied with the typographical and UI limitations of the terminal, Oni is the first graphical frontend for vim that satisfies me.
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.
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.
SpaceVim is not same as oni, oni, is a gui app for neovim. And SpaceVim is a configration for vim/neovim to make it works like IDE,
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:
https://spacevim.org/SpaceVim-release-v0.7.0/
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:
https://spacevim.org/SpaceVim-release-v0.7.0/
@wsdjeg: thank you for your continued work on spacevim
I do think I might prefer the approach of the asymptotic of development approaching vscode features with a base in pure Vim rather than the asymptotic approaching full Vim compatibility within vscode, and so I really want to like Oni.
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.
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.
This has been an issue for some time, tracked in (https://github.com/onivim/oni/issues/1568) and (https://github.com/onivim/oni/issues/405).
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.
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.
The main issue preventing smooth scrolling is it will require each split to be an independent neovim instance, which is (in my opinion) not quite as nice as native splits. There is a feature in development that does use a separate view for each split and smooth scrolling is possible if you are willing to give up your native splits. In practice I haven't noticed it because I don't use the mouse for scrolling.
does it actually bring any advantage except being closer to VIM in terms of navigation?
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?
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?
Does it work with vim plugins? How much of my pre-existing vim configuration can be transfered onto oni? It's currently about 500-1000 lines in .vimrc and ≈50 3rd party plugins.
Pretty much 100%. It's a regular instance of neovim, just with an Electron UI around it. I've had no issues with my .vimrc at all.
Even things like Goyo? Then it's pretty damn great. Even though I hate Electron apps. Thanks, I need to try it.
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.
Related projects — https://github.com/neovim/neovim/wiki/Related-projects
There are many projects on that list, if you want a fast native app I would recommend:
* 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.
* 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.
https://github.com/onivim/oni/wiki/Language-Support
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.
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.
Mentioning to perhaps save time for others: just gave it a spin but it looks like there's no eslint support, and my project uses prettier/flow/etc all wrapped up into eslint.
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...