chore(build): auto-generate vimdoc

This commit is contained in:
github-actions[bot] 2022-12-23 06:51:44 +00:00
parent c8da1c19e7
commit 040aeb68f1
1 changed files with 26 additions and 26 deletions

View File

@ -116,7 +116,7 @@ PLUGIN SPEC *lazy.nvim-plugin-spec*
│**url** │string? │A custom git url where the plugin is hosted │ │**url** │string? │A custom git url where the plugin is hosted │
│**name** │string? │A custom name for the plugin used for the local plugin directory and as the display name │ │**name** │string? │A custom name for the plugin used for the local plugin directory and as the display name │
│**dev** │boolean? │When true, a local plugin directory will be used instead. See config.dev │ │**dev** │boolean? │When true, a local plugin directory will be used instead. See config.dev │
│**lazy** │boolean? │When true, the plugin will only be loaded when needed. Lazy-loaded plugins are automatically loaded when their lua modules are required, or when one of the laz-loading handlers triggers │ │**lazy** │boolean? │When true, the plugin will only be loaded when needed. Lazy-loaded plugins are automatically loaded when their Lua modules are required, or when one of the lazy-loading handlers triggers │
│**enabled** │boolean? or fun():boolean │When false, or if the function returns false, then this plugin will not be used │ │**enabled** │boolean? or fun():boolean │When false, or if the function returns false, then this plugin will not be used │
│**dependencies**│LazySpec[] │A list of plugin specs that should be loaded when the plugin loads. Dependencies are always lazy-loaded unless specified otherwise │ │**dependencies**│LazySpec[] │A list of plugin specs that should be loaded when the plugin loads. Dependencies are always lazy-loaded unless specified otherwise │
│**init** │fun(LazyPlugin) │init functions are always executed during startup │ │**init** │fun(LazyPlugin) │init functions are always executed during startup │
@ -131,7 +131,7 @@ PLUGIN SPEC *lazy.nvim-plugin-spec*
│**cmd** │string? or string[] │Lazy-load on command │ │**cmd** │string? or string[] │Lazy-load on command │
│**ft** │string? or string[] │Lazy-load on filetype │ │**ft** │string? or string[] │Lazy-load on filetype │
│**keys** │string? or string[] or LazyKeys[] │Lazy-load on key mapping │ │**keys** │string? or string[] or LazyKeys[] │Lazy-load on key mapping │
│**module** │false? │Do not automatically load this lua module when its required somewhere │**module** │false? │Do not automatically load this Lua module when its required somewhere
LAZY LOADING ~ LAZY LOADING ~
@ -526,13 +526,13 @@ revisions. It is recommended to have this file under version control.
If you use your Neovim config on multiple machines, using the lockfile, you can If you use your Neovim config on multiple machines, using the lockfile, you can
ensure that the same version of every plugin is installed. ensure that the same version of every plugin is installed.
On the other machine, you can do `Lazy restore`, to update all your plugins to If you are on another machine, you can do `:Lazy restore`, to update all your
the version from the lockfile plugins to the version from the lockfile.
PERFORMANCE *lazy.nvim-performance* PERFORMANCE *lazy.nvim-performance*
Great care has been taken to make the startup code (`lazy.core`) as efficient Great care has been taken to make the startup code (`lazy.core`) as efficient
as possible. During startup, all lua files used before `VimEnter` or as possible. During startup, all Lua files used before `VimEnter` or
`BufReadPre` are byte-compiled and cached, similar to what impatient.nvim `BufReadPre` are byte-compiled and cached, similar to what impatient.nvim
<https://github.com/lewis6991/impatient.nvim> does. <https://github.com/lewis6991/impatient.nvim> does.
@ -578,7 +578,7 @@ Files from runtime directories are always sourced in alphabetical order.
STRUCTURING YOUR PLUGINS *lazy.nvim-structuring-your-plugins* STRUCTURING YOUR PLUGINS *lazy.nvim-structuring-your-plugins*
Some users may want to split their plugin specs in multiple files. Instead of Some users may want to split their plugin specs in multiple files. Instead of
passing a spec table to `setup()`, you can use a lua module. The specs from the passing a spec table to `setup()`, you can use a Lua module. The specs from the
**module** and any **sub-modules** will be merged together in the final spec, **module** and any **sub-modules** will be merged together in the final spec,
so it is not needed to add `require` calls in your main plugin file to the so it is not needed to add `require` calls in your main plugin file to the
other files. other files.