emms-help
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Yoni Rabkin
Subject: Re: [emms-help] Patch: emms-playlist-tracks-in-region
Date: Wed, 20 Jun 2018 21:37:26 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Fran Burstall <address@hidden> writes:

> 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.

-- 
   "Cut your own wood and it will warm you twice"



reply via email to

[Prev in Thread] Current Thread [Next in Thread]