| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I had to kill an Emacs session today over a prompt I could not answer. A
second agent session held the selected window while "Overwrite hiroshi.m3u?
(yes or no)" waited in another frame, so my keystrokes went to a terminal
and the minibuffer stayed empty. Losing unsaved buffers is a far worse
outcome than a mis-keyed confirm.
So cj/confirm-strong becomes cj/confirm-destructive, and instead of binding
use-short-answers to nil for a typed "yes" it reads a single y or n.
Two things I kept:
- No default. Only y and n answer, so a stray RET or space re-prompts
rather than confirming a shutdown.
- Pending input is discarded before the read. Without that the change would
have been a bad trade: read-char-choice reads the input queue, so a key
typed before the prompt painted would confirm instantly, where the old
typed-"yes" absorbed it harmlessly.
Worth being honest about what this does not fix. One keystroke does not
make a prompt reachable when focus is elsewhere, and C-g is still the
escape. It lowers the cost of the situation rather than preventing it.
Six call sites: shutdown and reboot, shred, playlist overwrite and delete,
and the two file overwrites.
|
| |
|
|
|
|
| |
I ran both live VERIFYs and found no issues: the fancy player UI (hero, serif, cover art, advancing bar, plain-text fallback) and the radio-browser queue-first model (n / t / m picks, save on v, offline and empty searches).
Both specs carry the keyword, a dated history line, and the mirrored Metadata status.
|
| |
|
|
|
|
|
|
| |
The radio-browser lookup and the manual station creator no longer write .m3u files at pick time. Picks become url tracks in the queue, carrying the station name, uuid, and favicon as track properties, and play immediately. The display and cover-art layers read the properties first and fall back to the on-disk metadata, so existing station files keep working.
Saving is the normal playlist save, now on w. The radio feature's S=stop rebind had silently shadowed the old S=save binding. An all-stream queue saves into the MPD playlist dir, and the station name pre-fills the prompt with no -Radio suffix. A custom emitter writes the station metadata back out as .m3u comment lines, since the stock EMMS writer emits bare URLs and would lose names and cover art on reload.
I removed the write-at-pick machinery (station-m3u, write-stations, disambiguate-name, the -Radio filename suffix) and the orphaned safe-filename helper. An empty name at the save prompt now signals an error instead of writing a hidden .m3u.
|
| |
|
|
|
|
|
|
| |
I turned the radio-browser lookup into a Radio row in the playlist buffer: n searches by station name, t searches by tag/genre, m enters a station by hand. Tag search is new (it was a vNext item), and both name and tag hit radio-browser's search endpoint with a name= or tag= field.
Freeing n and t moved two keys: single mode goes from t to s, and stop goes from s to S. The header gains a Radio row and the Mode row now reads [s] single. Created station files carry a -Radio suffix (Adroit_Jazz_Underground-Radio.m3u).
The pure pieces and the search-URL field are unit-tested (20). Name and tag searches are live-verified. The picker and playback stay a manual check.
|
| |
|
|
|
|
|
|
| |
I built the first phase of the radio-browser lookup: the pure pieces and the network client behind the search command, with no UI yet. It lives in modules/music-config.el, alongside the existing radio-station creator.
The client is url.el plus json-parse-string, trying a pinned host and falling back to one from /json/servers. The pure layer parses a response into station plists, and a non-JSON body signals a clear user-error rather than a stack trace. It picks a station's stream URL (url_resolved, then url), emits the .m3u in the existing radio format with the radio-browser UUID, formats the completion annotation (codec, bitrate, country, votes, tags), and disambiguates a colliding filename by UUID. Names are newline-stripped so an odd one can't inject extra m3u lines.
The pure pieces are unit-tested (14). The network client is smoke-tested against the live API.
|
| |
|
|
|
|
| |
I reviewed the spec and folded the review back in. The review found seven gaps, one blocking: completing-read-multiple splits its selection on commas, and radio-browser station names contain commas. A comma'd name would be mis-selected silently.
Resolving all seven: selection is now a loop-based single-select that never round-trips through a delimiter, the emitter skips a station with no usable stream URL, same-name picks in one search disambiguate by UUID, the server client has a defined fallback, and create-and-play interrupts current playback. The annotation format is codec, bitrate, country, votes, and tags, with no play count. Decisions read 5 of 5 and findings 7 of 7, so the spec flips to READY.
|
| |
|
|
|
|
| |
The prototype is a standalone HTML mockup of the four minibuffer screens for the radio-browser lookup: query, station list, multi-select, and created-and-playing. I drew it with real jazz-search data in the vertico and marginalia style. It shows the two candidate-annotation formats the design picks between. The spec's References section links to it.
This sets the convention for a spec's visual companion: docs/specs/<slug>.prototype.html, tracked alongside the spec.
|
|
|
A spec for searching radio-browser.info from Emacs and turning a selection into a playable radio .m3u, reusing the existing writer, multi-directory sourcing, and mpv path. The player can already read and play radio playlists but has no native way to discover stations, so every station is hand-entered from a browser.
I verified the API live (server discovery and station search) and matched the output to the existing radio .m3u format. All four design decisions are resolved: built-in url.el, multi-select writing one file per station, saving into the MPD playlist directory, and create-and-play. The spec has two build phases and is ready for spec-review.
|
