Oni: Using Oni with terminal based editors other than Neovim?

[leeola]

Is the architecture of Oni being designed to support other editor servers than Neovim? Ie, I'm a Kakoune user, and Oni looks really nice! I'd love to help Oni support Kakoune as an alternate to Neovim. I imagine Emacs users might like the same too, though I'm not sure if Emacs could support that.

Thoughts?

[oni-bot[bot]]

Hello and welcome to the Oni repository! Thanks for opening your first issue here. To help us out, please make sure to include as much detail as possible - including screenshots and logs, if possible.

[justinmk]

What do you mean by "term editor"?

Does kakoune have a UI protocol? Examples of kakoune remote UIs?

[leeola]

It does I believe, which is why I'd like to look into supporting Oni. I'm not too familiar with the UI server though. However, if Oni has no plans to support multiple backends then there's nothing I can do :)

I imagine it's not easy, so I wouldn't blame the project for staying focused on just Neovim

[justinmk]

I found this and this.

Perhaps kakoune could support the Neovim UI protocol? If you instead focused on that, you would be compatible with 10+ existing Neovim UIs, which would increase kakoune's UIs by 10x.

[leeola]

That's a good idea, furthermore I bet it would be reasonable to implement a bridge to translate the Neovim UI protocol back and forth to Oni. Hadn't thought of that, appreciate it! I wonder how multiple cursors would be supported. Regardless, investigation is required :)

[leeola]

I'm looking into this now. I'd like to donate and be involved in the project if it looks like I can make Kakoune support a reality. Note that this mainly involves Kakoune, but I'm sure many assumptions in Oni will be involved due to different plugin architectures.

With that said, on the note of assumptions, is the backend of Oni modular enough to enable large amounts of features being enabled/disabled depending on something like a Kakoune backend vs a Neovim backend?

I'd hate to constantly be going against the grain due to the majority of features being developed with a vim-centric outlook (like plugin management, etc).

[CrossR]

Is the architecture of Oni being designed to support other editor servers than Neovim?

I think we'd need @bryphe here to give a better answer...
But broadly, I know there has been at least some thought that has gone into this area (I remember discussing it/reading it ...somewhere but am unable to find it right now).

There is the concepts of OniEditor and NeovimEditor in the codebase, to split the two up. Currently the OniEditor just has simple functions that call to NeovimEditor but if there was a second backend I assume the idea is that it uses whatever the relevant function would be.

Ie instead of input calling return this._neovimEditor.input(key) we'd instead return return this._currentBackendEditor.input(key), and a new backend would need to cover the functionality defined over in https://github.com/onivim/oni/blob/master/browser/src/Editor/Editor.ts.

However... I do also expect that there is some parts that are very neovim specific throughout the code, even if only in small ways. Ie what I've described fits the Editor very well, but some of the surrounding services contain parts that are fairly neovim specific, as far as I know. Ie, the find functionality populates the QuickFix buffer with nvim commands and so on.

[justinmk]

Trying to support multiple editors is equivalent to designing an editor-agnostic protocol (like LSP, but with 10x scope). Kakoune should do the work once, not every UI N times. Or alternatively, someone should develop an editor-agnostic protocol.

[leeola]

I'm not clear on what you mean; Are you saying that rather than making a bridge for kakoune <-> neovim ui protocol <-> oni, Kakoune should switch to neovim ui protocol directly as a first class implementation?

If that's the case I'd have to agree, but that's unrealistic, at least from my perspective. I'm trying to think of solutions to work with Oni as a mere user, not a project lead.

[justinmk]

I would suggest hacking up a POC (talking to kakoune from Oni, using the kaoune json-ui protocol) and see where you get. Instead of worrying about future architecture.

[badosu]

I think @justinmk is referring to the best scenario where UI providers only implement the 'Editor GUI' interface and you just plug your implementation to it. The editor being the server in this protocol.

If you think there's a straightforward bi-directional mapping between vim and kakoune on the most essential features then I think it could be feasible.

However keep in mind that this would require a zero overhead abstraction layer in which your implementation would require no maintenance from the mainstream development, and could be used as modular as possible, to make this push realistic.

