If you watch the video carefully, each track in the candidate list is followed by a horizontally aligned column of fields: #<track-number>, artist, a M:SS duration, album name, album type, release date. Each field is rendered to a fixed width in its own face, so numbers and dates and names land as visually distinct columns rather than getting mashed together with a delimiter. Small glyph prefixes (# for counts, ★ for popularity, ♥ for followers) disambiguate otherwise bare numbers. That column is provided by Marginalia, and it comes from one function:
(defun spot--annotate-track (cand) "Annotate track CAND with number, artist, duration, album, type, and date. The track number is prefixed with `#' and duration rendered as M:SS." (let ((data (get-text-property 0 'multi-data cand))) (marginalia--fields ((spot--format-count (ht-get data 'track_number)) :format "#%s" :truncate 5 :face 'spot-marginalia-number) ((spot--annotation-field (spot--first-name (ht-get data 'artists))) :truncate 25 :face 'spot-marginalia-artist) ((spot--format-duration (ht-get data 'duration_ms)) :truncate 7 :face 'spot-marginalia-number) ((spot--annotation-field (ht-get* data 'album 'name)) :truncate 30 :face 'spot-marginalia-album) ((spot--annotation-field (ht-get* data 'album 'album_type)) :truncate 8 :face 'spot-marginalia-type) ((spot--annotation-field (ht-get* data 'album 'release_date)) :truncate 10 :face 'spot-marginalia-date))))
The first line is the only plumbing: (get-text-property 0 'multi-data cand) pulls the full Spotify API response off the candidate (exactly the hash table spot--propertize-items stashed earlier), and everything after it is Marginalia's own marginalia--fields macro doing the formatting. marginalia--fields handles the alignment, the per-field truncation, and the face application. The only thing my code does is declare which fields of the Spotify payload go in which columns with which faces. This is another substrate borrow hiding in plain sight: Marginalia registers the annotator and formats its output. I never wrote a single character of alignment, padding, or colourisation logic. The annotator reached into multi-data for its fields, Marginalia's macro did the cosmetic work, and Marginalia never had to know about Spotify's data model.
spot ships seven annotators. Each one is a domain-specific projection of a single Spotify response type onto a display string. Albums surface artist, release date, and track count, artists surface popularity and follower count, shows surface publisher, media type, and episode count; and all this context is really important, especially if you are 'browsing'. The annotators are independent of the search code, independent of the actions code, and independent of each other.
Registering them with Marginalia is three lines of bookkeeping:
(defvar spot--marginalia-annotator-entries '((album spot--annotate-album none) (artist spot--annotate-artist none) (playlist spot--annotate-playlist none) (track spot--annotate-track none) (show spot--annotate-show none) (episode spot--annotate-episode none) (audiobook spot--annotate-audiobook none)) "List of marginalia annotator entries registered by spot.") (defun spot--setup-marginalia () "Register spot annotators with marginalia." (dolist (entry spot--marginalia-annotator-entries) (add-to-list 'marginalia-annotators entry)))
The spot--marginalia-annotator-entries list keys on the category symbol (album, artist, and so on), the very same symbols the Consult sources stamp onto their candidates. Marginalia looks up the category of the current candidate in marginalia-annotators, finds the entry, and runs the annotator. No spot code is in that path. I only had to declare the mapping.
This is where one of the most interesting benefits of the second post shows up concretely. That post mentioned that because Marginalia annotations are themselves searchable, Orderless's @ dispatcher lets you match against annotation text. spot did not ship this feature. Orderless and Marginalia did, for free, because I stamped the annotation onto the candidate in the right way.