Question: Will Oni2 have vim plugin support?

[unknownbreaker]

Meaning, can you reuse the plugins that work for Vim8/NeoVim in Oni2?

[bryphe]

Hey @unknownbreaker,

Good question! We're still working through the details (which is why we gloss over it in the README: https://github.com/onivim/oni2#non-goals)

The TL:DR; is that we'll support some subset of Vim/Neovim plugins. That subset is still TBD.

Here's some of the considerations:

• In Oni1 - we tried hard to support the Vim/Neovim plugin model and an external plugin model for a first-class insert mode experience. Trying to support both gave us a crippled experience in some cases (ie, combining completion providers between an omnifunc and an external LSP).
• Onivim2 is owning the 'view layer' - the rendering - and uses Neovim primarily to manage buffers and manipulation of those buffers. This gives us some neat features like smooth-scrolling and minimap, but has consequences in the sort of plugins we can support.

Some types of plugins that will likely work fine with Onivim2:

• Text object plugins (vim-surround, targets.vim, etc)
• Plugins that are primarily Ex commands

Types of plugins that likely won't be supported:

• Syntaxes - we'll be using VSCode / Textmate syntaxes instead
• Themes - we'll be using VSCode themes instead
• Filetype - we'll be using VSCode language plugins
• Completion (omnicompletion) - we'll have a first-class completion experience, powered by the VSCode API
• Insert mode bindings - we'll be provided a first-class insert mode experience, for performance and integration with VSCode APIs.

Some types of plugins that are iffy:

• VCS plugins (ie, vim-fugitive) - the raw commands might be supported, but things like sign column wouldn't be.

Note that in the cases we don't support above in VimL, there tend to be first-class solutions in the VSCode world (the plugin ecosystem is very extensive and mature). In fact, we've even forked VSCode just so that we can run its "extension host" process.

I'd be interested though in cases where there is a gap - where we'd miss functionality with our VSCode-compatibility-approach, and we can work through to figure out the best avenue to preserve it.

[nilsbecker]

From a Vim user's perspective, one pertinent question is: "If I want to try out Oni2, can I use my existing .vimrc with small modifications? Can I write a .vimrc that works for both Oni2 and Vim in case I need Vim on the command line sometimes, and to ease the transition?"

[bryphe]

@nilsbecker - good question!

We would like to support init.vim and .vimrc down the road - the main challenge is testing to ensure a high-quality experience across various configuration settings. There are also some things we likely wouldn't be able to support, although @bfredl and @justinmk have a lot of great things planned in neovim/neovim#9421 that could help us support a broader surface area.

But we'll need to test - with Oni 1, we tried to support too much, and as a result the quality bar lowered. For Onivim 2 - I'd like to support a more minimal subset to start, get to a high quality bar, and incremental support more and more VimL/neovim configuration. We'll likely explore this after our MVP release.

I'm also building up a corpus of configurations for us to test again: https://github.com/onivim/oni2/wiki/VimL-configs#viml-support - feel free to add yours so we can test against it 👍

[eyalk5]

I couldn't add mine (permission problem).
https://github.com/eyalk5/.vim/blob/master/.vimrc

[yatli]

From a Vim user's perspective, one pertinent question is: "If I want to try out Oni2, can I use my existing .vimrc with small modifications? Can I write a .vimrc that works for both Oni2 and Vim in case I need Vim on the command line sometimes, and to ease the transition?"

Actually I'm already having such a compatibility script for dealing with vim/neovim/gvim/neovim-qt/neovim-gtk so I think it can be done the same way with if has('onivim')

[sassanh]

• Onivim2 is owning the 'view layer' - the rendering - and uses Neovim primarily to manage buffers and manipulation of those buffers. This gives us some neat features like smooth-scrolling and minimap, but has consequences in the sort of plugins we can support.

I'm doing same thing here https://github.com/sassanh/qnvim for Qt Creator (using Neovim just for buffer management and manipulation.). I have a big init.vim (~2k lines) with ~160 plugins. I didn't have any problem with my init.vim thought. It worked without any changes, based on my observation rc files don't need to be changed, parts of them simply don't work (for example autocompletions provided by plugins in neovim don't work in Qt Creator) but it's usually as expected (Qt Creator provides better highlighting, auto-completion, etc than any vim plugin out there)

So I guess this is what we should expect:

1. Some plugins work out of the box (surroud, etc)

2. Some may need to use full power Neovim API to work (for example fzf didn't work early days, but now it's working after new features were added in Neovim API and I used those features.)
   These kind of plugins are probably mostly the ones that user can leave without them but "it's good to have" them too.

3. Some plugins just don't make sense to work, and probably won't work silently without causing any errors.
   Users may consider making the definition of these plugins in their rc file conditional so that they don't run in oni2 just for performance purposes (if I'm not using my auto-completion plugin in oni2 there's no need to add .1 second to initialization time and constantly consuming CPU for results that aren't used at all.)

[bryphe]

FYI - I've added a full milestone to investigate VimL configuration / plugin compatibility:

(Updated on the website timeline: https://v2.onivim.io)

[agentofuser]

Adding a vote for Lua support. This OCaml project might help make it possible:

https://github.com/lindig/lua-ml

If that happens, Oni2 would be scriptable with Fennel, a zero-overhead Lisp that compiles to Lua, and that would be just glorious :D

https://oli.me.uk/neovim-configuration-and-plugins-in-fennel-lisp/

[DavidBachmann]

As soon as onivim 2 gets vim-surround and vim-sneak either via vimL plugin or not, this will be my primary editor. I hope this happens soon :)

[jsiebern]

@DavidBachmann Not sure about vim-sneak but I just tried vim-surround and it mostly works.
I just copied the surround.vim file to ~ for testing and added this to the onivim config:

"experimental.viml": [
      "so ~/surround.vim"
]

It throws an error along the way but as far as I can tell 90% of the surround commands work just fine regardless (ysiw] did not work for example).

[nwaywood]

I know onivim has builtin terminal support and fuzzy finding, but I still really hope these plugins will work 🤞

• https://github.com/voldikss/vim-floaterm
• https://github.com/junegunn/fzf.vim

[gordonrust]

Is there any way to load the .vimrc file directly with oni2?? I suppose this was planned. Any update would be most welcome.

[ShalokShalom]

I'd be interested though in cases where there is a gap - where we'd miss functionality with our VSCode-compatibility-approach, and we can work through to figure out the best avenue to preserve it.

Yuescript offers only Vim Support:

https://github.com/pigpigyyy/Yuescript#editor-support

[eyalk11]

I wish the approach of onivim2 would have been: there are many plugins for both VSCode and nvim. Lets just merge those worlds, and provide some basic things. Instead, trying to implement all those features (including those who are in plugins), is just too wide task. Sad that it ended for now.