And as @justinmk said, this effort would be all done just for Oni, so the best course of action would be to specify an Editor Protocol and when you want to support it into a new Editor GUI (say VSCode or Atom) you just need to implement the protocol layer.

[CrossR]

I should be clear here: Whilst I've seen it discussed, it was more in the context of making a second persons job easier rather than Oni itself doing it. As you say.....an editor protocol is something for a team a few tens of sizes bigger!

[bryphe]

This is a really interesting discussion - thanks @leeola for logging the issue and all for the contributions! Been fun to read through 😄

It would be _awesome_ to have a common protocol for client/server communication for editors - but although many editors are moving towards this architecture (Xi, X-ray, etc), there's no common protocol. Perhaps later this would be feasible, but it would be a large undertaking - if there is a common protocol, it would certainly make sense for Oni to work with it.

Speaking to @CrossR 's comment above - an implicit design goal I've had with Oni's architecture is to be _modular_ - at it's core, devoid of an editor, it is just a web-based window manager, configurable with Javascript, with a bunch of 'modular blocks' you can put together in interesting ways.

The _Editor_ (which is the biggest of these 'modular blocks' we have) - __is intended to be abstracted__. That means you could have any 'under-the-hood' implementation of the _Editor_ - whether it's Neovim, kakoune, Monaco, xi, etc... The only requirement is you implement the Editor API here: https://onivim.github.io/oni-api/interfaces/editor.html (which includes implementing the buffer events, like onBufferChanged, onCursorMoved, openFile, getBuffers, activeBuffer, etc...) - and we actually even have a starting point here: https://github.com/onivim/oni/blob/master/browser/src/Editor/Editor.ts

Having the architecture be modular is important to me... because I've toyed around with ideas around a web-based IDE leveraging Oni's building blocks, and those projects might (unfortunately) __necessitate an alternate Editor implementation__ (either because they need to work in the browser, or appeal to devs not familiar or open to modal editing, etc) - that would all be external to Oni. But having this Editor abstraction in-place and correct makes it easier to re-use Oni's functionality.

Of course, Neovim is the first-class citizen for Oni, and is the only 'editor' implementation we have today. (Although as @CrossR pointed out - there's actually _two_ - the NeovimEditor is for core neovim functionality, and OniEditor builds on the NeovimEditor with additional functionality). The vision for Oni is to be the _most productive way to go from thought to code_, and for me personally, Neovim is critical to deliver on that. However, architecturally, there should be no technical reason we can't support other Editor implementations.

In terms of implementation... we could extend our API / configuration to support additional editor strategies, like via a plugin (perhaps oni-editor-kakoune) which would let Oni know about a new editor implementation:

// This API is not implemented yet, but we could add it!
Oni.editors.registerEditorFactory("kakoune", () => new KakouneEditor())

And then be able to specify via user configuration which editor you'd like to use:

export configuration = {
     "editor.type": "kakoune", // Let editor manager know it should use the KakouneEditor
}

That would mean minimal changes to 'core' to support this scenario - we'd just have to change our startEditors function to respect this configuration setting.

The cool thing is... this could also be a way to expose a minimal Neovim strategy, too - we could support an "editor.type" of "neovim" or "minimal", which would spin up a Neovim editor surface (the barebones NeovimEditor) - without all the Oni extras. In other words, this could also be leveraged as a way to implement a minimal strategy for #2022.

Then, the bulk of the work is in implementing KakouneEditor such that it maps to our Editor API and talks to the Kakoune API (just like how our NeovimEditor talks to a neovim instance and exposes actions via the API). Also, our abstraction isn't perfect today - there are some places that talk to Neovim directly instead of the editor API, so we'd need to fix those.

I'd hate to constantly be going against the grain due to the majority of features being developed with a vim-centric outlook (like plugin management, etc).

This actually shouldn't be a problem. The NeovimEditor is what cares about Vim plugins, but if you're swapping to a different Editor implementation, the Vim plugins wouldn't even be loaded. Plugins that use Oni's javascript API (like snippets, language server, textmate highlighting) should work reasonably, as they would talk to the Editor abstraction.

Sorry for the wall of text... hope that helps give some ideas. I definitely see value in this as a test of Oni's architecture & modularity - happy to help if there are any questions!