A couple thoughts:
- Generally, unit tests aren't worth keeping in the same file as the library
- Specifically, *these* unit tests aren't worth keeping
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`.
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.
