Skip to content

VimL configs

Bryan Phelps edited this page Jul 4, 2019 · 4 revisions

VimL support

At the moment, this is brainstorming - but we're open to feedback.

We believe that the work Microsoft has done in VSCode, and the adoption of their plugin model / ecosystem, has brought a set of very high quality plugins for working with languages. However, we recognize that there is some functionality in Vim that simply isn't captured or part of that effort.

VimL configurations (init.vim, vimrc, etc)

The extent of VimL / init.vim / vimrc support is still TBD - but I'd like to collect a set of configurations for us to test against once we get to that point.

Ideally - we could seamlessly support both init.vim and VSCode configuration files (even together!). The tricky aspect is that Onivim 2 owns some pieces of the editor stack that traditionally Vim would own - like the view / windowing layer. Supporting the breadth of configuration options and, importantly, ensuring a high-quality experience means a lot of testing.

The challenge is figuring out the right set of features to support to ensure a high-quality bar. This is still an open issue; but we're open to feedback and ideas.

Some things we for-sure want to support:

  • Key bindings (map family)
  • Abbreviations (abbrev family)
  • Custom textobjects
  • Vim settings (relativenumber, etc) - these should integrate with the UI.

We may at some point expose an 'experimental-use-at-your-own-risk' configuration setting to bring in init.vim, as well.

Configs for us to track compatibility - feel free to add yours!

VimL Plugin support

Even though we are implementing first-class support for the VSCode Extension Host Protocol as a priority, the fact remains that there are some capabilities of Vim that aren't expressed in that protocol.

Some target plugins we'd like to support:

And then some plugins we likely won't target supporting:

  • ALE - the linter / LSP functionality would be handled by Onivim 2's VSCode extension host integration.
  • coc.nvim - the LSP support would be handled by Onivim 2's VSCode extension host integration.
  • Vim colorschemes (we'll support VSCode Color Themes instead, which also specify theming UI elements)
  • Vim syntax highlighting (we'll support Textmate Themes and maybe Tree-Sitter down the road)

VimL extensions

If there are users or VimL developers interested in leveraging some of the VSCode Extension Protocol support from VimL plugins, we could consider adding extensions to support this.

Let us know if you have ideas by opening an issue - your feedback will help shape what we end up building!

Clone this wiki locally
You can’t perform that action at this time.