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. 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!
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 :)