libvim

You mentioned elsewhere that VIM bindings are upcoming. I think this product will be an insta-buy for me once there're (reasonably proper) vim bindings. Is there a newsletter or something to know once this feature has landed? Also as a hint, before you try to re-implement 30 years of VIM bindings and end up with something where everybody misses something, there's a great C library that could be of help: https://github.com/onivim/libvim

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...

> 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 requi

> 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 d

No, it is actually using the real vim in the background. So while you might not be able to use all vim plugins/scripts, it should give you a much more complete vim experience. See also https://github.com/onivim/libvim

It's not that cut and dry. See https://github.com/onivim/libvim#why-is-libvim-based-on-vim-... It's mostly due to their build system.

I think perhaps libvim is like that? https://github.com/onivim/libvim

Onivim might not be for you :) But our project under the hood, libvim [1], might be useful for you to start (if it's easy to create bindings from C in Go). There's a cool non-Onivim usage of it called Paravim [2] (and the same author also used it for Vim-Cubed [3]) - [1] https://github.com/onivim/libvim/blob/master/src/libvim.h - [2] https://github.com/paranim/paravim - [3] https://github.com/oakes/vim_cubed

Thanks for checking out the project! This is one of the biggest pieces feedback we've received both the tabs / splits in particular [1], and the more general issue of broader Vim compatibility [2]. We actually use a forked Vim implementation under the hood (libvim [3]) - as the modal-editing engine. So Onivim, in theory, _could_ support everything. The main issue is 'wiring up' features from libvim to our front-end. We'll be focusing on this in our next milestone (July-Sep) - with the high level goals of supporting more traditional Vim workflows, Vim tab support, along with VimL plugin support and init.vim/vimrc compatibility. Ultimately it's a prioritization problem - so having feedback like yours is really helpful, so that we can focus on the right priorities for that work. - [1] https://github.com/onivim/oni2/issues/592 - [2] https://g

https://github.com/onivim/libvim#why-is-libvim-based-on-vim-... Guts of it is that Neovim didn't play nicely with their OCaml build and Vim did. Rather than invest time in working through the problem, they went ahead with Vim but remain open to supporting Neovim.

Vim support is still pretty meh, though better than some others. The onivim guys are still plugging away at libvim [0], and I'm really hoping once it's stable, someone integrates it with vscode and other editors. [0]: https://github.com/onivim/libvim