This commit adds a wrapper api around packer.nvim, allowing callers to
provide hooks into packer's plugin initialization lifecycle.
There are 4 recognized hooks: 'early', 'pre', 'post' and 'late'.
'early' and 'pre' run before any plugins are loaded, with 'early' running
before *any* work has been done, while 'pre' runs just before calling
into packer.
'post' and 'late' are more interesting, as they are guaranteed to run
after all plugins (and their private configs) have fully loaded.
Furthermore, both hooks are provided the active Plugins object as their
first arg, allowing them access to the entire list of plugins and the
api suite of Plugins itself.
This behavior is very similar to vim-plug's plug#begin .. plug#end
fences, but improves on the pattern by:
- Properly handling bootstrap situations (our old setup would require a
restart before everything loaded correctly)
- Async, does not block user activity while loading leading to a
smoother experience
Special care has been taken to detect and handle bootstrap situations,
where if found, we completely defer a lot of activity (and the hooks
'post', 'late') until packer indicates that the entire install workflow
has completed.
-- Usage
The expected usage of this api set si via requiring the module, setting
up your hooks and initializing the module:
```lua
local htable = { early = early_hook, ... }
local plugs = require('psoxizsh.plugins'):setup({ hooks = htable }):init()
```
As a convenience, you may directly call the module with your hooks,
rather than writing out the above:
```
require 'psoxizsh.plugins' { hooks = ... }
```
Plugins also provides several other interesting methods:
- :reload/0 | completely reload plugin configuration, including rerunning
any hooks
- :list/0 | get the list of raw plugin specs that were passed to packer
- :do_hook/1 | request Plugins run @hook 'early' | 'pre' | 'post' | 'late'
- :get/1 | get the spec object for the provided plugin id
- :has/1 | check if the spec contains the provided plugin id
This module bootstraps our plugin manager
It can (and should) be called before any plugins are initialized,
containing only a dependency on system git, for cloning the package
manager locally.
The 'install_path' variable was taken from packer.nvim's documentation
and installs packer as an optional (opt) plugin. This is important for
when we have packer manage itself, as we'll need to:
1. Ensure it's loaded during bootstrap via `packadd packer`
2. Install load hooks on it's various commands + module
These functions are primarily designed for reloading lua modules, and
specifically, lua modules returning some sort of local config object or
function.
Paul Stemmet