Marty Oehme
51e0d82ce9
The application autostart takes too long and is more intrusive than anticipated. If I want to use qutebrowser, I can just start qutebrowser on my and don't need to wait for i3 to do it for me --- especially since the starting procedure takes a while and the application starts on the wrong workspace anyways when it autostarts while I change desktops. Spotify is not installed currently and throws an error each time, so that is also not very useful. An option for this to make a return might be as automatically starting systemd services, which quickly switch to the correct workspace when the application actually starts up -- but it is probably not worth the hassle. Lastly, this let's me get rid of a script in the i3 configuration directory, which did not really belong there anyways with the XDG distinction of 'configuration' and 'data'. |
||
---|---|---|
.assets | ||
.githooks | ||
alacritty/.config/alacritty | ||
an2linux | ||
bash | ||
bibtex | ||
bootstrap | ||
dunst/.config/dunst | ||
git | ||
i3/.config/i3 | ||
mpv | ||
nvim/.config/nvim | ||
pass | ||
picom/.config/picom | ||
polybar | ||
qutebrowser | ||
rofi | ||
rofi-surfraw/.config/rofi-surfraw | ||
scripts/.local/bin | ||
services | ||
sh | ||
styler | ||
sxhkd | ||
tmux | ||
vifm | ||
X | ||
zsh | ||
.gitignore | ||
.gitlab-ci.yml | ||
.gitmodules | ||
.stowrc | ||
install.sh | ||
LICENSE | ||
README.md |
dotfiles Read-Me and Roadmap
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
tm
andtl
tools - tmux fuzzy-searching of terminal sessions to switch to with hot-key (
<C-A><C-j>
) - system-wide color management (terminals, vim, qutebrowser, polybar, xresources) through
styler
command using base16 themes - quick theme switching by activating
styler
and 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.
Since it 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).
If you do not want to install any packages, but only link the dotfiles run stow -S */
from the main repository directory.
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)git
- distributed version control system.gopass
- Password management suite, building on (and largely compatible with)pass
for unixi3
- Tiling window managernvim
- Neovim configurationpandoc
- Pandoc plaintext transformation options (mostly latex templates)picom
- X11 compositor (maintained fork from compton)polybar
- Easy to customize statusbarqutebrowser
- 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/shell
contains all the general zsh/bash/sh configuration and environment variables usually contained in.zshrc
,.zprofile
and 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
zsh
directory 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).sh
sets 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 rofi
contains 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/bin
inscripts
stow
unit 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/pandoc
contains configuration for academic latex (pandoc, really) writing and is of interest if you want to use this functionality..xinitrc
is 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/
,.stowrc
and 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 in_bootstrap/.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. ↩︎