[emms-help] Patch: emms-playlist-tracks-in-region

[Fran Burstall]

The (not very important) issue: in a playlist buffer I hit
// (emms-playlist-limit-to-all).

What I expect to happen: nothing if the playlist is already
unlimited.

What happens: the playlist has its order reversed.

Commentary: emms-playlist-limit-to-all refills the playlist
from a list created by a previous application of
emms-playlist-tracks-in-region. The latter lists the tracks of the
region in reverse order on account of just consing up said list
from the top.

Please consider applying the following tiny patch to
emms-playlist-tracks-in-region.

---Fran

diff --git a/lisp/emms.el b/lisp/emms.el
index 062b6eb..7a14a9e 100644
--- a/lisp/emms.el
+++ b/lisp/emms.el
@@ -1098,7 +1098,7 @@ This is supplying ARGS as arguments to the source."
(emms-walk-tracks
(setq tracks (cons (emms-playlist-track-at (point))
tracks))))
- tracks))
+ (nreverse tracks)))

(defun emms-playlist-track-updated (track)
"Update TRACK in all playlist buffers."

[Yoni Rabkin]

Post by Fran Burstall
The (not very important) issue: in a playlist buffer I hit
// (emms-playlist-limit-to-all).
What I expect to happen: nothing if the playlist is already
unlimited.
What happens: the playlist has its order reversed.
Commentary: emms-playlist-limit-to-all refills the playlist
from a list created by a previous application of
emms-playlist-tracks-in-region. The latter lists the tracks of the
region in reverse order on account of just consing up said list
from the top.
Please consider applying the following tiny patch to
emms-playlist-tracks-in-region.
---Fran
diff --git a/lisp/emms.el b/lisp/emms.el
index 062b6eb..7a14a9e 100644
--- a/lisp/emms.el
+++ b/lisp/emms.el
@@ -1098,7 +1098,7 @@ This is supplying ARGS as arguments to the source."
(emms-walk-tracks
(setq tracks (cons (emms-playlist-track-at (point))
tracks))))
- tracks))
+ (nreverse tracks)))
(defun emms-playlist-track-updated (track)
"Update TRACK in all playlist buffers."

I think that the way emms-playlist-limit currently works is essentially
a kludge (indeed, the very idea behind `emms-playlist-limit' is a
strange way of replicating a subset of the browser.) Storing the entire
playlist in a variable is bad. We already have a data structure for
storing playlists: it's called a playlist!

Once we re-write it, these issues will go away by dint of
emms-playlist-limit being re-implemented correctly. For example, we
could make it so that limiting creates a new playlist with the selected
tracks and makes that playlist the current playlist. If the original
playlist was called "Classical" and was limited to the artist Beethoven,
the new playlist would be generated as "Classical (limited to
artist/Beethoven)". The new playlist can have a local variable pointing
to the original playlist so that a "//" can be equivalent to "kill this
buffer and make the original playlist current (if it still exists)".

I'm sure that there are other implementation ideas which are as good.