Two Projectile Defaults Overridden on Purpose
Projectile ships with sensible defaults for switching projects and listing files, and most of my config leaves packages at their defaults unless something specific needed to change.
Projectile ships with sensible defaults for switching projects and listing files, and most of my config leaves packages at their defaults unless something specific needed to change.
Moving a template file from one directory to another shouldn't change what it renders. I moved html.html.twig to templates/layout/html.html.twig for Drupal 11 compatibility, and the rename quietly deleted an AdSense script tag and three Google Fonts links that had nothing to do with the move. Nobody noticed for hours.
My Emacs config loads two separate linter frameworks in the same file, both fully configured, both actually running: flymake and flycheck. They're not doing the same job for different languages, and neither one is dead configuration left over from a migration that didn't finish.
Seven packages in my Emacs config are fetched with package-vc-install instead of the ordinary archive-based use-package foo :ensure t: auto-package-update, powerline, centaur-tabs, lsp-mode, php-mode, dap-mode, and smartparens-mode, each cloned straight from its GitHub repository
Two different lines in my own Emacs config call the exact same function twice, in the exact same file, a few lines apart. Neither one breaks anything. Both are worth understanding, because they demonstrate two different things about what use-package actually guarantees — and neither one is what I assumed before I went looking.
My Emacs config has three completion frameworks installed and configured: auto-complete, company, and corfu. Only two of them are actually doing anything.
The service account this site's automated pipeline runs under, api_publisher, is a small role: a handful of permissions in a YAML file, tracked in sync/ like every other piece of this site's configuration. Reading that file today tells you what it can do.
Ad placements on this site had started looking wrong — not broken, just not deliberate: spots that clearly weren't ones I remembered choosing. My first assumption was that some old ad unit had been dropped into a template years ago and half-forgotten, so I went looking for it in the theme. There's exactly one ad-related line in the entire theme, and it isn't a placement at all:
This site's article pipeline runs unattended from a wrapper shell script, invoking a claude -p session wrapped in timeout to draft and schedule posts. One run, I decided partway through that I didn't like the direction it was taking and killed it — kill <wrapper-pid>, the process I could see in my terminal.
This site runs on a Europe/Warsaw system clock, and its automated article pipeline needed to compute a publish-time window in UTC from a plain local-time string like "2026-08-31 16:00". The obvious tool is GNU date's -u flag, which converts to UTC — except it doesn't do what that sentence implies.