zeroknight/dotfiles

Just my dotfiles and other various configs. Nothing to see here.

ZeroKnight's Dotfiles

These are my personal configs, scripts et al. Feel free to prod around and snag anything you happen to find interesting.

This README will at some point contain more information.

dotfiles's Issues

Make `gf` work with Lua package paths

Being able to jump to require'd files would be really nice. Be aware of package.(c)path and runtimepath.

For example, these cases should work:

• zeroknight.config.highlight -> lua/zeroknight/config/highlight.lua
• zeroknight.config -> lua/zeroknight/config.lua
• zeroknight.config -> lua/zeroknight/config/init.lua

Machine-based config system for Awesome setup

Allow certain parameters of Awesome (eg. background, net traffic, etc) to be configurable on a machine basis (ie. config outside of rc.lua).

Create a tmux status-line

Finish ditching powerline's unacceptably slow, resource gobbling, process spamming ass and create my own tmux status-line. Ideally, match the prompt we make in #5.

Add 24-bit color support to [spectrum]

Ideally, some helper functions that take either a hexadecimal parameter, or RGB parameters, e.g. $(fg #00FF00), $(fg 255 255 100), etc.

Intelligently symlink dirs at the deepest level

When symlinking directories, avoid unnecessarily symlinking entire root dotdirs into the dotfiles repo and thus needing to ignore unwanted contents. Instead, symlink only the deepest level directories (ie. no further children), creating parent dirs in $HOME as needed. The idea is to only symlink the absolute required parent directory holding the files desired in the repo. This approach is not only easier to maintain, but more elegant and correct.

Example:

dotfiles/.config:
awesome/ openbox/ sakura/ tint2/

Instead of symlinking dotfiles/.config to ~/.config and creating a mess, symlink each leaf directory, creating the structure to mirror if necessary:

~:
.config -> dotfiles/.config # BAD

~/.config:
awesome -> ../dotfiles/.config/awesome # GOOD
...

Consider switching from vim-plug to packer.nvim

I adore vim-plug, but having since finally started making the conversion to Neovim nightly and all the lua-goodness, packer.nvim also looks to be a very tempting option.

• Commands/Features are nearly identical to vim-plug
• Allows specifying plugin load order
  • This might just be a killer feature since this could avoid issues like Airline recently complaining about not being able to find the one theme
• It's in Lua, so it'll be amazingly fast (not that plug isn't)
  • It has some kind of compilation feature
• Allows specifying dependencies
• Allows running arbitrary configuration, attached to the plugin
  • This is quite nice as it allows everything about the plugin setup to be with the declaration if there's little to do
  • Especially nice for lua plugins, since they almost always require a setup call of sorts
• Can take over the entire setup process if need be

Add and learn to use Leap

Leap seems to be the bleeding edge in the "better movement" paradigm, building off the collective experience and learned-lessons from plugins like EasyMotion, Sneak, Lightspeed, etc. Its design is approached with a very clear philosophy and design goal with a lot of consideration for how its jump points are chosen. If I'm going to pick up a plugin of this class, this should probably be the one.

It also has a companion plugin for f/F/t/T movements: flit.

Add Telescope function to find Neovim logs

Simply opens a file finder on ~/.cache/nvim so I can reference Neovim logs, e.g. lsp.log or null-ls.log.

Add .curlrc

Create generic "programming" snippets

Create a generic programming.snippets file with extremely basic and common snippets with negative priority to allow being overwritten. Some examples:

• C-style Loop and conditionals
  • Compatible with many languages, would save space in other snippet files
• TBD

zsh-syntax-highlighting: unhandled ZLE widget 'send-break; self-insert'

This error is printed when starting a shell. Could it be due to #9? May need to wrap the command in this keybind in a zle widget.

Add play to install kitty from upstream releases

I'd like to always have the latest kitty features, so the usual suspects will generally have far too old of a kitty
version to be acceptable. Thankfully, Kovid provides convenient bundles and an installer for grabbing the latest
release. Instead of installing from repositories on non-rolling distros, install from these instead.

Add task to nvim role to download PowerShell VSCode snippets

Add a task in the nvim ansible role to download the PowerShell VSCode snippets from
upstream and store them
in ~NVIMD/external_snippets/vscode/PowerShell.json

External Modules to Add to Zsh

• Syntax Highlighting
• More Completions
  • Comment: Just did a distro install, no need to make a submodule

Reorganize UltiSnips snippets

Apparently UltiSnips is rather flexible in how it looks for snippets:

Using a strategy similar to how Vim detects |ftplugins|, UltiSnips iterates
over the snippet definition directories looking for files with names of the
following patterns: ft.snippets, ft_*.snippets, or ft/*, where "ft" is the
'filetype' of the current document and "*" is a shell-like wildcard matching
any string including the empty string. The following table shows some typical
snippet filenames and their associated filetype.

    snippet filename         filetype
    ruby.snippets            ruby
    perl.snippets            perl
    c.snippets               c
    c_my.snippets            c
    c/a                      c
    c/b.snippets             c
    all.snippets             *all
    all/a.snippets           *all

It would be a good idea to follow the <ft>/<specfics>.snippets format, especially for sets like Perl where I've made several categories of snippets. For example, I could expand them as such:

UltiSnips
` Perl
  ` base.snippets
  ` moose.snippets
  ` idioms.snippets

Replace null-ls

Since null-ls was sadly—but understandably archived, I should find a replacement since it's likely a matter of time before it stops working. After doing a bit of searching, I could go with one of the following:

1. A community fork, none-ls
2. nvim-lint + formatter
3. nvim-lint + conform
4. efm
5. dls

none-ls would be a drop-in replacement, but I'm not sure if I want to commit to using it without seeing more widespread adoption. Currently, there's only been a handful of commits by a couple of maintainers, which have really only been new builtins.

Both efmls and dls are fine alternatives and both support defining linters/formatters that run in any filetype. However, a bit of a workaround is necessary to actually have them attach to "any" filetype due to the way Neovim works. More specific to my needs, however, is that neither of them support conditionally running formatters, so I wouldn't be able to exclude e.g. diff from having whitespace trimmed. I'd realistically need to do that with an autocmd, but then I'd have to cook up a way to run it and LSP formatting and then it's no longer all done in a single place.

So that leaves nvim-lint and either formatter.nvim or conform.nvim. I used nvim-lint in the past and it does a good enough job; no issues with using it, especially now that there's an nvim API for diagnostics. Thankfully, both support conditionally running formatters:

• formatter.nvim allows defining formatters as functions
• conform.nvim has a condition field that takes a predicate function

As I collected these thoughts and wrote this all out, I pretty much decided on conform as I got to this point. formatter.nvim would be a perfectly acceptable choice, but conform has a killer feature of forcing range format support and calculating the actual formatting patch even for lazy LSPs that just send the whole buffer. Additionally, conform provides a lua interface instead of just user commands, which I appreciate. Conform looks awesome.

Personalize Zsh Configuration

Ditch the slow frameworks loaded with extras that I don't need and/or conflict with my own stuff. Create a "framework" of my own tailor-made to my existing configuration (while lovingly yanking bits and pieces that I like from the frameworks I'm ditching).

Todo

• Load run-help properly
  • Alias to 'help' 'zhelp'
• Set up Completions and zstyles
• Set up input/zle
• Finish importing any last decent bits of frameworks
• Git Git Git
• #6
• Set up Prompt (low load order! will depend on functions from other modules like git)
• Purge all remnants of frameworks

Convert remaining .vim files to Lua as the Neovim API evolves

As the Neovim API evolves and more Vim-only commands gain Lua equivalents, migrate Vim files to Lua.

Waiting On ...

• :command
• :autocmd and :augroup
• Vim function definitions from Lua (may not ever be added)

Remaining Files

• ftplugin/ and after/ftplugin/
• plugin/ and after/plugin
  • autocmds.vim
  • commands.vim
• autoload(?)

Add modules array for load order

Feed the filename generation line module names from a $zmodules array. This allows for:

• Load order determination
• Load control via excluding modules from the array

Load order is important for modules like completion and syntax-highlighting that depend on settings introduced by other modules. This can not be achieved currently, as straight filename generation produces a strictly lexicographical load order. Alternatively, modules could just be named like ##-name similar to some linux rc files, but I don't exactly find this method to be "clean".

Fix Indent Guides color with light background

My indent guides color work great when background=dark, but not so much when background=light as it is too dark and clashes with regular text color. Find a way to switch to a different color on background change.

Current color setting here.

This may be of some use

Improve LSP Server Configuration

My LSP setup works pretty well so far. However, there's still a couple of shortcomings to take care of:

• A way to reload server configuration without restarting Neovim
• Better integrate with mason-lspconfig
• Install neoconf to allow per-project LSP settings

Reloading Server Configuration

It would be nice to—at a minimum—be able to reload lsp/servers.lua and have lspconfig re-ingest the result. Even better would be to (optionally) automatically reload any associated language servers attached to buffers.

Even better still, see how folke implements monitoring for config file changes to implement hot-reloading (e.g. lazy.nvim, neoconf.nvim). That would be cool. NOTE: I may actually get this for free with neoconf.

Mason LSPConfig

Additionally, I should look into perhaps going through mason-lspconfig to set up my servers instead, to take advantage of its compatibility and automatic installation capabilities.

Replace Airline with a new statusline (and tabline)

Airline has served me well enough over the years, but its performance issues are becoming quite grating, specifically how unreasonably long it takes to switch windows of all things. Certain statusline components really slow it down and I can't stand it any longer.

Candidates

I'm torn between several choices, as of course, there isn't one that meets all my desires.

lightline

Language: VimL

• Very responsive out of the box
• Sensible and decent stock configuration
• Intentionally designed without plugin integration, leaving it to the user to customize as they desire
  • Easily and highly customizable
• Built-in theme support
  • Inflexible, however. Colors are only loaded on init and never again, so no background swapping support
    • Could possibly work around it if I can find a way to get it to reload its colors, but this also requires rebinding [ob and ]ob to accomodate the workaround
      • UPDATE: It can be done by re-sourcing the lightline colorscheme file and calling lightline#enable(), which we can trigger on a ColorScheme event
      • Can even auto-set g:lightline.colorscheme to the value of g:colors_name

Thoughts

I honestly would go with lightline as-is despite not being in Lua because it fits what I'm looking for pretty much perfectly. The issue with background swapping is preventing me from pulling the trigger.

galaxyline

Language: Lua

• Extremely customizable, even more so than lightline (arguably the most out of the bunch)
• Provides a nice API for creating a statusline
  • It's actually more intended to be an API than a ready-made statusline, as such there's no default configuration, requiring more work up front
• Extremely fast startup due to being in Lua and also async'd (only around 1ms!)
• No built-in theme support, but allows colors ("highlight") on components to be defined with any arbitrary function
  • So I can acquire/set up my colorscheme colors for both light and dark background and assign a function that will pick from either as appropriate
  • Could also make use of the ColorScheme and ColorSchemePre autocmd events
  • Unfortunately, this means I'll need to configure colors manually for any colorscheme I want to use

Thoughts

So far, I think I will likely be going with this one, as it offers the most customizability short of creating my own from scratch.

lualine

Language: Lua

• Very customizable, on par with lightline
  • Follows Airline's section design (A|B|C X|Y|Z), which is potentially a bit more limiting
• Built-in theme support
  • Fairly limited, and the author seems explicitly against supporting background swapping :(
  • Colors on A, B, and C are mirrored to X, Y, and Z which further limits potential customization. It also makes it difficult to apply coloring to certain elements
• Very much ready to go out of the box
• Still a bit young currently; API seems to be in flux and not fully realized yet

Thoughts

A very good choice but definitely less flexible, and the issues with theming put me off of this one. I don't think I'll be going with this one; might be worth revisting in the future.

My own statusline

Language: Lua?

• Can add whatever feature I want
• As light as possible, as it will only include what I want
• Will probably end up taking more time to set up
• A good learning experience

Thoughts

Technically the ideal choice, but requires the most effort. The only drawback is time.

Switch to NeoVim

The Big Picture

NeoVim has matured a fair deal, and it may be a good time to switch. However, there are concerns that need research:

• Is there still a reason to switch now that Bram has picked up the pace with Vim development?
  • Vim recently added quite a few features that nVim brought to the table. Is there still enough perks that warrant switching?
    • Nah.
  • Yes, the fact that 24-bit color doesn't work properly and relies on assumptions regarding xterm, along with various long-standing bugs and legacy code leaves me to prefer NeoVim despite this.
• Will I be able to continue using the plugins I care most about, or will I be able to replace them?
  • One plugin that comes to mind is YCM, though apparently deoplete/deoplete-clang are good alternatives and may be worth looking in to
  • Losing some lesser-used plugins would not be the end of the world

Some nice things to note:

• Truecolor that supposedly JustWorks™ Relevant: d85a822
  • It does.
• Much better plugin support (that async...)
• Not sure if the built-in terminal thing is a plus...would it be useful even having tmux?
  • Useful when not in tmux for some reason, be it lack of availability or forgetting to attach

Plan of Action

• Start with #16
• Ensure that both Vim and NeoVim will run properly with the new configs
• For each plugin, either verify that it works with NeoVim, find a replacement, or get rid of it
• :CheckHealth

Make sure these Zsh options are set

Completion

• auto_param_(slash|keys)
• complete_in_word (and always_to_end)

Consider using `vivid` instead of `dircolors`

vivid is a neat looking project that aims to simplify creation of LS_COLORS by generating it based off of a YAML file. These YAML files are defined per colorscheme, so the resultant dircolors could match the rest of the environment.

Vivid is fundamentally different from the crowd-sourced LS_COLORS that I am currently using in that vivid intends to match a colorscheme while the latter is curated to specific colors that don't follow a particular colorscheme (as far as I know). Without customizations, I would likely be trading color diversity for uniformity.

Also, at the time of opening this issue, there is not a theme available for Tokyo Night, so I'd have to do that myself.

Break up git config

As of Git 1.7.10, it is possible to "include" other files. It would be a good idea to leverage this along with either a conditional deployment in Ansible or a Debian-style config-available directory with symlinks. Git will silently ignore "missing" include files, so the latter approach should work well.

In addition to being an opportunity for organization, a particular pain point has been using my git config on other machines that are missing delta and consequently being unable to use git log, git blame, git diff, etc.

Running `nvim_rebuild` playbook by itself is broken

When I moved the variables to roles/nvim/defaults, this broke the nvim_rebuild playbook, as it no longer sees these variables. Figure out the proper way to go about this.

Replace UltiSnips with a Lua alternative

UltiSnips has served me very well over the years, but like everything else, I want to take advantage of Lua in this area. However, the replacement should be able to do, at a minimum, everything my current snippets can do and at least as much as the less esoteric features that UltiSnips offers.

Implement configuration management (e.g. Ansible)

Learn me a config management. Will work far better and require far less effort than rolling some jank install script.

Use nvim 0.7 `vim.keymap` API instead of custom `zeroknight.util.key`

One of the new features in 0.7 is the addition of the vim.keymap API (see 16591), which provides a nicer interface than the lower level nvim_(buf_)set_keymap function. Notably, this API takes advantage of being able to pass arbitrary Lua functions to mappings which was added somewhat recently; now I don't need to hack this in myself. It also supports mapping multiple modes at once and defaults to applying nvim_replace_termcodes which is great.

Other than having the short "sugar" methods like key.nnoremap there's not really any reason to keep these around now, especially when we can map multiple modes at once; the new API completely obviates the need for util.key.

Alpha "Load Session" mapping gets applied to argv file

Specifying a file to open when running neovim causes the Alpha "Load Session" mapping to apply to that file rather than the Alpha buffer.

Remove old stuff

• Openbox, tint2, etc. — Haven't used it in years and don't plan to go back.
  • Archive compton just in case I can use it with awesome
• TODO — Been using Github Issues for a while now
• installer.sh — Haven't used this in ages, and redesign has been shelved
• conky — Pretty sure this is a near-default config that I played with once and forgot about
• Update the Readme

Disable Indent Guides ONLY for man pages

When using :Man, the autocmd that controls formatting and disables Indent Guides ends up disabling them for all buffers. Do this locally.

Create mapping or function that wraps at a configurable `textwidth`

The idea is that this would be mostly for comments and docstrings, but might have other uses.

Notes

Setting width:

• Supplying [count] gives an explicit width
• Buffer-local width via b:aux_textwidth
• Global width via g:aux_textwidth

Map to something like gQ<motion>

Refactor Vimfiles

Over time, my initial vimfiles layout has proven insufficiently split in some cases, and unnecessarily redundant in others. Now that I'm switching to NeoVim, this is a good time for a refactor.

config.vim ✔️

Consider simply moving this to .vimrc/init.vim since as of right now that file delegates everything and lacks any real substance of its own. However, keeping it separate does allow is to source config changes without invariably re-sourcing every other file.

Reorganize and reformat. The "sections" in general look pretty ugly. Go over all settings and refine anything as necessary, e.g. new characters for listchars, etc.

plugins.vim

• Switch to vim-plug
• Merge Vundle.vim and plugins.vim
• For each plugin, either verify that it works with NeoVim, find a replacement, or get rid of it
• Reorganize sections
• Cherry pick snippets from vim-snippets
• Replace CtrlP with something... probably unite or fzf

The man plugin may prove a bit tricky. We definitely want to keep it for the extra functionality that it provides vanilla Vim, and it has a few features not present in Neovim's man plugin (e.g. [[ and ]]). We could probably abuse has and assorted trickery for Vim:

if !has('nvim')
  Plug 'bruno-/vim-man'
endif

And for porting the extra features to Neovim, we could just throw them in $VIMFILES/ftplugin/man.vim or wherever. Also, make sure we address this for any other plugins if necessary.=

functions.vim ✔️

Implement functions as autoload functions for efficiency and organization; like functions can go in their own scope.

See also...

autocmds.vim ✔️

Implement the various filetype-related autocmds properly as ftplugin configs, e.g. helps q mapping...

platform.vim ✔️

Not sure on this one, as I don't use Vim in Windows anymore. Look into how NeoVim runs on Windows...we may not have tmux, but at least NeoVim has the built-in terminals.

Either way, it should be refined or removed.

Perhaps we'll need different settings on BSD? There's no has()-friendly way that I know of the check for BSD, so if we ever do, it'll have to be done in a more hacky way, probably via system('uname').

Everything else

• #14 Could be done
• expand() all instances of $VIM* variables in configs. This way we can—for whatever reason—modify them on the fly by changing the environment we run (n)vim in. Implemented with s:SetDefault() function
• Make sure anything that Neovim sets by default now is still set in .vimrc (e.g. encoding)

Switch from YCM to NCM

It would probably be a good thing to switch to NCM; it has quite a few neat features that YCM lacks (though the reverse is also true for a few things).

A few highlights (see Evernote for deeper analysis):

• Runs completion sources in parallel
• Scoping, basically "smart completion"; allow multiple filetype completion sources at once (e.g. CSS completion in an HTML <style> tag)
• Has a LOT of sources available, including ones from deoplete, and creating sources seems to be less involved than YCM

Overall, NCM is lighter, less complex and likely to be faster than YCM. Also, no compiled component to worry about when updating.

Switch from lexima to nvim-autopairs

All aboard the Lua train! 🚂

nvim-autopairs looks to be more flexible than lexima and tries to integrate with Treesitter, which would hopefully solve some of my indent-related annoyances with lexima.

Switch from nvim-compe to nvim-cmp

nvim-compe was deprecated some time ago and we should stop being lazy about it, especially since TJ has a nice video about it.

https://github.com/hrsh7th/nvim-cmp

Add DAP plugins to Neovim

DAP is to debugging as LSP is to language tools. I should look into this and start using it if/when it takes off. The backbone support can be added via nvim-dap.