Feature request: plugin API access to the play-next queue (Shift+A), not just the main playlist

Open
  • Is something wrong?
#437 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 5 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
42/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
go, lua
Domain
backend, cli

Research direction

Start with luaplugin/api_queue.go, ui/model/plugin_queue.go, and docs/plugins.md to trace how the existing queue bindings resolve paths and how the play-next list is manipulated by the a shortcut. The request is for a Lua API that adds a resolved path or URL to that list without changing the main playlist. Done means a plugin can enqueue a track to play next; the payload names no tests to run.

Written by the indexing model from the issue text.

Description

What's missing

The Lua plugin API (docs/plugins.md) exposes cliamp.queue.add/jump/remove/move, which all operate on the main playlist (ui/model/plugin_queue.go -> resolve.Args -> m.playlist.Add()/Move()/Remove()). There's no way for a plugin to touch the separate "play next" queue (the Shift+A overlay, toggled per-track with a) — I checked luaplugin/api_queue.go and the main branch too, not just a release tag, and there's no Lua binding, CLI subcommand, or IPC command for it anywhere.

Why this matters

I built a "song radio" plugin (Last.fm track.getsimilar for suggestions, since Spotify killed the Recommendations API for new apps in Nov 2024, resolving matches via ytsearch1: since there's no Spotify URI support in the resolver either) that auto-queues similar tracks while you listen. Without access to the play-next queue, the only place a plugin can put tracks is the main playlist itself. I worked around this by:

  • Using cliamp.queue.move() (which swaps two positions rather than inserting) to walk newly-add()-ed tracks up next to the current track, since add() only appends to the very end.
  • Deleting each one via cliamp.queue.remove() once you've played past it, using a position-based counter, so they don't pile up permanently.

Both work, but it's a real hack around a UX that already exists in the app — a dynamic queue is the correct place for "here are some picks, play them next, don't touch my library playlist."

Ask

A Lua binding along the lines of:

cliamp.queue.enqueue_next(path)  -- resolve a path/URL and drop it into the play-next
                                  -- queue, right after the current track, without
                                  -- touching the main playlist

or equivalent access to toggle/insert into the same list that a already manipulates. Happy to test against a branch if useful — the plugin I wrote is a good real-world exerciser for this (Last.fm-based, but the resolve step is the same one every URL/file add already goes through).

Dominant language
Go
Stars
4.4k
Forks
307
Avg merge
4d 18h
Merged PRs (30d)
13

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from bjarneo/cliamp

All issues in bjarneo/cliamp

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.