A Vompeccc Case Study: Spotify as Pure ICR in Emacs
2 days ago
- #Emacs
- #VOMPECCC
- #Spotify
- Spotify client 'spot' built on VOMPECCC (Emacs completion packages) with minimal UI, using Consult for async candidate streaming, Marginalia for annotations, and Embark for actions.
- Architecture splits code into modular files: ~635 lines for Spotify infrastructure and ~493 lines for VOMPECCC integration shim across three files.
- Candidates are strings with two text properties: 'category' (type) and 'multi-data' (full API response), enabling interoperability among VOMPECCC packages.
- Consult sources defined per content type with async fetching, narrowing keys, and history, unified via 'consult--multi' for a single search interface.
- Cache implemented to handle Spotify API rate limits, storing query results to avoid redundant network requests during incremental search.
- Marginalia annotators format metadata into columns for each candidate type, using 'marginalia--fields' macro for alignment and styling.
- Embark keymaps provide per-type actions (e.g., play, show data, list tracks), with chaining where actions can launch new Consult sessions.
- Integration managed via 'spot-mode' minor mode that registers/unregisters annotators and keymaps, with graceful degradation if VOMPECCC packages missing.
- Counterfactual: Without VOMPECCC, a similar client would require custom UI and more code, lacking interoperability with Emacs completion ecosystem.
- Pattern generalizes to other domains (issue trackers, code hosting) via typed items, propertized candidates, and per-type sources/annotators/actions.
- Conclusion: Completion as a programmable substrate enables smaller, composable packages; reframes Unix philosophy as contributing to a shared substrate.