Marty Oehme
cb5f09c414
Script can be used in a statusbar or otherwise and will return the currently active sxhkd mode. Look into the README for further explanation.
70 lines
6.4 KiB
Markdown
70 lines
6.4 KiB
Markdown
# dotfiles Read-Me and Roadmap
|
|
|
|
## What's in these dotfiles
|
|
|
|
* [x] vim configuration for simple programming tasks (especially go/typescript/python/bash) and prose
|
|
* [x] academic workflow tools, to allow quick citation, pdf compilation, and preview
|
|
* [x] simple, efficient polybar with package update notification, and spotify (mpris) integration
|
|
* [x] tmux session management through `tm` and `tl` tools
|
|
* [x] tmux fuzzy-searching of terminal sessions to switch to with hot-key (`<C-A><C-j>`)
|
|
* [x] system-wide color management (terminals, vim, qutebrowser, polybar, xresources) through `styler` command using [base16](http://chriskempson.com/projects/base16/) themes
|
|
* [x] quick theme switching by activating `styler` and fuzzy-searching themes with hot-key (`<Super>+F8`)
|
|
* [x] many vim color-schemes with quick light/dark switching (`F8`) and individual theme switch (`<Space>+F8`)
|
|
* [x] quick directory jumping using z, with fzf integration
|
|
* [x] 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](https://nering.dev/2016/git-submodules-vs-subtrees/), 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]
|
|
|
|
[^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/dotlink.sh`]
|
|
|
|
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`](https://github.com/jwilm/alacritty) - Terminal emulator (GPU accelerated and customizable)
|
|
* [`git`](git/README.md) - distributed version control system.
|
|
* [`gopass`](https://github.com/gopasspw/gopass) - Password management suite, building on (and largely compatible with)
|
|
`pass` for unix
|
|
* [`i3`](https://i3wm.org/) - Tiling window manager
|
|
* [`nvim`](https://neovim.io/) - Neovim configuration
|
|
* [`pandoc`](https://pandoc.org) - Pandoc plaintext transformation options (mostly latex templates)
|
|
* [`picom`](https://github.com/yshui/picom) - X11 compositor (maintained fork from compton)
|
|
* [`polybar`](polybar/README.md) - Easy to customize statusbar
|
|
* [`qutebrowser`](https://github.com/qutebrowser/qutebrowser) - vim-key enabled web browser
|
|
* [`rofi`](https://github.com/davatorium/rofi) - Application launcher, dmenu replacement
|
|
* [`sxhkd`](sxhkd/README.md) - X11 hotkey manager
|
|
* [`tmux`](https://github.com/tmux/tmux/) - terminal multiplexer
|
|
* [`vifm`](https://github.com/vifm/vifm) - 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 specific `stow` '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.[^shreq]
|
|
* `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` in `scripts` `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'.)
|
|
|
|
[^shreq]: 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.
|
|
|
|
|