Prefer starting lorri with home-manager.
Note: I could have removed the `systemctl --user start lorri.service` line
before switching to home-manager by calling `systemctl --user enable
lorri.service`. This would have made a symlink in
`~/.config/systemd/user/default.target.wants`.
This does two things:
1. Starts lorri daemon
2. Moves ssh-agent and docker daemon startup calls to ~/.profile
I'm still not entirely sure when ~/.profile is evaluated... I'd like to use
systemd to startup and manage these background services, but I currently don't
have a strong enough desire to do this.
Renaming my mono-repo briefcase.
I first introduced this commit in master, but it introduced a bug where one of
two things would happen:
1. Emacs wouldn't start and would crash X.
2. Emacs would start but my keyboard wouldn't work.
I learned some valuable debugging skills in the process. Here are some of them:
When my keyboard was broken, I wanted to control my computer using my
laptop. Thankfully this is possible by using `x2x`, which forward X events from
the SSH client to the SSH host.
```shell
> # I'm unsure if this is the *exact* command
> ssh -X desktop x2x -west :0.0
```
Git commit-local bisecting. I didn't need to do a `git bisect` because I knew
which commit introduced the bug; it was HEAD, master. But -- as you can see from
the size of this commit -- there are many changes involved. I wanted to binary
search through the changes, so I did the following workflow using `magit`:
- git reset --soft HEAD^
- git stash 1/2 of the files changed
- re-run `nix-env -f ~/briefcase/emacs -i`
- restart X session
- If the problem persists, the bug exists in the non-stashed files. Repeat the
process until you find the bug.
In my case, the bug was pretty benign. Calling `(exwm/switch "Dotfiles")` at the
bottom of `window-manager.el` was failing because "Dotfiles" is the name of a
non-existent workspace; it should've been `(exwm/switch "Briefcase")`.
There may have been more problems. I changed a few other things along the way,
including exposing the env vars BRIEFCASE to `wpcarros-emacs` inside of
`emacs/default.nix`.
The important part is that this was a valuable learning opportunity, and I'm
glad that I'm walking away from the two days of "lost productivity" feeling
actually productive.
I recently changed my hostname for my desktop and laptop from
wpcarro.lon.corp.google.com -> zeno.lon.corp.google.com
wpcarro2 -> seneca
If you're curious, the names Zeno and Seneca come from famous Stoic
philosophers. As you can see from this commit, my configuration depends on the
values of these hostnames.
Immediately impacted:
- .profile
- device.el
Not immediately impacted:
- configs/install
- configs/uninstall
- .ssh/config
- .zshrc*
* As a side note, I should stop supporting ZSH.
Using an .envrc file helps me DRY up some of my configuration. Ideally I should
only need to make changes to the .envrc file and then expect everything to work
as expected. Let's see how that goes.
After some confusion about my `emacsclient` is currently working as
expected. Perhaps it always did. I had `emacs --daemon` in my
`~/.xsessionrc.shared` for awhile, which may have confused
`emacsclient`. Whatever happened, I'm glad it's working now.
Instead of keeping this in my ~/.profile, I'm going to define it in .envrc.
What I still don't know is how functions like `getenv` are supposed to interact
with direnv. I suppose maybe they aren't? Right now, when I call
`(getenv "DOTFILES")` from Emacs, it's `nil`, which I understand. Hopefully the
more I use direnv, the more reasonable expectations I'll have.
Currently paying the price of months of non-diligent git usage.
Here's what has changed.
- Theming support in Gvcci and wpgtk
- Dropping support for i3
- Supporting EXWM
- Many Elisp modules
- Collapsed redundant directories in ./configs
