Fix repository organization, house cleaning

Added up-to-date install instructions and a simple image to the README.
Added an assets directory to house these things and some notes. Removed
`.gitlab-ci.yml` from being linked to the home directory, it does not
belong there.

README.md

@@ -1,6 +1,5 @@
 # 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
@@ -11,22 +10,26 @@
 * [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
 
+![Overview](_assets/gaps.png)
+
 ## Quick-Start
 
-The dotfiles are based on a bare-repository residing in your home directory. To enable a faster usage of the dotfile git commands, a `dot` command is supplied which mirrors the usual `git` functionality, but solely applies it to your dotfiles.
+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).
 
-To install you need git on your system; to effectively use the dotfiles you should be using zsh (`chsh -s /bin/zsh` to switch your current user to the shell).
+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.
+If you do not want to install any packages but only link the dotfiles run `./_bootstrap/autostow.sh -s`, once again from the main repository directory.
 
-Clone the bare repo, rename it and force a checkout with the following command - **NOTE** this WILL **OVERWRITE YOUR EXISTING FILES**, so have a look at what is contained beforehand.
+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.
-`git clone https://gitlab.com/marty-oehme/dotfiles.git df && cp -rf df/.git ~/.dotfiles && rm -rf df && cd ~ && git --git-dir=$HOME/.dotfiles/ checkout -f master`
+They're pets, not cattle.
-
+Enjoy!
-It will clone your dotfiles into the .dotfiles directory in your home directory and then force a checkout of the current master branch. Open a new terminal window and you should live in the dotfiles.
 
 ## Main Applications
 
 * [`alacritty`](https://github.com/jwilm/alacritty) - Terminal emulator (GPU accelerated and customizable)
-* [`gopass`](https://github.com/gopasspw/gopass) - Password management suite, building on (and largely compatible with) `pass` for unix
+* [`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)
@@ -40,10 +43,12 @@ It will clone your dotfiles into the .dotfiles directory in your home directory
 
 ## Notes
 
-* generally, most configuration for applications follows the XDG specifications, keeping configuration in .config directory and supplementary files in .local/share directory
+* 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/..; it is divided in login shell config (loginrc.d), general shell config (rc.d) and zsh specific (zsh.d)
+* `.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.
-* `.config/rofi` contains additional scripts and a simple theming framework for rofi and should probably be migrated into the correct directories at some point
+* `.config/rofi` contains additional scripts and a simple theming framework for rofi and should probably be migrated into the correct directories at some point.
-* `.local/bin` contains most executable user scripts
+* `.local/bin` in `scripts` `stow` unit contains most executable user scripts.
-* `.local/share/pandoc` contains configuration for academic latex (pandoc, really) writing and is of interest if you want to use this functionality
+* `.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
+* `.xinitrc` is used for x initialization and program startup.
-* `.gitlab-ci.yml` is only used for simple CI code linting and static analysis on gitlab, can be deleted on individual deployments
+* `.gitlab-ci.yml` is only used for simple CI code linting and static analysis on gitlab, can be deleted on individual deployments.
+
+![Gapless](_assets/gapless.png)

_assets/NOTES.md

@@ -0,0 +1,51 @@
+## Unfinished ideas
+
+* Read out tmux session / window / panel names (or, for panels/windows, the names of programs running) and pass them to rofi for it to show them and allow 'tabbing' to them a-la Alt-Tab windows
+
+## Implementables
+
+### styler
+
+* [x] styler should be able to present a list of all installed packages/processors/themes
+* [ ] styler should have an additional display for each application that a theme is available
+* [x] use same style for processors as for packages
+* [x] enable downloading
+  * [x] from github / link > user inputs author/repo and it automatically downloads package/processor (decided by name)
+  * [x] so, `styler download chriskempson/base16-vim` will automatically clone into package directory
+* [x] `styler download marty-oehme/yabam16-vim` will automatically clone into processor directory
+  * [x] `styler download someone/any-string-here` should also automatically download into processor dir, but print a warning
+* [ ] enable suggestion of missing packages when downloading processors
+  * [ ] some processors contain `readonly dependency=("author/package")` format to make sure they run against the right package
+  * [ ] when this is the case and the package does not exist, warn the user or propose to automatically download the package
+* [ ] enable suggestion of processors/packages when running empty download
+  * [ ] `styler download` should suggest some processors to download (i.e. applications), and either suggest packages or make use of the previous suggestion and have them automatically suggested when installing the processor
+* [x] enable switch for theme switching/permanent theming through styler
+  * [x] styler should, by default, only *switch* applications to the new theme but not make the theme default
+  * [x] when invoked with saving switch, the processors should make sure that the theme will be the default theme for the next run of the application
+  * [x] perhaps styler should invoke processors with additional "switch" "save" first variable being passed, which they will use to differentiate
+* [ ] enable shell completion for themes
+* [ ] read configuration from configrc file (containing processors/packages to download, applications to set?)
+* [ ] Bug: duplicate processors mess it up
+* [ ] Find out which *applications* will be styled (perhaps grep comparison of processors/packages and if both have an application name, display this)
+* [ ] Feature: styler processor calling could be extended for a post-hook, which would be run after setting the new themes. So, it could work like `processor variables "switch"`, `processor variables "set"`, `processor variables "post"`, to have these hooks. Hooks could even be extended to switch_pre, switch, switch_post, set_pre, set, set_post; though perhaps YAGNI.
+* [ ] Feature: add `get` option, where you can input an app/processor and it displays its current theme; or do `get` without argument to display it for each app/processor?
+* [ ] a better way to set a processor and package which should target an app
+  * [ ] packages do not know about styler (and shouldn't), processors *do*, processors should carry the information of which packages they can be used for, and should recommend package installation on download
+* [ ] the process workflow/lifecycle:
+  * [ ] styler gathers all processors (with some algorithm deciding which takes precedence for applications)
+  * [ ] the processors carry dependencies on packages, styler ensures these are met
+  * [ ] styler sources the processes and calls, in order
+    * [ ] set_pre   -- called before any process sets themes
+    * [ ] set       -- called for each processor in turn
+    * [ ] set_post  -- called after each processor sets themes
+    * [ ] theme_pre -- called before each processor switches themes
+    * [ ] theme     -- called for each processor in turn
+    * [ ] theme_post-- called after each processor switches themes
+
+### processors
+
+* [x] shell should set shell colors even when invoked through rofi
+  * [x] shell should set it for *all* terminals, not just the one it ran it (through pgrep?)
+* [ ] shell should be able to save the colorscheme permanently
+* [x] qutebrowser should be able to save the colorscheme permanently
+* [x] vim should actually save the colorscheme, not just the name of it?