Three packages in this Emacs config are installed the same way: skip the archive-based package manager, fetch straight from GitHub with package-vc-install, and guard the call so it only ever runs once. The same guard pattern, copy-pasted for a third package, checked the wrong directory — and for eight weeks, the guard's own logic guaranteed it would never actually skip anything.
A guard clause meant to run once
The pattern first appears in commit b50452b (2025-09-26), for auto-package-update: (unless (file-directory-p "~/.emacs.d/elpa/auto-package-update/") (package-vc-install '(auto-package-update :url "..."))). The same commit reuses it correctly for auto-complete, checking ~/.emacs.d/elpa/auto-complete/ against a package-vc-install call for a package named auto-complete. In both cases the directory being checked is the exact name package-vc-install gives the package it clones. The check works because the two names agree.
Reused for a third package, wrong this time
Commit 05dedcb (2025-12-05) adds a third one, for smartparens, copied from the dap-mode block directly above it and only half edited:
- guard checks:
~/.emacs.d/elpa/smartparens/ - install call names the package:
dap-mode(with smartparens's GitHub URL)
Commit 09ba4c6 (2026-01-23) renamed the install symbol to smartparens-mode and left the guard alone. Either way it's a real, meaningful mismatch, because package-vc-install creates its checkout directory from the symbol it's given, not from whatever string the guard happens to check. By the end, the directory this produced was ~/.emacs.d/elpa/smartparens-mode/. The guard checks for ~/.emacs.d/elpa/smartparens/ — a directory nothing in this code path ever creates.
What that mismatch guarantees
unless (file-directory-p X) only skips its body once X exists. Here, X is elpa/smartparens/ — a path the install call itself never produces, since it writes to a directory named after its symbol (dap-mode, later smartparens-mode) instead. Nothing else in this config creates a bare elpa/smartparens/ directory either. That makes the condition unconditionally true on every single evaluation, regardless of whether smartparens was already fetched five minutes ago or five weeks ago: the guard doesn't fail open occasionally, it fails open every time by construction, for as long as the mismatched name stays in place. Compare that to auto-complete and auto-package-update a few lines above it in the same file, where the identical guard shape does exactly what it looks like it does, because there the checked name and the installed name happen to match.
Eight weeks, unnoticed
The mismatch shipped 2025-12-05 and was corrected in commit 850755c (2026-01-30), titled "Fix smartparens mode loading" — a one-line diff changing the checked path from elpa/smartparens/ to elpa/smartparens-mode/, with nothing else in the commit. Eight weeks between the two commits, on a line of code that runs at the top of every single Emacs startup during that window. The fix didn't stay the last word. Commit 2ba0219 (2026-03-06) added a second smartparens guard, in ui.el, with the same copy-paste shape: it checks elpa/smartparens-mode/ but hands package-vc-install the symbol auto-complete, along with smartparens's URL. That makes a fourth copy of the pattern, and a second wrong one. A cleanup commit on 2026-09-15 (9ad0b29) moved the packages.el guard into a shared helper, my-install-package-from-git, and changed both guards to check elpa/smartparens/ while installing a package named smartparens. On that branch the checked name and the installed name now agree in both places, and the directory they agree on is the bare smartparens/ the original guard checked for all along. The config this machine actually runs today is on a different branch that doesn't use package-vc-install for smartparens at all: it comes from MELPA through use-package, into a versioned elpa/smartparens-20260129.1214/ directory, with no guard involved.
What actually got the guard fixed
A guard that's supposed to prevent redundant work and doesn't is a quiet failure on its own: no wrong result, no error message, no missing feature. Nothing about this one would have forced anyone to look at it. What did was the package behind it. The commit that corrected the guard is titled "Fix smartparens mode loading", and the commits around it show that getting smartparens to load was the actual work that week.
A week earlier, 09ba4c6 (2026-01-23, "wip..") — the same commit that renamed the install symbol to smartparens-mode — also switched smartparens off. The (use-package smartparens-mode :ensure t) block was replaced with a commented-out ;; (require 'smartparens-mode), and the two hooks that turned it on for the PHP modes were commented out with it. Then, on 2026-01-30, 850755c landed at 16:23 and changed only the guard path. An hour later, at 17:21, a commit titled "add ripgrep" (e417a49) brought the use-package smartparens-mode block back. The PHP hooks stayed commented out. The loading setup didn't settle until 2ba0219 (2026-03-06), the same commit that added the second guard: it switched to use-package smartparens, the package's actual name, hooked into prog-mode, text-mode and markdown-mode.
So the guard wasn't caught because someone noticed the guard. It was caught as part of debugging the package it was protecting, and its one-line diff happens to be the part of that afternoon's work whose commit message describes it. A guard that fails open doesn't announce itself. It gets found when something next to it breaks, if it gets found at all — and the second smartparens guard, added in the commit that finally got loading right, went wrong again the same way.
Leave a comment
Comments are reviewed before they appear.