UI: Externalize Window Management

[bryphe]

There are several shortcomings to how Oni manages windows today.

• Convoluted code path - the overlay / overlaymanager concepts are unnecessarily complex and confusing
• Difficult to extend - it's non-trivial to add new functionality, like a git blame marker plugin, or something like markdown preview

For the overlay scenarios, it'd be really nice if each split had its own 'container' div. This really isn't possible today, as Neovim as a whole manages rendering to various splits.

I'd like to look at the possibility of 'multiplexing' Neovim instances to address these shortcomings. In effect, this would allow us to move window management to Oni, and allow us to really build on that experience - we could have first-class animations and much simpler overlay code if we manage the windows explicitly. Each 'split' would be its own Neovim process.

My original concern with this was that it would be difficult to persist settings between the splits - for example, marks, history, etc. @justinmk had a great write up on how this could work:
https://www.reddit.com/r/neovim/comments/5ym9p3/future_of_ui/

[FrigoEU]

For me, this issue is super important, but also still very vague. I love Vim's editing experience but hate its extensibility story. Now most extensions that I'm interested in (and spacemacs is my biggest influencer here) are a git interface, keybinds explorer, compilation feedback, search, etc. These are all panels that are being drawn over/around the editor.

I don't know how you see this, and I don't know how I think it should be, but I think if we could present a nice API to plugins (and I think React can help here) next to the "internal" panels, it would mean the world.

[bryphe]

I love Vim's editing experience but hate its extensibility story.

I'm with you 100% here. This is exactly what motivated the creation of this project.

For me, this issue is super important, but also still very vague

Definitely! I have some ideas in my head, but haven't had much chance to experiment yet... I think it's worth calling out some of the primary goals:

• Git interface
• Git blame annotations
• Keybindings explorer
• Compilation feedback
• Search
• Live Preview (React components, HTML, Markdown)
• File Explorer
• Plugin Manager

I see three broad classifications of these:

• Floating Panels - these are independent pieces of UI that exist independently or on top of the editors. The log panel you implemented is a good example. The file explorer and git interface also potentially fit this, but would be on the side.
• Overlays - these are UI entry points that place UI on top of an editor window. We have lots of examples today - the completion, the error bubble, the quick info bubble. Other items I could see extending this would be things like git blame.
• Additional Renderer Types - preview modes would fall into these. They might be rendered completely differently from how we render the windows today, but maybe that is as simple as specifying a separate render strategy that is provided by a plugin.

Floating Panels would be completely new UI, independent of the editor. Overlays would be layers on top of the editor window - so they would augment the existing editor rendering strategy. Additional Renderer Types would competely replace the existing editor rendering strategy.

One thing that is important to me is maintaining Vim key bindings across these different windows. So I should be able to use the keys I'm comfortable with for navigating my file explorer, my git interface, my keybindings explorer, etc. One thing I'm experimenting with is supporting custom renderers for a buffer - sort of like how NERDTree renders to a scratch buffer, we'd have a scratch Neovim instance that would could be used for navigation, but I could do custom rendering for that neovim instance / window - so I could add folder and file icons without needing a font hack. This will be more realistic once the refactoring to support #201 is complete.

Sorry if this isn't very clear, just sort of thinking and brainstorming through the keyboard. 😄 But I agree with you, I think if we can have a reasonable story for all those - like exposing an API that takes a React component as you suggest, along with some of the other plugin capabilities - we could go pretty far in tackling many of these scenarios.

[FrigoEU]

To pile on the brainstorm, one thing that I was thinking is:

1. some functionality lives in editor windows/splits. One example of that is magit in spacemacs, which just always opens in a split next to the file that you're editing. If you already have a split open, it overtakes one split. I like your idea of reusing neovim for that to keep all the bindings working. A custom renderer also sounds like a good idea, maybe some kind of read-only attribute can be specified somewhere? ie; you don't want to be able to start typing in your git log overview.

2. Second is panels that "steal space" from editor windows. The new messages log is one example for that. It's nice that it shows up on the bottom, but it shouldn't render over the existing windows. Now that I think about it, this should be just a vertical split, right? Again with neovim handling key binds. One thing that I don't know how this would fit though, is when I search in spacemacs, this "vertical split" kind of thing comes up where you have at the top a search bar, and at the bottom your results. I'm unsure how this fits in the << let's "just" make new neovim instances for every window >>.

3. As you said, overlays. Here we just need a clear "system" (could we just do simple z-indexing?) so that the intuitive order of overlays gets respected.

Btw, these "Additional renderer types" is I think where Oni will start shining :). All the other stuff is kinda things that other editors already figured out. For example I love magit, but I kinda fear having to implement the whole thing in Oni again...

[bryphe]

Starting to look at this in the context of #442 - a few initial blockers:

• PluginManager and NeovimInstance are both associated 1-to-1 with each other. For multiplexing the Neovim instance, this will need to be decoupled. NeovimInstance isn't used too extensively in PluginManager, so it seems like it can be decoupled fairly easily.
• Some pieces of UI would be global (ie, QuickOpen), whereas other pieces would be local to a particular window (like AutoCompletion) - they would need to start to be split up.

Need to think about how to streamline some of this architecture in light of this new model.