[WiiManic]

> but implementing a vim backend is a monumental task if you intend to be compatible with existing vim plugins

We skipped that and haven't implemented any vim backend at all!

We use/made libvim[1], which is just the vim source, that we've essentially turned into a library. So its the vim code base with terminal UI stuff stripped out, and an interface added for us to hook into it. The README of that repo has some good insight into that (including why we didn't use neovim here, as much as the team all loves nvim).

We don't support vimscript stuff at the moment, but its in progress as all the vim source code is there to load/run it as normal, its just about integrating is properly into Oni2 (making sure keybinds are working, commands are properly loaded, packing stuff up nicely for distrib etc).

(There is some other motivation bits in this doc[2]. Its outdated since we haven't edited it since before the project started, but it outlines the motivations we went in with etc).

[1]: https://github.com/onivim/libvim [2]: https://github.com/onivim/oni2/blob/master/docs/MOTIVATION.m...

[revscat]

It is my understanding that one of the initial driving forces behind NeoVim was to allow for easier embedding, such as what you appear to be doing here. If this is true, why did you decide to go with traditional vim rather than NeoVim? Additionally, since nvim lets you choose between Lua or Vimscript for configuration/extension, and I personally find Lua far more intuitive than Vimscript...

[atweiden]

> If this is true, why did you decide to go with traditional vim rather than NeoVim?

Answered here [1].

> I personally find Lua far more intuitive than Vimscript...

One of the biggest motivating factors for the rewrite of Oni was the limitations imposed by Vim/Neovim of a terminal grid of characters in the rendering layer: “Neovim treats the visible screen as a grid of cells” [2]. This precluded implementing CodeLens amongst other things [3].

I’m also a fan of Lua — I’ve written a substantial amount of Fennel — but given Oni’s goals, revamping Vim’s rendering layer is of higher importance than Lua support, particularly since the VSCode extension ecosystem is being relied upon anyway. Onivim is designed as more of a direct challenge to heavyweight IDEs than as a substitute for Vim. I already switch between Vim and VSCode depending on requirements, but it’d be great to have the best possible support for modal editing in VSCode.

[1]: https://github.com/onivim/libvim#why-is-libvim-based-on-vim-...

[2]: https://onivim.github.io/docs/other/motivation#a-new-view-la...

[3]: https://onivim.github.io/blog/2021/02/03/release-0.5.3

[RMPR]

Seems they had trouble implementing that with Neovim[0]. Relevant reddit thread[1]

0: https://github.com/onivim/libvim#why-is-libvim-based-on-vim-...

1: https://www.reddit.com/r/neovim/comments/cdf36v/onivim2_chan...

[crdrost]

Interesting. For once I am interested in compiling something to wasm. Thanks for the libvim link! :)

[jnovek]

“We skipped that and haven't implemented any vim backend at all ... so its the vim code base with terminal UI stuff stripped out, and an interface added for us to hook into it.”

You took out the most important part!

I don’t know about other people, but I became a vim user because I found myself configuring servers and needed to know a better text editor than nano.

Vim is also my primary code editor these days but portability is still a killer feature.

[lbotos]

You are mis-interpreting what they did. They literally took vim, and built a ui around it. No re-implementation. It's Vim with a more modern frontend stack. You can go look at the libvim source and see it for yourself.

The point of this is to bring Vim into more modern workflows, not but "vim compat" but literally... vim.

Source: had some pull requests into libvim a while back to remove a lot of the various legacy compat features that don't make sense for libvim.