I want to couple my EXWM workspaces with monitors. E.g. - I'd like my "Chatter"
workspace to prefer my `4k-vertical`. This change supports that.
I also did a small amount of formatting, which I don't think belongs in a
separate commit.
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.
My modeline was displaying the local time (not UTC time) and appending the UTC
timezone offset, which was confusing me.
When it was `00:03` in London, my modeline would read `00:03+01`. One way of
interpreting this is that it's `00:03` in London and the `+01` is a reminder
that I'm one hour ahead of UTC. However, I was reading it as though it was
`00:03` UTC and thus `01:03` in London.
I had to set `display-time-string-forms` instead of `display-time-string` to
pass the `t` argument to the `ZONE` parameter to indicate that I'd prefer to use
UTC time and not local time when expanding the variables.
My custom language settings conflict with Google-Emacs's language settings, and
I'm not interested in finding a more harmonious solution. For now, I'm dropping
my settings altogether in favor of Google-Emacs's settings.
After ~1-2 hours of debugging, I realized that locally I was reading from .envrc
but when Emacs initializes, it is not reading from .envrc. I don't know how to
ideally handle this, so for now I'm including GOOGLE_BRIEFCASE as an environment
variable and moving on with my life.
I was previously relying on the variable `server-process` being set, but this
only resulted in false-negatives and broken initializations. This should make my
Emacs initialization more stable.
In the past I used `defconst` in many of my Elisp libraries where I should've
used something like:
```elisp
;; some/path/to/some-lib.el
(defgroup some-lib nil)
(defcustom some-lib-setting nil
:group 'some-lib)
```
When I encounter code that I should've structured this way, I'm cleaning it up
to prefer this more idiomatic pattern.
While attempting to debug why pressing `C-s-s` from an X-window screenshots my
entire screen, I switched from `call-process` to `make-process`, which is
async.
I still haven't debugged the original issue, but I think this is an improvement
regardless.
Since I'm calling `(require 'general)` in `wpc-package.el`, which gets called at
the beginning of my `init.el` file, all sub-modules have `general`. I originally
wanted this, but I'm beginning to rethink that preference.
After `script.el` broke my CI because of a missing `general` dependency, I'm
fixing it for `buffer.el` and all other modules that consume `general`.
Since script.el depends on buffer.el now, buffer.el fails to evaluate because of
a missing dependency on ts.el.
Blindspots like this make me want to eventually support testing individual loads
of each of the libraries in my .emacs.d/wpc directory.
TL;DR:
- Remove `require` statements from init.el
- Remove unused, auto-install KBDs for bookmark.el
- Remove unused `require` statements from clipboard
- Remove unused, commented-out code
I would like for an Elisp linting stage to test for unused `require` statements,
but I'm unsure how practical that is to support.
Here's what happened:
My `emacs.glinux` derivation relies on gLinux `/usr/bin/emacs`, and Google
recently published version 27, so all corporate machines (i.e. this laptop)
switched from Emacs 26 to Emacs 27 overnight.
However, my Nix derivation was building all of the packages for Emacs 26, so
some packages were compatible while others weren't.
The Elisp package, `emr`, doesn't build for version 27, so I dropped it
altogether.
