My personal configuration files.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Marty Oehme 72af217e8c
vidl: Enable automatic chapter embedding
2 weeks ago
.assets Switch to wayland 2 years ago
.githooks bootstrap: Split packages into stable and testing lists 5 months ago
bootstrap bootstrap: Disable system USB mouse wakeups 3 months ago
desktop waybar: Fix remaining status bar icons 2 weeks ago
disks disks: Fix udiskie service config file sourcing 3 years ago
git git: Add sendmail configuration 6 months ago
multimedia mpv: Update gui interface 2 weeks ago
nvim/.config nvim: Remove automatic full-text completion 2 weeks ago
office neomutt: Update macro key maps 2 weeks ago
pass pass: Update pass-pick pointer 1 year ago
qutebrowser qutebrowser: Add URL rewriting for scribe redirects 2 weeks ago
scripts vidl: Enable automatic chapter embedding 2 weeks ago
services services: Remove deprecated X services 5 months ago
sh sh: Simple pseudo-fix for missing xdg symlink 3 months ago
social/.config newsboat: Implement half-page up/down mappings 2 weeks ago
ssh ssh: Add host fingerprint matching 1 year ago
terminal wezterm: Refactor and format 2 weeks ago
writing papis: Change notes to markdown, add ee library 3 months ago
.gitignore task: Integrate into office module 6 months ago
.gitlab-ci.yml repo: Update linting for 4-spaced shell scripts 2 years ago
.gitmodules scripts: Change nxsiv-rifle to uoeia 5 months ago
.stowrc stow: Remove readme symlinking 3 years ago
LICENSE LICENSE: Fast forward four years 5 months ago styler: Remove from repo 3 months ago bootstrap: Fix initial package installation to work 5 months ago


Note that the below screenshots still show the X configuration from v0.1 which is very old by now. The current dotfiles are geared toward wayland for which the setup looks similar but not identical to the previews below.

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 waybar with package update notification, and spotify (mpris) integration
  • tmux session management through tm and tl tools
  • 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 flavours application using base16 themes
  • quick theme switching by activating flavours and fuzzy-searching themes with hot-key (default <Super>=<Shift>+S)
  • 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-like integrations for bibtex citation, vim buffer management, most recently used switching, shell command history, and more

Styler recoloring demo


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 an initial 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 ./ 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. I would mostly recommend this on fresh machines or a test machine first - it will link my personal dotfiles and, if you allow it, will install quite a few packages. By default it will ask your consent for some steps -- use ./ -f to force yes to everything.

The dotfile installation procedure 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).

NOTE The same non-destructive installation procedure does not apply to the package installation and system setting file linking, where it can potentially overwrite or remove existing files.

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

Overview - an older image of the dotfile desktop with gaps, showing git logs, styler logs, duckduckgo in a browser, and a vifm view of the dotfiles themselves

  • wayland - Containing basics for fully functional tiling wayland setup:
    • river - Tiling window manager for wayland
    • waybar - Easily customizable statusbar for wayland
    • bemenu - Extended dmenu replacement for wayland, X11 and ncurses
    • [fontconfig] - System-wide font replacements and styling settings
  • wezterm - Terminal emulator (fast, understandable and lua configurable)
  • tmux - terminal multiplexer (slowly migrating away in favor of wezterm)
  • nvim - Neovim configuration
  • vifm - vim-like file-manager
  • qutebrowser - vim-key enabled web browser
  • pass - Password management suite
  • bibtex - LateX/BibteX/pandoc plaintext writing & reference suite
  • git - distributed version control system.
  • office - office/productivity software for writing e-mail and setting appointments


  • 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.
  • 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.
  • Whereas sh module scripts are requirements for other scripts, .local/bin in the scripts module contains most executable user scripts. Most of these have been migrated to other corresponding modules (e.g. if a script exclusively targets git functionality, it will live there), some useful --- or left-over --- stand-alone scripts remain however.
  • .local/share/pandoc contains configuration for academic latex writing (pandoc, really) 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 systemd/runit as supervised services.
  • Generally, top-level 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'.)

Gapless - the same image as above, only displayed without gaps

  1. 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/]

  2. 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.