feat(hammerspoon): clickable slivers in the accordion gutter

[kelvinst]

Parked, not ready to merge — opening it so the work and its findings are reviewable rather than stranded on a branch. Tracked as dot-phr.

Landed on main briefly (370eafb), reverted (f0b1ca3), reinstated here (bd3d860).

What it does

Aerospace stacks every unfocused accordion window at the same frame, then shifts the focused one over by accordion-padding (100). That gutter shows one strip whether two windows hide behind the focused one or seven — no sense of stack depth, and no way into it except cycling focus.

This splits the gutter into one sliver per hidden window (app icon + title rotated to read bottom-to-top). Clicking a sliver focuses that window.

Why drawn, not real windows

The original goal was actual windows, actually offset. Three mechanisms were tried and measured first:

• Nudging real tiled windows — aerospace re-asserts frames ~1s after any external setFrame, unprompted. A cascade collapses on a timer.
• Squeezing via aerospace resize — kitty compresses to a real 24px sliver, but Chrome has a hard 500px minimum and aerospace answers by overflowing the container, shoving windows to x=-460 and the focused one to x=-1028 w=3071, off-screen. Any Chromium/Electron window in the stack breaks the layout.
• Thumbnails instead of icons — hs.window:snapshot() returns nil on macOS 26 (per-window CGWindow capture is gone; full-screen capture still works).

Drawn slivers pick no fight with the layout.

Refreshes off hs.window.filter, not an aerospace on-focus-changed callback, so holding alt-j does not spawn an hs -c process per keypress.

Verified

• 4/4 sliver click tests pass, both gutter sides
• focused window always excluded; aerospace tree order preserved
• gutter side detection flips correctly (right x=1944, left x=12)
• tiles layout and single-window workspaces draw nothing
• rendering confirmed from a screenshot crop, not inferred from geometry

Two silent bugs were caught this way and are fixed here: deriving the container from only the unfocused frames (a window aerospace stopped focusing keeps its old padded position), and hs.canvas.matrix chained with . instead of :, which returns a valid but wrong matrix and put every title off-canvas.

Why it is parked

It works mechanically but does not feel good enough in practice.

• slivers get unreadable past ~5 windows (33px at 3, 20px at 5)
• aerospace opens only one gutter, so all hidden windows crowd one side regardless of where they actually sit relative to focus
• icon+title is a weak substitute for a thumbnail, and thumbnails are not available at all on macOS 26
• v_accordion is explicitly skipped — its gutter is horizontal and these slivers are not laid out for it

The ceiling is upstream. A genuine visual accordion likely needs aerospace support rather than a Hammerspoon overlay.

Session

Built and measured in a Claude Code session, archived rather than deleted so the full reasoning (the spike that ruled out three other mechanisms, the two silent bugs and how they surfaced) can be restored instead of reconstructed.

• Title: Aerospace accordion window count
• Desktop app session id: local_f85b8c55-1adf-4e13-ba0e-0e8a7d45afbc — unarchive from the sidebar's Archived view
• CLI transcript id: d8edf5ee-2fd3-4166-bdb6-aa7a5a6683a6

Resume from a terminal in this repo:

claude --resume d8edf5ee-2fd3-4166-bdb6-aa7a5a6683a6

Both ids point at the same conversation; the desktop app and the claude CLI just address it differently. These are local to this machine — there is no shareable URL, so the session will not open for anyone else from this PR.

🤖 Generated with Claude Code