For the sake of easier installation for users, it would be good to have this in a public repo like MELPA. Gnu ELPA might make sense too.

I would love a genre source; then I could just add all of my folk music at once, shuffle it and and call it a day.

EMMS playlists are buffers. It might be useful (especially for power users who define their own actions on buffers) to just reuse the buffer keymap in embark? This would remove the need to reinvent the wheel on commonly needed operations (as in 6754e3b). OTOH, the way we store playlists at the moment (in text properties, which allows for prettification of strings or whatever, and is more robust than relying on buffer names) is probably not going to play well with most of those actions. There are also actions (like shufling) that only apply to playlist buffers, but that could be dealt with by making a 'playlist map with the 'buffer map as its parent.

Just putting this here to make myself think about it one day...

At the moment, the list of keywords used to filter the arglist in consult-emms--playlist is hard-coded. This works, but it isn't very elegant, or easily maintainable if the arglist changes in future versions of consult. It would be better to get it programmatically. (as the TODO in the code says!)

Some commands have shorthands for embark-become because one switches between them a lot. The fours entry points are probably a good example.

Embark integration is happening here. Embark integration has been merged (the README lies!). This is (still) a tracker issue for the actions on different kinds of targets.

Wishlist of ideas for embark actions on different kinds of candidates:

(once I've got through these and the package is a bit more stable, I'll close the issue and new isses can be raised for any individual suggested additions)

Tracks (always)

• Add to playlist (select a playlist from all the currently open ones. This should allow for accepting a non-matching input and thus creating a new playlist, to which the track is then added). d17b4e7
• goto album (select from the tracks in given track's album) 6fd2dfe
• add album to current playlist 30c68ac
• goto artist (select from the tracks in given track's artist) 00350ef
• add artist to current playlist 30c68ac
• goto genre 23d769c
• add genre 6894c3b

Tracks (when on a playlist)

• Remove from playlist 125c6cf
• Move up/down in playlist
• Make next/enqueue (make the playlist current, so that it plays next, and ensure that the selected track will be the first to play). (It might be a good idea to drop a marker in the emms playlist buffer whenever I do this, and have repeated invocations just deposit the track at the marker. That way if I add A then B, I get current track, A, B, rather than current track, B, A (which would happen if B was just pushed to directly after the current track.). Or maybe enqueue and make-next should just be two separate commands?)

(both of the above are good candidates for having quick keys bound to them (can't find the link right now, but I'm pretty sure there's a way to do this))

Artists

• Choose from among artist's tracks 3a04f56
  • Include albums as additional source in viewing artist (so use consult--multi) 88c64fa
• choose a playlist and add artist's tracks to it fd44afb

Albums

• Choose from among album's tracks 5d73e9a
• choose a playlist and add album to it b9b2b61
• goto artist 6f77630
• add artist to current playlist
• goto genre 7bae277
• add genre d1798ee

Playlists

• save playlist to file
• insert playlist into (other) playlist buffer
• Shuffle playlist
• Kill/remove playlist bd95e6b
• Clear tracks from playlist
• rename playlist buffer bd95e6b
• Make current (so that the next song is drawn from the selected playlist, but the current one finished first) f929cc5

Streams

• Choose playlist and add to it a4b6396

Genres

• goto genre (similar in spirit to "goto/album" on an album -- list all the tracks in the genre. Perhaps albums and artists too?) 1ee5087

Such that a user in, say, a playlist buffer could call embark-act on a track and have the same thing happen as if they had called it on a track in a consult-emms minibuffer. This should apply to tracks in playlist buffers, tracks, albums, artists etc. in the browser and to playlists in the metaplaylist buffer.

Instructions here.

Need an easier way to clear the current playlist.

This might be a useful thing to do. We could say that:

• accepting a non-matching input when choosing a playlist buffer creates a new playlist
• If the playlist chosen is empty (it is newly created, or is just empty anyway) then make it the current playlist, and run consult-emms-library, so the user can add things to it.

Not sure, but it might be fun?

Title. There isn't much to say at the moment, though it might be worth mentioning how little this package actually does (in particular: it doesn't do anything to or for EMMS itself. That configuration is left to the user)/

It would be good to configure proper embark exporters. Lists of tracks could be exported to a playlist buffer, lists of other things (albums, artists, etc) maybe to a specially filtered EMMS browser buffer? And since playlists are just buffers, they can be exported like buffers normally are (or mabe into special filtered metaplaylist buffers? I could see both of these being useful, so maybe there could be a custom variable for controlling which is used for exporting lists of playlists?)

Annotate candidates when listing music items (tracks, albums, etc.), such as in `consult-emms-library).

I want the annotation to be configurable, vertically aligned, and to have annotations in similar spirit for different categories (i.e. a track's and an album's playing time) aligned to each other.

I think the way to do this is to have:

• a list variable for the different fields to display, and how long they should be (similar to how ebib handles index-item formatting). Perhaps this could also include fall-backs for if the field is undefined.
• a generic function for each field
• an implementation of each such function for each category (track, album, etc.). If the field is inappropriate, then return nil, or an empty string or something.

To solve the truncate issue mentioned here, I think the functions for gettng candidate lists will just have to include the ability to truncate? Maybe look into how citar handles this problem. Because of that issue (unless I want to have a long excursion into implementing proper affixation for consult-multi), annotation will have to come after the string. This is something I can live with.

This could be useful? It would certainly be a nicer user experience.

(As in stored playlists which can be added with emms-source-playlist.) Might be good ot have a variable dictating where these are generally kept -- a defcustom like consult-emms-playlist-dir, default value wuld just be to inherit from emms-directory. Better yet -- propose that EMMS itself have such a variable, and submit a patch for it, then use it here.