I was going to rant about this idea but it looks really good and not at all like gvim.
1. a single shared runtime install, installed transparently by the first thing to need it (similar to how the Adobe Air first-use experience worked), rather than a vendored dependency?
2. a shared VM that ran its apps in separate V8 execution contexts (like how browsers isolate tabs), but with a lot of shared resources so that each Electron app didn't end up with a GB of (mostly redundant) memory consumption?
I find that most people don't object to HTML5 apps per se; they just object to the way Electron handles things. The above was going to be the strategy of Chrome's "app-only runtime" mode, until they just killed off Chrome Apps altogether. I still think it's a decent strategy, all-said.
You can, for example, print your application's interface (i.e. your document), without having to implement your own print-layout logic, because that logic can just be the browser doing CSS @media(print) to the DOM. (Which can, with a few @media(print)-scoped rules, hide all the toolbars to just leave the document.)
Or, users can use User-Agent stylesheets (think "forcing high-contrast" or "disabling serif fonts") and browser extensions to customize your application [or, more importantly, anyone's old closed-source abandonware application that's never gonna make an accessibility update ever again], because your application's interface is guaranteed to exist in the intermediary state of a DOM tree, where those things can get to it to munge it†.
† (This is also true in various ways for each OS UI framework—and you can create native "extensions" like screen-readers that use the OS accessibility APIs of each OS—but you have to redo this work. WebExtensions are cross-platform.)
Also, with web-apps, users get final control over how the application is sized and shaped on the desktop, and so apps are forced to be at least semi-responsive—which is easy, because the default layout algorithm for any container, if you don't override it, is a reflowable-text algorithm. Web-apps are the only apps where I'm (nearly) guaranteed to have the ability to adjust the em-widths of blocks of text so that they're actually comfortable to read.
And, as an added benefit, as long as you ensure that you really are serving a static HTML document at each URL that is progressively-enhanced into being your app—then your web-app can double as a programmatically-accessible infobase. Google can't index a native app. You can't scrape a native app. You can't embed microformats into a native app. Etc.
I believe that a web-based UI would still be slower than a native application, if only because of the huge number of abstractions in-between, but I'd say it's something that can be overcome by (a) newer hardware, (b) better development i.e. careful profiling and optimization, (c) advancements made by the browser engine developers, and (most likely) a combination of all three.
There's also the issue with the Web as a platform, but honestly, it's not as bad as purists on HN make it. No technology is perfect. I used to be a very loud opponent of using Web technologies for applications, but I realize that ship's pretty much sailed, and we could have had a much worse outcome than this.
My main gripe with Electron has always been the inability to share resources between instances. If firing up Slack or VSCode would have the same net impact on my memory use as opening a new Chrome tab, I'd gladly run them and quit complaining.
Let's take Slack as an example. All the keyboard shortcuts use weird modifier keys like option instead of command, and I can't discover any of them by looking through the menu bar like I can in a native app.
Or for another example, the Services feature of macOS doesn't work correctly with Electron apps. In any native app I can select some text and then trigger a Service on that text (for example, I've defined a service to be able to select a bug id and hit a keyboard shortcut to view that bug in our bug tracker). No such luck in Slack.
However I really wanted to have a little more interactivity (and visuals) than what the terminal can provide and so far Oni has delivered it good enough for me.
That said, there are a lot of daily editing issues to be solved before it can be said battle-tested.
[0]: https://github.com/neovim/neovim/wiki/Related-projects#gui
> Oni brings several IDE-like integrations to neovim:
Quick Info
Code Completion
Syntax / Compilation Errors
Fuzzy Finding
Status BarPersonally I use terminal vim not any sort of nvim (maybe I should change over but then I potentially have to maintain two sets of plugins, one for nvim and one for vim. ).
No if you want to call this out, I'd call it out for the lack of features. This only supports code completion in JS and TypeScript. I have code completion plus snippets for a lot more then that with vim.
Honestly if you want to wow me, someone should build a GUI configuration tool for neovim/vim. One big benefit of GUIs is that you can generally see all the possible settings with tool tips and explanations, and I can see that being useful for vimmers, especially if it did the right thing, like using ft-plugins to do filetype specific settings, instead of a bunch of one line autogroups based on file extension.
Yes there are vim config generators, but the neovim api means you could programmatically query the current configuration and display it along with the options, meaning you could have interactive configuration modification.
I use this in my ~/.config/nvim/init.vim:
set runtimepath^=~/.vim runtimepath+=~/.vim/after
let &packpath = &runtimepath
source ~/.vimrc
Then I set up an alias in my zsh profile:
alias vim=nvim
All of my plugins thus far have worked without a hitch (and I have a lot of configuration/plugins). If I ever run into problems, I can bail out by removing the alias (or for a one-off editing session, I can just run: $ command vim).
You might give something like that a go.
Which seems to have fixed things.
No, this only supports the extended features fro completion for those languages. It should use the simpler completion system for other languages, in which case you are using vim's support anyway.
But we can chose to ignore those "some", just like they can keep using whatever works for them.
It's not just "literally use Neovim as the editing engine", I've tried to make editing the text in "Sublime Mode" work too, including running Sublime plugins. Work in progress, but afaik the most complete Vim integration for an existing editor. Waiting on updates to both Neovim and Sublime Text to polish it a bit more.
VSCodeVim is using it as a reference for some of their new work as well.