Oni: Discussion about Roadmap

[timeyyy]

Myself as well as others in the neovim chat room have talked about the idea of having a Plugin Manager.
We should implement this feature as a neovim plugin (UI agnostic).

What are the plans for the Left Pane Feature? If the plan is to provide expose an api for scripting the pane, we could talk about how we might generalize the solution of scriptiable UI elements. It could be feasible to make a vim plugin for building scriptable UI components.

tl;dr neovim supports frontend's in any languages, we should think about introducing a culture of reuse.

[bryphe]

Hi @timeyyy ,

Thanks for looking through the roadmap! Sorry that there were not a lot of details about either of these features in the roadmap - I should have more information.

Here are my thoughts on the areas you called out:

Plugin Management

The _Plugin Model_ for Oni is actually quite different from Neovim - superficially, JavaScript vs VimL is being used, but there are some larger architectural differences. In particular, my plan for Oni is to have it be an nvim multiplexer - essential an IDE with Neovim as its core editor, as opposed to just a front-end UI. This necessitates a fundamentally different plugin architecture because the plugin model has to be able to work with multiple editor / neovim instances.

For these reasons, the _Plugin Manager_ scenario for Oni would differ from Neovim in the following ways:

• Because Oni plugins would live across multiple Neovim process , the lifecycle (timing between activation / deactivation, install / uninstall) would be different.
• JavaScript plugins have unique requirements (resolving npm dependencies, native dependencies)

Because of this, I don't think a plugin manager in Neovim core would actually solve the problem for Oni. Likewise, Oni's solution doesn't really map back very well to Neovim, especially in terms of maintaining Vim compatibility.

Solving the Plugin Manager problem in a general way for Neovim is actually a much more difficult problem than it is for Oni - because it has to appease an existing Vim community and be seamless in migration across the different plugin managers that already exists. And I don't believe the decisions and tradeoffs I'm making for Oni make sense in general for the established user base for Neovim. But if some of these concepts do make sense to bring back, I'm open to it!

Left Pane

The _Left Pane_ I have in mind for Oni is similiar to VSCode's left pane:

It's a poor name in the roadmap but essentially it's a quick launch panel that Oni plugins can hook into and expose various functionality (and, preserve keyboard accessibility sneak-style via #366). Left pane can mean a lot of things.

I'd like to bubble up some convenience methods for opening up a file explorer, a search experience, Neovim's terminal, source control integration. Long-term, a debugger would be great. Maybe some custom specific tools like an embedded browser.

For this, I'm not sure it's something that makes sense in the context of Neovim. This sort of interface doesn't work well in a terminal UI (although some of the patched fonts do some intricate things for statuslines, etc).

A good example of a feature that I believe would be useful for Oni and makes sense in neovim core would be something like multiple cursors: #184

A core implementation for that is much more valuable and robust than a UI-level implementation.

I'm definitely open to reuse where it makes sense - I'll keep this issue open so that we can discuss if there are any other opportunities for reuse, or features that Oni has that make sense in the context of neovim . I hope that as I can get some more time I can make some contributions to Neovim directly :smile:

[timeyyy]

Because Oni plugins would live across multiple Neovim process , the life cycle (timing between activation / deactivation, install / uninstall) would be different.

This could be taken into account, or we supply a simple api which can be composed to fulfill any use case.

JavaScript plugins have unique requirements (resolving npm dependencies, native dependencies)

We could have support for external plugin tools, similar how to neomake can be made to support most tools

Solving the Plugin Manager problem in a general way for Neovim is actually a much more difficult problem than it is for Oni - because it has to appease an existing Vim community and be seamless in migration across the different plugin managers that already exists.

Making things general/reusable is generally a bit more work. It is definitely worth it though.

• We could start of only implementing support for Zplug, someone may come along and add support for Dein, and now your users have more flexibility about the plugin manager they can use for free.

  • GUI's for plugin management might pop up in nvim qt etc

Hit me up before you tackle this feature, we can discuss/pair and see what we can come up with. I also have use cases for a UI plugin manager one day.

[bryphe]

This could be taken into account, or we supply a simple api which can be composed to fulfill any use case.

The _any use case_ is pretty broad - I'm not convinced that an API that works well to fill in the gaps for Vim-ecosystem plugin managers will satisfy the use cases required for Oni. But I'm definitely open to discussing it.

As I get closer to looking at it for Oni, I'll dive a bit deeper and come up with the set of requirements I'm looking at, and we can look at it together and see how it might map to a Neovim API, so that we have a more concrete basis for that discussion. It'd be helpful to know what the API might look like on the Neovim side - I'm assuming it will be based on some of the most popular plugin managers.

Making things general/reusable is generally a bit more work. It is definitely worth it though.

Agree in general, but it's important to be pragmatic. One pitfall I've seen is that sometimes, a feature will sound _superficially_ the same for a solution A and B - and it ends up being generalized into a _more complex_ solution, because the generalization ends up being the wrong abstraction to solve either problem, and both the generalization along with A+B end up more complicated than required - which ends up making the solution take significantly more time to develop, carrying more bloat and complexity at the end.

I've seen some of my friends startups fail with this - instead of focusing on the problem domain, they get caught up in generalizing to the extreme, and it becomes an inimical undertaking as they end up spinning their wheels instead of solving the actual business problem. For Oni, I view it in some sense as an experiment, and for an experiment, being able to iterate quickly and get feedback quickly is paramount. Right now, Oni has the luxury of being in the "move fast and break things" phase 😄

Of course, it's a spectrum, and on the other end of that spectrum is what you're describing - where a solution is just reinvented every time and that has cost in terms of duplication and maintenance as well. I see this in some other projects I'm involved in and it is very frustrating. Obviously that is not desirable either, so you have to find the right balance. It's usually not black-and-white, especially as software grows.

Identifying the commonalities and differences between the solutions can help guide that decision, which sounds like the next step for us.

Hit me up before you tackle this feature, we can discuss/pair and see what we can come up with. I also have use cases for a UI plugin manager one day.

Definitely! I really appreciate you proactively seeking this out - we'll continue to discuss and figure out the right solution. Pairing and collaborating sounds like a great idea.

Just an FYI, in terms of timeframe, I likely won't be starting work on the plugin manager until ~September. At that time, I'll put together a set of requirements from the Oni side and make sure we get together to discuss. Thanks for the time & thoughts around this!