This plugin replaces the functionality of nerdtree, providing a much
smoother experience.
It also comes with a bunch new features:
- Floating window support
- Vastly more configurable
- Icon support
- Intelligent file grouping / hiding
- Faster responses to filesystem events
Minus a lot of old of the old conditional code around vim/neovim
differences.
This commit also removes some of the default plugin list. Replacements
will be added in the following commits.
- scrooloose/vim-statline
| 12 years old doesn't seem to have an effect
- vim-airline/vim-airline-themes
vim-airline/vim-airline
| Throwing all sorts of errors when loaded by packer. Not sure what is
wrong, but I think it's just incompatible.
- airblade/vim-gitgutter
| Nothing wrong with gitgutter, but it appears that a lot of the nvim
world uses (and more importantly, integrates with) gitsigns. It's also
a lot faster.
- scrooloose/nerdtree
Xuyuanp/nerdtree-git-plugin
| Again, nothing really wrong with nerdtree, but there are better
options in neovim land (neo-tree.nvim)
I couldn't find any nice, easy to use library or package for interacting
with autocmds from lua, and neovim has only in a very recent version
(0.7) added support for them through the vim.api object.
This commit adds a small module that provides an ergonomic api for
interacting with them in lua.
First import the module
local au = 'psoxizsh.autocmd'
Then you can create grouped autocmds in a variety of ways, several of
which are shown below.
```lua
-- Invoke the group, and add { events, patterns, command } triples
au.Example1 {
-- String commands are interpreted as vimscript to be executed
{ 'FileType', 'lua', 'echo "Hello from a lua file!"' }
-- Or you can provide a lua function instead
{ 'FileType', { 'yaml', 'yml' }, function() print('hello from a yaml file!') end }
}
```
```lua
-- Or pass a function that takes the group as an arg
au.Example2(function(grp)
-- And add the { patterns, command } tuple for each cmd
grp.FileType { '*.md', 'MarkdownTidy' }
grp.User { 'LSPError', 'messages' }
end)
```
This commit adds packer to it's list of managed plugins, taking over
from the bootstrap install.
Notably, we ensure that it knows where to find itself (opt = true), and
take care to ensure that it will be loaded on require or command.
This commit adds an empty plugin set, along with functionality to
extend it via a list of extra plugin specs.
No attempt is made to deduplicate items in this list, though packer may
handle this itself.
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