I was tired of using `arandr` to manually configure my monitor positions, so I
encoded the settings in Elisp in the `display.el` module.
TL;DR:
- Drop support for `position` kwarg in `display-register` macro
- Support `coords` kwarg in `display-register`.
- `defconst` the `xrandr` arguments and command in `display-register`.
- Define `display-arrangement` macro that consumes the `xrandr` arguments that
`display-register` defines to create an interactive function,
`display-arrange-<NAME>`, which -- when invoked -- runs one xrandr command to
configure a display "arrangement".
My newly minted macro for defining monitors introduced two bugs:
1. Laptop defined its position in terms of 4k-horizontal and 4k-horizontal
defined its position in terms of laptop, I introduced a circular dependency.
2. The identifier, `laptop-monitor`, which `window-manager.el` depends on, is
now defined as `laptop`.
A friendly reminder to myself to always test new Emacs builds to make sure that
everything can initialize properly. This is something that my CI should be
automating, but ever since I moved flats, I lost my CI and need to restore it.
This is another reminder to drop into a TTY when Emacs fails to initialize, run
`nix-env --rollback`, then attempt to restart X. But this time, debugging this
entirely from a TTY wasn't so disappointing.
I recently acquired a new monitor, which I'm orienting vertically for logs,
chats, etc. As such I needed to add more functions, KBDs to wrangle the
setup. To DRY up my code, I define a macro, `display-register`, as a DSL for
supporting new monitors. This:
- defines two functions for enabling and disabling the displays
- defines a constant, `display-<name>`
It's basically just a wrapper around `xrandr`, and that's good enough for now.
Today when I opened my laptop, I wasn't sure if it was powered off or on because
the display was blank. Thankfully the volume was muted and the LED indicator was
on, which informed me that the laptop was powered on. This saved me from
unnecessarily rebooting.
What happened was that last night I was working from home and using my external
monitor. Usually I enable my external display and disable my laptop display. But
when I left for work this morning, I unplugged the HDMI cable from my laptop
without disabling the external display or enabling the laptop display.
I noticed a XF86 button on my laptop entitled XF86Display. I figured that this
could be a nice place to bind a key to toggle my laptop display on or off. At
the last minute, I had the idea to just cycle through all possible display
configurations that I use; there are only three anyways. When dealing with more
than two states, I realized I should use a cycle to model the configuration
states. Now I'm thinking that I should be using cycles to model toggles as well
- instead of just using a top-level variable that I `setq` over. I haven't
refactored existing toggles to be cycles, but I am excited about this new
keybinding.
This commit additionally:
- Moves keybindings out of display.el and into keybindings.el
- Conditionally sets KBDs if using work laptop
Currently, after I connect my monitor to my laptop, I run `display/enable-4k`,
which will use `xrandr` to enable the display. The scaling of the enabled
display is not what I expect. So I've habituated re-running the same function,
`display/enable-4k`, which scales the display and meets my expectations.
What's strange is that if instead of running `display/enable-4k` the first time
from Emacs, I call `xrandr ...` from a terminal, this enables the display and
scales it properly on the first invocation.
I'm unsure how to explain this behavior. It's possible that a environment
variable is set properly in the terminal that isn't set in my Emacs, but this is
just a guess.
I'm going to using a different invocation in display.el that explicitly passes
the monitors dimensions. Let's see if that works.
