|
|
|
@ -644,6 +644,7 @@ Each plugin supports a several properties, all except `name` are optional: |
|
|
|
* `provider`: a list of vim providers (e.g., 'python3') that must be present |
|
|
|
* `binary`: a list of executables that must be available on your path |
|
|
|
* `plugin`: a list of other plugins that must have been successfully initialized |
|
|
|
* `virtual`: do not register with vim-plug |
|
|
|
* `config`: passed through to the plugin itself as configuration |
|
|
|
* `keys`: a list of key mappings in the format expected by the keymap module |
|
|
|
(see |NukeVimModuleKeymap|) that should be registered if this plugin is enabled |
|
|
|
@ -658,6 +659,15 @@ should allow NukeVim to simply adapt to whatever is available at the time. If |
|
|
|
any expected functionality is missing, running `:checkhealth nukevim` should |
|
|
|
report why a plugin wasn't loaded under the plugin module section. |
|
|
|
|
|
|
|
"virtual" plugins interact with both of these systems. The primary intention is |
|
|
|
to allow for the quick and easy creation and inclusion of built-in lua plugins |
|
|
|
which have no corresponding plugin to load via vim-plug. By setting a plugin as |
|
|
|
`virtual`, it will not be registered with `vim-plug` but in all other ways will |
|
|
|
be treated as a plugin--including loading an appropriately named lua file from |
|
|
|
the `lua/plugins/` folder. I cannot see the use-case, but a virtual plugin |
|
|
|
would also satisfy a dependency declared in the `requires` section of any other |
|
|
|
plugin. |
|
|
|
|
|
|
|
|
|
|
|
-------------------------------------------------------------------------------- |
|
|
|
5.5 Settings *NukeVimModuleSettings* |
|
|
|
|
