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.
This commit adds an env var, PSOXIZSH_EXPERIMENTAL_NEOVIM_LUA, that can
be set to opt into using an 'init.lua' based configuration.
This setting only makes sense to use with neovim, and thus even if we do
decide to switch to lua, we'll need to keep the old vimrc config around
for a long time yet, to ensure backwards compatibility
Fix for the warning
```
The `osx` plugin is deprecated and has been renamed to `macos`.
Please update your .zshrc to use the `macos` plugin instead.
```
We now require that a user's local tmux path is ~/.config/tmux.
This is due to failings in how TPM parses tmux config files, namely
that it doesn't expand variables and only looks one level deep for
source-file declarations.
By default we symlink $PSOXIZSH/tmux/tmux.conf to ~/.tmux.conf. Again,
because both TPM and tmux itself have strong (unconfigurable) opinions
about where config files live we'll just have to live with it.
On the upside, this allows us to seperate out different tmux config
'fragments' into files which a user can then include.
By default we symlink in fragment/plugins.conf, but all others are
optional.
- plugins -> $PSOXIZSH/tmux/plugins.conf
- vim integration -> $PSOXIZSH/tmux/fragment/vim-movement.conf
We also allow the user to include personal settings via ~/.config/tmux/{early,late}.conf
which can include any of the fragments we collect!
C
Paul Stemmet
André Stemmet