Switched to a lua setup. Moved from `init.vim` to `init.lua`. Moved to a
lua-based plugin manager (packer.nvim). Moved some plugins to neovim
(i.e. lua) versions instead of vimL (notably fzf and indentLine).
Enabled lsp, treesitter and similar plugins by default.
Modularized plugins a little by invoking them in separate files.
This should provide a base to build on, and allow me to more fully
integrate lua into my workflow.
More detailed changes follow:
nvim: Replace completion-nvim with nvim-compe
Replaced completion-nvim since compe comes with more things working out
of the box (especially buffer completion and treesitter save me two
plugin installations), and seems to be overall a bit better supported.
It's fast, it works well, and I can add custom completion sources so
that should be good enough for me.
Changed around a couple of other things for lsp settings and treesitter,
and moved the files around a bit.
This is somewhat in preparation for a move to a lua-based configuration,
since I have long wanted to make the switch.
nvim: Add treesitter-enabled rainbow brackets
Added rainbow brackets to the editor, using the treesitter AST
detection. I am not sure yet if I will keep them, or if they confuse me
more than they help by coloring *everything* *everywhere* and being a
bit too much for my tired eyes.
nvim: Add vim-terminator to enable repl style dev
Added vim-terminator and included some basic keybindings. The plugin
allows sending code over to a terminal window, or repl for those
languages where it's enabled (python, R, bash somewhat).
The basic workflow for me right now is: From e.g. a python file
1. Open a repl with <leader>rr
2. Send over code with
2a. <leader>rt sending (selected part or whole of) file over
2b. <leader>rd sending (selected part or whole of) delimited area
over
A delimited area in option 2b looks for certain patterns and sends
everything up-to the next instance of that pattern.
Currently, the enabled patterns are `In[n]:` with n being a number,
emulating the way jupyter blocks are coded; and `^```` (three
back-ticks at the beginning of a line), to enable sending code fences
from (R)markdown files.
Since it uses the filetype to determine which repl/interpreter to send
code to, it is still a little unwieldy in markdown files (which in this
editor get handled as `pandoc` filetype.)
FIXME: There are two options going forward, either finding a way to
correctly identify the interpreter without filetype (should be done in
vim-terminator and seems inelegant) or correctly setting the filetype
for code fences in (R)Markdown *only* (seems more feasible and may
already be enabled in RMarkdown plugins for vim).
nvim: Fix simultaneous opening alacritty and nvim
When opening both (e.g. `alacritty -e nvim file`), neovim would open
with the wrong size (usually way smaller than the resulting terminal
size) and stay that way until you resized the terminal window.
This simply sends a 'resize' kill command to vim whenever the user
enters it to circumvent the bug until it's fixed.
nvim: Simplify lua plugin setup, Add indentLine
Added indent line plugin to show where and how indentations occur using
neovims virtual text. Can be toggled with `:IndentBlanklineToggle`.
Simplified lua setup a little by naming settings after intent instead of
per plugin -- everything lsp-y now resides in `lsp.lua`, everything
treesitter in `treesitter.lua`, everything indentation in its respective
file. Should, as long as plugins don't get too many, be perhaps a little
simpler to reason about.
nvim: Switch to packer as plugin manager
Switched to packer -- the plugins move to lua and so will I. Packer
seems basically like `vim-plug` in a dress (which is awesome, since
vim-plug is also awesome!) and it is extremely fast.
So, no real complaints but still a little switch to get that little bit
further away from vimscript.
nvim: Add telescope plugin and configuration
Added telescope as fzf replacement. Fzf served me well, but the
configuration is somewhat difficult (not least owing to the fact it's
written in vimscript), and telescope has a burgeoning ecosystem growing
around it.
I could basically drop-in replace all of my mappings and then some.
Refined some options and changed some defaults and I am fairly happy for
now.
nvim: Switch to zettelkasten plugin over wiki.vim
|
||
|---|---|---|
| .assets | ||
| .githooks | ||
| alacritty/.config/alacritty | ||
| an2linux | ||
| bash | ||
| bibtex | ||
| bootstrap | ||
| disks | ||
| dunst/.config/dunst | ||
| git | ||
| i3/.config/i3 | ||
| mpv | ||
| nvim/.config/nvim | ||
| pass | ||
| picom/.config/picom | ||
| polybar | ||
| qutebrowser | ||
| rofi | ||
| rofi-surfraw/.config/rofi-surfraw | ||
| scripts | ||
| services | ||
| sh | ||
| ssh | ||
| styler | ||
| sxhkd | ||
| taskwarrior/.config | ||
| tmux | ||
| vifm | ||
| X | ||
| zathura/.config/zathura | ||
| zsh | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .gitmodules | ||
| .stowrc | ||
| install.sh | ||
| LICENSE | ||
| README.md | ||
~/🌹
What's in these dotfiles
- vim configuration for simple programming tasks (especially go/typescript/python/bash) and prose
- academic workflow tools, to allow quick citation, pdf compilation, and preview
- simple, efficient polybar with package update notification, and spotify (mpris) integration
- tmux session management through
tmandtltools - tmux fuzzy-searching of terminal sessions to switch to with hot-key (
<C-A><C-s>) in addition to normal session switching - system-wide color management (terminals, vim, qutebrowser, polybar, xresources) through
stylercommand using base16 themes - quick theme switching by activating
stylerand fuzzy-searching themes with hot-key (<Super>+F8) - many vim color-schemes with quick light/dark switching (
F8) and individual theme switch (<Space>+F8) - quick directory jumping using z, with fzf integration
- fzf integrations for bibtex citation, vim buffer management, most recently used switching, shell command history, and more
Quick-Start
The dotfiles use GNU stow to link themselves in the home directory. You can clone this repository anywhere (though I have mine in ~/.dotfiles as it seemed most logical for me).
I would recommend doing a git clone --recursive for this repository, since it contains git submodules, which will then automatically get pulled in as well. Of course, you can do it non-recursively and then just pull those modules selectively which you actually want.
Once in the repository directory, when you then run ./install.sh it will install many of the packages I use (though they are probably slightly out-of-date) and link the dotfiles into the home directory.
If you do not want to install any packages, but only link the dotfiles run stow -S */ from the main repository directory.
Since dotfiles management is based on stow, it will not overwrite anything already in the home directory (though you can force it to if you really want, using stow --override='.*' -- I do not recommend this).
After all files are linked and you open a new shell session, the dotlink alias will allow you to re-link all dotfiles from anywhere on the system.1
Both automatic installation paths are presumably somewhat brittle. In any case, I would suggest to manually look through the files for things you want instead of copying and activating everything. Dotfiles are too personal to be standardized like that. They're pets, not cattle. Enjoy!
Main Modules
alacritty- Terminal emulator (GPU accelerated and customizable)i3- Tiling window managerpolybar- Easy to customize statusbarpicom- X11 compositor (maintained fork from compton)git- distributed version control system.pass- Password management suitenvim- Neovim configurationbibtex- LateX/BibteX/pandoc plaintext writing & reference suitequtebrowser- vim-key enabled web browserrofi- Application launcher, dmenu replacementsxhkd- X11 hotkey managertmux- terminal multiplexervifm- vim-like file-manager
Notes
- Generally, most configuration for applications attempts to follow the XDG specifications, keeping configuration in .config directory and supplementary files in .local/share directory. Over time, I am moving more applications to this standard: it keeps the home directory clean, and the separation of configuration, binaries, and data relatively clear.
.config/shellcontains all the general zsh/bash/sh configuration and environment variables usually contained in.zshrc,.zprofileand similar. It is divided in login shell config (loginrc.d), general shell config (rc.d) and zsh specific (zsh.d). Over time this should be migrated to specificstow'units', but for now here is where it is.- The
zshdirectory contains all setup for the z-shell, my daily work environment. It should not be required for working with any other module but will add additional functionality to many (such as command auto-completion and so on).shsets some base functionality for any shell you may wish to work in. It is, for now, the only module that is required for some other modules to work.2 roficontains additional scripts and a simple theming framework for rofi and should probably be reorganized to put the correct files into the correct directories (per xdg) at some point..local/bininscriptsstowunit contains most executable user scripts. Most of these have been migrated to their corresponding modules (e.g. if a script exclusively targets git functionality, it will live there), some stand-alone scripts remain however..local/share/pandoccontains configuration for academic latex (pandoc, really) writing and is of interest if you want to use this functionality..xinitrcis used for x initialization and program startup. At some point, some of the consistently running applications may be moved to runit as supervised services.- Generally, directories starting with a . are only meaningful for the repository not for the functionality of the machine that these dotfiles are deployed on. That means
.gitlab-ci.yml,.assets/,.stowrcand similar files and directories will not show up in the final deployment in any home directory. Perhaps they should be called dotdot-files since they're the dotfiles for my dotfiles. 🙂 (Also, 'dotfiles'.)
-
This alias only works when the dotfiles are cloned into
~/.dotfiles, mirroring my setup. This is due to a hard-coded cd into this directory. If your dotfiles lie in another directory and you want to use the dotlink alias, simply change the corresponding line inbootstrap/.config/sh/alias.d/dotlink.sh] ↩︎ -
I may remove this requirement in the future to make modules more self-contained. However, relying on some base utility scripts makes it easier to avoid duplicating such functionality for each individual script in other modules. ↩︎


