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.

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.

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.

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

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'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.

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.

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.

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.

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.

[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?

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