Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plugins for VSCodeVim #590

Closed
rebornix opened this issue Aug 11, 2016 · 4 comments
Closed

Plugins for VSCodeVim #590

rebornix opened this issue Aug 11, 2016 · 4 comments

Comments

@rebornix
Copy link
Member

We've been asked multiple times about porting Vim's plugins to this Vim extension for Code. It's also the same case for Code's markdown feature as everyone is using Markdown their own way. Currently Code don't have native support for plugins of its extensions, but since it's nodejs, we still have a way to make it a happen.

I have a prototype which simply works locally for Vim plugins and its mechanism is like

  • Vim Plugins for VSCodeVim are written in TS or JS and published by NPM.
  • Users install their favorite plugin to their Vim extension folder by running command npm run install --save vscodevim-surround etc.
  • Users put the extension name in their settings file, for instance, "vim.plugins:": ["surround"].
  • We require users' plugins while activating Vim extensions, like
let  plugin = require("surround");
plugin.apply(plugin, [Actions]);
  • Vim plugin defines specific commands like what we do in VSCodeVim core and inject them to Actions.allActions.

With above workflow in mind, you might already know the most signaficant thing is how we expose our BaseCommand, BaseMovement or Operator types or information to plugin authors. Markdown-it's plugin system is doing good as markdown-it plugins are adding/modifying its rule system, which is just a Regex/Handler pair and has no side effect. IMHO, #520 can help us a lot while exposing Actions to plugins.

Another thing that we need take into consideration is how we install/uninstall/store plugins. In my above prototype workflow, I'm leveraging NPM and putting everything in Vim extension folder. But Code will remove everyhing while updating extensions then ppl have to resinstall their Vim plugins. It's apparently unacceptable.

@rebornix
Copy link
Member Author

@johnfn @jpoon @sectioneight @aminroosta look forward to your options on this.

@johnfn
Copy link
Member

johnfn commented Aug 11, 2016

My thoughts here are:

I think the number of people who will actually write plugins for VSCodeVim is very few. So far, we've only had one request for a plugin (surround.vim) and 0 plugin proposals. I just don't think that Vim plugins will be all that popular - most of them (NERDTree, Taglist, language support, etc) are natively done by VSCode.

Therefore, I am completely fine with allowing plugin authors to simply write their code directly in the VSCodeVim repo and toggle it with a settings.json flag. I don't think we'll ever have enough that this becomes unwieldy. I considered doing a more fully-featured extensions idea like what you're proposing, but I just don't think we'll ever have a large ecosystem to make it worthwhile. In the meantime, we lose nothing by simply merging all proposed plugins directly into master - plus we consolidate efforts, which is a good thing.

Worse comes to worst, we can have a folder extensions/ somewhere in the repo that we aggregate all these extensions.

@johnfn johnfn changed the title Plugins fot VSCodeVim Plugins for VSCodeVim Aug 11, 2016
@ascandella
Copy link
Contributor

+1 to @johnfn -- I can't imagine having more than 3 or 5 full-fledged plugins, and the machinery required to get it right sounds a lot worse than just adding it to core. FWIW I'm a prominent "monorepo" fan, so take my opinion with a grain of salt.

@rebornix
Copy link
Member Author

This has been here for two months and didn't see any request so I'd like to close this first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants