Declaring bankruptcy and starting again
-
Org-babel
- One file for emacs config and one file for everything else actually seemed to be a decent way of dividing
-
Using one repository that works for multiple machines (as opposed to previous effort with Git branches)
-
Public on Github instead of private on bitbucket
- Bitbucket's new authentication setup is really cumbersome for something I want to clone quickly on a new system and push changes from.
- I don't really have any secrets in here anyway?
-
Ditch the email stuff. I really did prefer notmuch to webmail, but every other aspect of configuration was too painful to keep up, and most of my accounts use Exchange now :-(
-
Use elisp to conditionally tangle different stuff on different machines. I was finding it a bit tricky to specify the different use-cases / environments in previous hackery, the extra power should be helpful
-
Don't name the setup script setup.py, that was really confusing because of Python conventions
-
Use
stowto distribute files that have system-dependent locations:- org-babel can tangle to a standard tree within a temporary director or this source folder
- then call
stow -t /suitable/root/position [packages]to copy them --dotfilesargument automatically converts "dot-config" to ".config" etc for a nicer tree
-
Use Elpaca instead of package.el
- soooooo much faster
- install unavailable packages by default, if it shouldn't be on this machine then don't configure it (see conditional tangling, above...)
-
It would be really nice if stow could easily be diffed against the current version. Maybe some kind of --dryrun/--diff mode can be added to make.el that handles this. Would need to:
- Copy current stow files to a temporary directory
- Re-stow from the temporary directory
- Tangle files (which is hard-coded to the "main" stow path)
- Diff the temporarary (and still-live) version with the new tangle
- Clean up by deleting the newly-tangled files, moving back the temporary stow tree and re-linking everything to the normal path.
-
That would be made a lot easier by putting all the stow directories under a folder rather than using the main source directory. It also makes it easier to .gitignore them?
-
For i3 I put a few scripts into ~/.local/bin; make sure those are visible. (i.e. add ~/.local/bin to PATH in ~/.profile)
-
./make.elto tangle dotfiles to directories -
stow -t $HOME --dotfiles i3 fish ...to symlink things to ~/.config and ~/.local/bin- Once there are more packages and machines set up, this should be
included in
make.el, fired off by an optional argument.
- Once there are more packages and machines set up, this should be
included in
-
The dotfiles feature is busted on most builds of GNU stow; we can still have dot-filenames but directories need to have the literal dot (and so are hard to list etc.)
I was using a fork to get around this but it was more trouble than it was worth; for now, we use the mainline stow again.
Since stow 2.4 this is fixed, once that has a chance to hit package managers maybe we can use it again :-D
An alpine container is defined for unit testing on Github. It can also be used manually, just follow the same steps as the CI job:
- build image
- run detached container
- archive the project folder and copy it into the container
- attach to container (or run commands with e.g.
podman exec) - extract files, run
./make.elandstow -t $HOME --dotfiles emacs bash ...to install desired features.