Direction of Oni?

[Bretley]

Just a few questions with regards to Oni, as it is a popular repo and has a lot of potential.

Plugins and Extensibility

Are you trying to have Oni be the framework for plugins? Will Neovim plugins work out of the box to provide an easy transition, or will Oni be the only configurable variable.

In my opinion, if you want to get people to switch, Vim configurations and plugins have to work, and then people will be willing to configure Oni on top of their already decked out vim. I don't know if the UI decoupling will make it easier for you to handle autocompletion type functions from plugins. You're not going to get all of the plugin writers to switch to Oni, and fragmenting the community is not a good idea. I know for a fact that I personally won't be switching over if my config doesn't port over well. Reconfiguring for many is not an option, unless Oni will come with comparable plugins.

Js, Viml, Lua

I've seen in several of the comments and issues the pull between JS and VimL, but what's going to happen with Lua? Much of neovim is being changed, or at least transpiled to Lua for speed improvements. Will this have any bearing on the development of Oni? We don't want to work on a hardcore Viml/JS project just to have to restart with Lua. I've seen some talk of avoiding VimL because of speed, but that might be less of an issue as Neovim continues.

Thanks for your time, and if these questions sound stupid it's because I am by no means a developer, just an interested highschooler.

[keforbes]

I have a similar concern (which I didn't think justified its own issue) so I'll just add on to @bert88sta's question of where you see Oni going in the future.

Given that this is an Electron app, I wonder how much time you'll spend trying to re-implement Atom features when you could just create an integration with Atom. There was a similar project which was trying to integrate Neovim with Atom but it looks like it has been abandoned. Oni is further along than that Atom integration but Atom still has a lot of the features that Oni is trying to implement. If you're trying to do something with Oni that Atom doesn't do then that's awesome but fuzzy finder, mini-map, code completion, error highlighting, and quick info popups are all implemented in Atom (or available via Atom plugins). I'd hate for you to duplicate effort if it isn't needed.

[jordwalke]

I do not currently share the same concern. I'll explain why. There are many great editors out there with great plugin systems (JS is very popular/strategic choice for plugin language). Most of them lack great vim keybindings (besides vmp, of course). Even if Oni was only using NeoVim just to create great vim-faithful key bindings (and undo/redo, cursor position, visual block mode - creating that excellent, authentic vim feel) it would be worth it even if zero Vim plugins were supported. Still, the better support there is for Vim plugins, the better, and I've proposed some interesting ways to make sure that Oni can integrate very well with other Vim based configuration. I just thought I'd express that although I feel this tight integration is great, it's doesn't seem as important when the alternative is using another IDE entirely with vim bindings that don't even feel authentic.

As far as Atom is concerned, I have to say I appreciate the instant startup time of Oni and would not see much point in integrating into Atom unless somehow you found a way to make Atom's startup time/perf as fast as raw vim.

[bryphe]

Thanks all for the great feedback / discussion! I feel bad in a way that I didn't have the repo in a better spot with more details on the vision of the project :)

My long-term vision would be to have a modal editor for the 21st century. I've gotten really hooked on Vim in the past year - in my opinion, it is the fastest way to author text. For a long time, I used visual studio with C# and I really enjoyed the intellisense and language features, but I tried coding on my laptop on a long flight, and realized how hard it was to deal with the trackpad... and realized there had to be a better way!

I then got into Vim, using gvim on windows, but missed some of the language features. So then I tried Atom, and it's actually a very beautiful editor, with a mature VIM binding. However, as was pointed out, it's slow. Like, so slow that I assumed Electron wasn't really a viable option for a while. I would love to just use Atom with Neovim, but when I looked at the performance, I found they weren't just one-off issues but core architectural issues. If you're interested in the performance work they are doing, check out these issues:

• Editor window startup is slow atom/atom#2654
• Possible Startup Improvements atom/atom#9572

Unfortunately, they've been open for a year or more, and there are a few other issues that are non-starters for me.

I then tried out https://github.com/microsoft/vscode, and VSCode is actually a really great editor - it's much faster than Atom in most areas, and I think it proves to people that an Electron-based app can be a viable editor. I've used the VIM plugin there: https://github.com/VSCodeVim/Vim and the author there has done fantastic work and it's very mature. I'm a big fan of both VSCode and VSCodeVim plugin, and I tried really, really hard to make that my primary editor. However, for VSCode, the lack of extensibility of the core editor was a problem for me, and no matter what vim emulation you do, there are always cases where something goes differently than you expect, and to me thats like nails on a chalkboard.

I've also been really inspired by some talks like this:
(A Whole New World - A new text editor) https://www.destroyallsoftware.com/talks/a-whole-new-world
(React w/ Live Reloading) https://www.youtube.com/watch?v=xsSnOQynTHs

And then projects like this:
http://lighttable.com/

I would really like to incorporate some of these concepts into an editor. Being able to see your code live as you edit is such a powerful concept, and it makes writing code a whole different ballgame.

At the end of the day, whether I was in Visual Studio, Atom, VSCode, I felt like I had to make a compromise in some direction, so that's sort of how this project came about - I just wanted to build an editor that fit my workflow and let me try out some of these ideas, without compromising. Neovim made that possible by allowing an arbitrary front-end and letting me preserve everything I enjoy about VIM.

I've done a lot of rambling... but to give thoughts on the questions more directly:

1. Plugins - I agree with both points above - to me, I use a relatively small set of plugins, but these are very personal. I would really like to make it easy to transition to Oni from Vim/Neovim if a developer feels it is the right fit for them - I think if Linux support #13, Synchronizing VimScript keybindings. #20, and Synchronizing colors: #33 can be implemented reasonably, then that would go a long way in bridging the gap for the transition. I think if we can also add a variable like g:oni or something, that could help people too.

2. Lua - I'm actually not too familiar with how Lua is used in Vim - I've never used a Vim distro that was built with Lua support. I'm more familiar with it in the context of a scripting engine for games ;) Let me know if there are some concerns here, I imagine there are solutions - the worst case is Neovim always supports writing to stdin/stdout, so you can always implement a protocol over async.

3. Re-implementation - I think we covered the Atom issues above, but I think even without Atom, we still have a ton of opportunity for reuse. The React community has an incredible set of controls and libraries (thanks @jordwalke !!) to leverage, and Microsoft has done a great job making their plugin infrastructure open - https://github.com/Microsoft/language-server-protocol - and the node community has such a rich set of NPM modules that can be used, so there's a ton of opportunity to reuse some existing controls. I'd like to reuse existing ones where we can, and then if we need to build new ones, eventually refactor and make available to the community.

Oh and by the way, @bert88sta , not stupid questions at all - thanks a lot for asking them!

[JakubJecminek]

Are you looking for any help on the project? Oni seems to me like great project and I would like to help in my spare time. Do you have some backlog of features you need to implement?

[Bretley]

@JakubJecminek the issues are mostly features and or bug fixes, any of those would be great
:)

[bryphe]

Are you looking for any help on the project?

@JakubJecminek Definitely! I think this is an ambitious vision and to build something meaningful for the community I'll need a lot of help. I'll be porting over some of the items I had in my TODO backlog as bugs / features in the issue tracker here, it would be awesome to have your help in the ones that interest you. And if there are ideas you have that aren't tracked, feel free to log them here so we can discuss.

[bryphe]

I'll close this out for now, as the project has matured significantly since this initial discussion. Great to have this context though, and feel free to log an issue if there are still aspects of the direction that are unclear!

[trusktr]

mini-map

This would be too awesome! Maybe Oni can open the current window's buffer in another window and render to a shrunk down canvas on the side of the Oni window?