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.
After switching my namespace separator from "/" to "-" the function,
`alist-get`, clashed (surprise!) with the pre-existing function, `alist-get`. As
I was struggling to debug my broken Emacs (it broke bc Emacs 27 rolled out), and
I changed the module name, "alist", to "al" attempting to defuse the issue.
I created a strangely named Elisp module, >.el, just to appease the CI gods. My
gut tells me that this is a desperate idea and fails the smell test. I'm pretty
eager to pass the linting phase of my Elisp CI, however, and I can always revert
this.
In order for this to scale, I need to solve two things:
1. Ad-hoc ignore fill-column rules for URLs and other exceptions.
2. Run Elisp flychecker without evaluating my Elisp code and firing its
side-effects.
