Replacing airline, lualine seems to be a super customizable
statusline plugin.
I yoinked the base config file from the net and modified it to suit my
needs.
This commit adds replacement to airline's bufferline. It provides a
fast, flexible bufferline with a couple big improvements over airline:
1. Fast
2. Sidebar aware (e.x for NERDTree)
3. Buffer management, including grouping (via directory), movement and go-to-buffer
4. A lot of options to customize
5. Optional icon integration
It loses the powerline look, but I'm pretty sure I can get it back if
desired in the future.
Replacing gitgutter, gitsigns appears to be the standard neovim git
integration plugin.
It is _significantly_ faster in responding to file deltas, and plays
really nicely with a lot of other tooling in the neovim ecosystem. It
also appears very customizable.
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.
Paul Stemmet