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

[Yoni Rabkin]

Hi,
Some news: I made good progress on a more robust implementation but
hit a wall when I realised when I realised that I had not understood
how emms handles multiple playlist buffers.

I'm happy to hear you've been working on it.

My idea had been that limiting by artist (say) creates a new playlist
buffer which was not necessarily current (so I can limit to Led
Zeppelin while still listening to whatever is playing in the current
unlimited buffer). 

I would say that this is the right direction. But maybe we've been
thinking about this in a manner which is too... limited: perhaps we can
first implement an `emms-playlist-derived' mechanism. This would be a
general mechanism which takes as input playlist-A, applies a series of
functions to it and outputs playlist-B as a result. Then we could
implement `emms-playlist-limit' using `emms-playlist-derived'.

This would allow people to then use `emms-playlist-derived' to implement
other interesting playlist modification functions (Emacs already uses
this technique to define modes with `define-derived-mode'.) For
instance, code could use `emms-playlist-derived' to iterate over a
playlist and split it into multiple playlists which are per-artist or
album.

I implemented a mechanism for edits (deletions, maybe also insertions)
to the limited buffer to propagate back to the source buffer. 
However, then I realised that some emms buffer operations, notably
emms-playlist-save, apply to the current playlist even when that is
not be the playlist buffer from which it is called.   So, for example,
I cannot save a new Led Zeppelin playlist to disc from my limited
buffer unless I first make it current.

I would recommend against such a mechanism; operations on one playlist
buffer shouldn't affect another.

But perhaps I don't fully understand what type of operations you wanted
to do with the limited buffer. Stuff like narrow-to-region?

At this point I lost momentum because I could not decide whether the
limited playlist should automatically become current. 

In such a case my policy is to choose a default behavior (in this case I
would say that the default would be that the new buffer would be made
current) but build in the option so that people can change the
behavior. For example, a `emms-playlist-limit-new-current-p' variable
set by default to t. But see more on this below.

I wanted to be able to limit arbitrary (non-current) playlists as an
aid for editing such playlists but this does not seem such a good fit
with how emms works (at least according to my current understanding).

This makes me think that when invoked pragmatically (which can be
implicit from the user's perspective) the function shouldn't change the
current playlist buffer unless an argument is passed to the function
saying otherwise, but when invoked interactively (which is an explicit
action by the user) it would obey `emms-playlist-limit-new-current-p' as
above.

So advice would be very welcome here!  How do you want the limit
feature to work? 

I hope my thoughts above make some sense. Also, do you mind if I post
this latest conversation onto the mailing list so that:

* everyone else can read and weigh-in

* we can continue the conversation there, where it will be archived

P.S. Please feel free to create a remote branch on the repo once you
have code so that we can poke at it as well.

---Fran

I agree that the current implementation is a little fragile, to

say

the least!
If the re-implementation is a long way down the to-do list,

would it

be helpful if I had a go at doing it?  (It won't hurt my

feelings if

you say no!)
---Fran

Any news on this front?

   
     > 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

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"

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

[Fran Burstall]

Have a look at branch emms-playlist-limit for a re-write of
emms-playlist-limit.el. This is my first piece of elisp for public
consumption so criticism very welcome and almost certainly necessary.

The main difference is that the limiting is done by a playlist-in,
playlist-out function (see emms-playlist-limit--limit-playlist) that
approximates Yoni's derived playlist idea.

Along the way, I fixed various bugs caused by

* cursor not on a track
* current track not set in limit playlist

that caused the previous implementation to error out or otherwise misbehave.

As with the previous implementation, limiting always applies to the current
playlist and makes the new limited playlist current. I wonder if that is
the optimal behaviour?

---Fran

---------- Forwarded message ----------
Date: Thu, 20 Sep 2018 14:27:18 -0400
Subject: Re: [emms-help] Patch: emms-playlist-tracks-in-region

Hi,
Some news: I made good progress on a more robust implementation but
hit a wall when I realised when I realised that I had not understood
how emms handles multiple playlist buffers.

I'm happy to hear you've been working on it.

My idea had been that limiting by artist (say) creates a new playlist
buffer which was not necessarily current (so I can limit to Led
Zeppelin while still listening to whatever is playing in the current
unlimited buffer).

I would say that this is the right direction. But maybe we've been
thinking about this in a manner which is too... limited: perhaps we can
first implement an `emms-playlist-derived' mechanism. This would be a
general mechanism which takes as input playlist-A, applies a series of
functions to it and outputs playlist-B as a result. Then we could
implement `emms-playlist-limit' using `emms-playlist-derived'.
This would allow people to then use `emms-playlist-derived' to implement
other interesting playlist modification functions (Emacs already uses
this technique to define modes with `define-derived-mode'.) For
instance, code could use `emms-playlist-derived' to iterate over a
playlist and split it into multiple playlists which are per-artist or
album.

I implemented a mechanism for edits (deletions, maybe also insertions)
to the limited buffer to propagate back to the source buffer.
However, then I realised that some emms buffer operations, notably
emms-playlist-save, apply to the current playlist even when that is
not be the playlist buffer from which it is called. So, for example,
I cannot save a new Led Zeppelin playlist to disc from my limited
buffer unless I first make it current.

I would recommend against such a mechanism; operations on one playlist
buffer shouldn't affect another.
But perhaps I don't fully understand what type of operations you wanted
to do with the limited buffer. Stuff like narrow-to-region?

At this point I lost momentum because I could not decide whether the
limited playlist should automatically become current.

In such a case my policy is to choose a default behavior (in this case I
would say that the default would be that the new buffer would be made
current) but build in the option so that people can change the
behavior. For example, a `emms-playlist-limit-new-current-p' variable
set by default to t. But see more on this below.

I wanted to be able to limit arbitrary (non-current) playlists as an
aid for editing such playlists but this does not seem such a good fit
with how emms works (at least according to my current understanding).

This makes me think that when invoked pragmatically (which can be
implicit from the user's perspective) the function shouldn't change the
current playlist buffer unless an argument is passed to the function
saying otherwise, but when invoked interactively (which is an explicit
action by the user) it would obey `emms-playlist-limit-new-current-p' as
above.

So advice would be very welcome here! How do you want the limit
feature to work?

I hope my thoughts above make some sense. Also, do you mind if I post
* everyone else can read and weigh-in
* we can continue the conversation there, where it will be archived
P.S. Please feel free to create a remote branch on the repo once you
have code so that we can poke at it as well.

---Fran

I agree that the current implementation is a little fragile, to

say

the least!
If the re-implementation is a long way down the to-do list,

would it

be helpful if I had a go at doing it? (It won't hurt my

feelings if

you say no!)
---Fran

Any news on this front?

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"

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

--
"Cut your own wood and it will warm you twice"
---------- Forwarded message ----------
Date: Mon, 24 Sep 2018 13:20:42 -0400
emms-playlist-tracks-in-region
--
"Cut your own wood and it will warm you twice"
_______________________________________________
Emms-help mailing list
https://lists.gnu.org/mailman/listinfo/emms-help

[Yoni Rabkin]

Post by Fran Burstall
Have a look at branch emms-playlist-limit for a re-write of
emms-playlist-limit.el.  This is my first piece of elisp for public
consumption so criticism very welcome and almost certainly necessary.
The main difference is that the limiting is done by a playlist-in,
playlist-out function (see emms-playlist-limit--limit-playlist) that
approximates Yoni's derived playlist idea.
Along the way, I fixed various bugs caused by 
* cursor not on a track
* current track not set in limit playlist
that caused the previous implementation to error out or otherwise misbehave.

This is all good. I'm fine with you merging this into master so that
everyone can play with it (especially considering that it already
compiles with no errors or warnings.)

Once you do we need to:

* write documentation (I'm volunteering to do that)

* document the change in one sentence in the NEWS file (you do that)

* add you to the AUTHORS file (you do that too)

Post by Fran Burstall
As with the previous implementation, limiting always applies to the
current playlist and makes the new limited playlist current.  I
wonder if that is the optimal behaviour?
---Fran

That's a good question. The confusion here would be that you could be
trying to limit a playlist buffer and keep on getting an error that no
tracks are being found because the code is looking for tracks from
_this_ buffer in the _current_ buffer:

1. create two playlist buffers "classical" and "prog rock"

2. make "classical" the current playlist buffer

3. switch to "prog rock" (note we are just switching to it, not
making it current)

4. try to limit to a track from "prog rock" (say, "21st Centry
Schizoid Man")

5. get an error because "21st Centry Schizoid Man" can't be found in
the "classical" buffer

The behavior isn't technically an error, but I think it falls short of
the Do What I Mean principle.

What do you think?

Post by Fran Burstall
---------- Forwarded message ----------
Cc: 
Bcc: 
Date: Thu, 20 Sep 2018 14:27:18 -0400
Subject: Re: [emms-help] Patch: emms-playlist-tracks-in-region

Hi,
Some news: I made good progress on a more robust implementation

but

hit a wall when I realised when I realised that I had not

understood

how emms handles multiple playlist buffers.

I'm happy to hear you've been working on it.

My idea had been that limiting by artist (say) creates a new

playlist

buffer which was not necessarily current (so I can limit to Led
Zeppelin while still listening to whatever is playing in the

current

unlimited buffer). 

I would say that this is the right direction. But maybe we've been
thinking about this in a manner which is too... limited: perhaps we can
first implement an `emms-playlist-derived' mechanism. This would be a
general mechanism which takes as input playlist-A, applies a series of
functions to it and outputs playlist-B as a result. Then we could
implement `emms-playlist-limit' using `emms-playlist-derived'.
This would allow people to then use `emms-playlist-derived' to implement
other interesting playlist modification functions (Emacs already uses
this technique to define modes with `define-derived-mode'.) For
instance, code could use `emms-playlist-derived' to iterate over a
playlist and split it into multiple playlists which are
per-artist or
album.

I implemented a mechanism for edits (deletions, maybe also

insertions)

to the limited buffer to propagate back to the source buffer. 
However, then I realised that some emms buffer operations,

notably

emms-playlist-save, apply to the current playlist even when

that is

not be the playlist buffer from which it is called.   So, for

example,

I cannot save a new Led Zeppelin playlist to disc from my

limited

buffer unless I first make it current.

I would recommend against such a mechanism; operations on one playlist
buffer shouldn't affect another.
But perhaps I don't fully understand what type of operations you wanted
to do with the limited buffer. Stuff like narrow-to-region?

At this point I lost momentum because I could not decide

whether the

limited playlist should automatically become current. 

In such a case my policy is to choose a default behavior (in this case I
would say that the default would be that the new buffer would be made
current) but build in the option so that people can change the
behavior. For example, a `emms-playlist-limit-new-current-p' variable
set by default to t. But see more on this below.

I wanted to be able to limit arbitrary (non-current) playlists

as an

aid for editing such playlists but this does not seem such a

good fit

with how emms works (at least according to my current

understanding).
This makes me think that when invoked pragmatically (which can be
implicit from the user's perspective) the function shouldn't change the
current playlist buffer unless an argument is passed to the function
saying otherwise, but when invoked interactively (which is an explicit
action by the user) it would obey
`emms-playlist-limit-new-current-p' as
above.

So advice would be very welcome here!  How do you want the

limit

feature to work? 

I hope my thoughts above make some sense. Also, do you mind if I post
    * everyone else can read and weigh-in
    * we can continue the conversation there, where it will be
archived
P.S. Please feel free to create a remote branch on the repo once you
have code so that we can poke at it as well.

---Fran
   
   
     > I agree that the current implementation is a little

fragile, to

     say
     > the least!
     >
     > If the re-implementation is a long way down the to-do

list,

     would it
     > be helpful if I had a go at doing it?  (It won't hurt my
     feelings if
     > you say no!)
     >
     > ---Fran
   
     Any news on this front?
   
     >
     > On Thu, 21 Jun 2018 at 02:39, Yoni Rabkin <
     >
     >   
     >     > 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

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"
     >
     >
     >
   
     --
        "Cut your own wood and it will warm you twice"

--
   "Cut your own wood and it will warm you twice"
---------- Forwarded message ----------
Cc: 
Bcc: 
Date: Mon, 24 Sep 2018 13:20:42 -0400
emms-playlist-tracks-in-region
--
   "Cut your own wood and it will warm you twice"
_______________________________________________
Emms-help mailing list
https://lists.gnu.org/mailman/listinfo/emms-help

[Fran Burstall]

Post by Yoni Rabkin

Post by Fran Burstall
Have a look at branch emms-playlist-limit for a re-write of
emms-playlist-limit.el. This is my first piece of elisp for public
consumption so criticism very welcome and almost certainly necessary.

This is all good. I'm fine with you merging this into master so that
everyone can play with it (especially considering that it already
compiles with no errors or warnings.)
* write documentation (I'm volunteering to do that)
* document the change in one sentence in the NEWS file (you do that)
* add you to the AUTHORS file (you do that too)

Will do.

Post by Yoni Rabkin
As with the previous implementation, limiting always applies to the

Post by Fran Burstall
current playlist and makes the new limited playlist current. I
wonder if that is the optimal behaviour?
---Fran

That's a good question. The confusion here would be that you could be
trying to limit a playlist buffer and keep on getting an error that no
tracks are being found because the code is looking for tracks from
1. create two playlist buffers "classical" and "prog rock"
2. make "classical" the current playlist buffer
3. switch to "prog rock" (note we are just switching to it, not
making it current)
4. try to limit to a track from "prog rock" (say, "21st Centry
Schizoid Man")
5. get an error because "21st Centry Schizoid Man" can't be found in
the "classical" buffer
The behavior isn't technically an error, but I think it falls short of
the Do What I Mean principle.
What do you think?

I agree that it falls short: I am likely to call the limiting function from
a playlist buffer and expect it to limit what I am seeing. This is not the
only place where emms has this slightly unexpected behaviour: hit C-x C-s
in any playlist buffer and what is saved is the _current_ playlist: in yr
example, I hit C-x C-s in the "prog rock" buffer so I can listen to King
Crimson on my phone but the saved m3u (say) file is full of Beethoven!

My preference for emms-playlist-limit would be:

1. Limit the playlist buffer it is called from (and error out if it is
called from a non-playlist buffer).

2. If the calling buffer is the current playlist, make the limited
playlist current, otherwise not.

3. Have a variable emms-playlist-limit-only-current so that users can get
the old behaviour back if they want it.

Similar remarks apply to emms-playlist-save and, indeed, all other commands
in the emms-playlist-mode-map: it violates the Principle of Least Surprise
when they act on another, possibly invisible, buffer. (That said, most
commands in the mode-map do apply to the calling playlist but the limit fns
and save are definite exceptions!). If emms-playlist-save saved the
calling buffer, this would go a long way towards making emms a comfortable
environment for _editing_ playlists (which is one of the reasons I was
attracted to emms in the first place) as well as playing them. Thoughts?

---Fran

[Yoni Rabkin]

Post by Fran Burstall

Post by Fran Burstall
Have a look at branch emms-playlist-limit for a re-write of
emms-playlist-limit.el.  This is my first piece of elisp for

public

Post by Fran Burstall
consumption so criticism very welcome and almost certainly

necessary.
 
This is all good. I'm fine with you merging this into master so that
everyone can play with it (especially considering that it already
compiles with no errors or warnings.)
    * write documentation (I'm volunteering to do that)
    * document the change in one sentence in the NEWS file (you
do that)
    * add you to the AUTHORS file (you do that too)
Will do.

Post by Fran Burstall
As with the previous implementation, limiting always applies to

the

Post by Fran Burstall
current playlist and makes the new limited playlist current.  I
wonder if that is the optimal behaviour?
---Fran

That's a good question. The confusion here would be that you could be
trying to limit a playlist buffer and keep on getting an error that no
tracks are being found because the code is looking for tracks from
    1. create two playlist buffers "classical" and "prog rock"
    2. make "classical" the current playlist buffer
    3. switch to "prog rock" (note we are just switching to it,
not
       making it current)
    4. try to limit to a track from "prog rock" (say, "21st
Centry
       Schizoid Man")
    5. get an error because "21st Centry Schizoid Man" can't be
found in
       the "classical" buffer
The behavior isn't technically an error, but I think it falls short of
the Do What I Mean principle.
What do you think?
I agree that it falls short: I am likely to call the limiting
function from a playlist buffer and expect it to limit what I am
seeing.  This is not the only place where emms has this slightly
unexpected behaviour: hit C-x C-s in any playlist buffer and what is
saved is the _current_ playlist: in yr example, I hit C-x C-s in the
"prog rock" buffer so I can listen to King Crimson on my phone but
the saved m3u (say) file is full of Beethoven!
1.  Limit the playlist buffer it is called from (and error out if it
is called from a non-playlist buffer).
2.  If the calling buffer is the current playlist, make the limited
playlist current, otherwise not.

I agree with the above.

Post by Fran Burstall
3.  Have a variable emms-playlist-limit-only-current so that users
can get the old behaviour back if they want it.

Won't hurt to have; not a big deal to omit.

Post by Fran Burstall
Similar remarks apply to emms-playlist-save and, indeed, all other
commands in the emms-playlist-mode-map: it violates the Principle of
Least Surprise when they act on another, possibly invisible, buffer. 
(That said, most commands in the mode-map do apply to the calling
playlist but the limit fns and save are definite exceptions!).   If
emms-playlist-save saved the calling buffer, this would go a long way
towards making emms a comfortable environment for _editing_ playlists
(which is one of the reasons I was attracted to emms in the first
place) as well as playing them.  Thoughts?
---Fran

We should modify this behavior where we find it so that Emms conforms
with the rest of Emacs; when I hit C-x C-s it saves the buffer I'm
looking at, and not some invisible buffer.

I've added this to my general TODO.

[Fran Burstall]

Post by Yoni Rabkin

Post by Fran Burstall
1. Limit the playlist buffer it is called from (and error out if it
is called from a non-playlist buffer).
2. If the calling buffer is the current playlist, make the limited
playlist current, otherwise not.

I agree with the above.

Post by Fran Burstall
3. Have a variable emms-playlist-limit-only-current so that users
can get the old behaviour back if they want it.

Won't hurt to have; not a big deal to omit.

This should all be easy to implement after the rewrite of
emms-playlist-limit. I will do so and push to the emms-playlist-limit
branch when done.

Post by Yoni Rabkin

Post by Fran Burstall
Similar remarks apply to emms-playlist-save and, indeed, all other
commands in the emms-playlist-mode-map: it violates the Principle of
Least Surprise when they act on another, possibly invisible, buffer.
(That said, most commands in the mode-map do apply to the calling
playlist but the limit fns and save are definite exceptions!). If
emms-playlist-save saved the calling buffer, this would go a long way
towards making emms a comfortable environment for _editing_ playlists
(which is one of the reasons I was attracted to emms in the first
place) as well as playing them. Thoughts?
---Fran

We should modify this behavior where we find it so that Emms conforms
with the rest of Emacs; when I hit C-x C-s it saves the buffer I'm
looking at, and not some invisible buffer.
I've added this to my general TODO.

I will also have a look at this...

---Fran

[Yoni Rabkin]

Post by Fran Burstall
I will also have a look at this...

Cool. Just make sure that you drop a line here on the mailing list if
you do, so that we don't duplicate our efforts.

[Yoni Rabkin]

I've added emms-playlist-limit to the documentation.

As I was writing it occurred to me that `emms-playlist-limit-to-all'
perhaps should not kill the derived buffer. At least not without adding
a mention of that to the function documentation, which currently simply
reads: "Show all tracks again."

[Fran Burstall]

Here I was replicating the previous behaviour.

Thinking about it: if I don't kill the buffer and I later run the same
limiting action, I will want to at least clear the derived buffer so as not
to present stale results. So maybe better to just kill it and document it
in the doc-string. Either way, I agree that the current doc-string does
not capture what the function does.

What do you think? Kill the derived buffer or not?

---Fran

Post by Yoni Rabkin
I've added emms-playlist-limit to the documentation.
As I was writing it occurred to me that `emms-playlist-limit-to-all'
perhaps should not kill the derived buffer. At least not without adding
a mention of that to the function documentation, which currently simply
reads: "Show all tracks again."
--
"Cut your own wood and it will warm you twice"
_______________________________________________
Emms-help mailing list
https://lists.gnu.org/mailman/listinfo/emms-help

[Yoni Rabkin]

Post by Fran Burstall
Here I was replicating the previous behaviour.
Thinking about it: if I don't kill the buffer and I later run the
same limiting action, I will want to at least clear the derived
buffer so as not to present stale results.  So maybe better to just
kill it and document it in the doc-string.  Either way, I agree that
the current doc-string does not capture what the function does. 
What do you think?  Kill the derived buffer or not? 

It wouldn't really present stale results since each call to
`emms-playlist-new' creates a unique, numbered buffer.

(emms-playlist-new "foo") => #<buffer foo>
(emms-playlist-new "foo") => #<buffer foo<2>>

The question is therefore if two calls from the same buffer, using the
same limit, should overwrite the derived buffer, or simply create a new
one.

I don't have a strong opinion about that (If someone else has an opinion
they can certainly chime in). Buffers are cheap, but you also may not
want to spam buffers. Feel free to make that as you see fit.

Post by Fran Burstall
I've added emms-playlist-limit to the documentation.
As I was writing it occurred to me that
`emms-playlist-limit-to-all'
perhaps should not kill the derived buffer. At least not without adding
a mention of that to the function documentation, which currently simply
reads:   "Show all tracks again."
--
   "Cut your own wood and it will warm you twice"
_______________________________________________
Emms-help mailing list
https://lists.gnu.org/mailman/listinfo/emms-help

[Fran Burstall]

Hi,

Look in the emms-playlist-limit branch for a new version of
emms-playlist-limit.el that operates on the playlist in the current buffer
rather than the current playlist. While I was there, I tried to make the
doc-strings a little more expressive.

Meanwhile, I just got burned by emms-playlist-sort having the same
behaviour: no matter what playlist buffer you hit "S a" in, it is the
current playlist that gets sorted by info-artist. I was mashing the keys
and not understanding why the playlist I was looking at did not sort!

If you agree that this is a bug, I am happy to fix...

---Fran

Post by Yoni Rabkin

Post by Fran Burstall
Here I was replicating the previous behaviour.
Thinking about it: if I don't kill the buffer and I later run the
same limiting action, I will want to at least clear the derived
buffer so as not to present stale results. So maybe better to just
kill it and document it in the doc-string. Either way, I agree that
the current doc-string does not capture what the function does.
What do you think? Kill the derived buffer or not?

It wouldn't really present stale results since each call to
`emms-playlist-new' creates a unique, numbered buffer.
(emms-playlist-new "foo") => #<buffer foo>
(emms-playlist-new "foo") => #<buffer foo<2>>
The question is therefore if two calls from the same buffer, using the
same limit, should overwrite the derived buffer, or simply create a new
one.
I don't have a strong opinion about that (If someone else has an opinion
they can certainly chime in). Buffers are cheap, but you also may not
want to spam buffers. Feel free to make that as you see fit.

Post by Fran Burstall
I've added emms-playlist-limit to the documentation.
As I was writing it occurred to me that
`emms-playlist-limit-to-all'
perhaps should not kill the derived buffer. At least not without adding
a mention of that to the function documentation, which currently simply
reads: "Show all tracks again."
--
"Cut your own wood and it will warm you twice"
_______________________________________________
Emms-help mailing list
https://lists.gnu.org/mailman/listinfo/emms-help

--
"Cut your own wood and it will warm you twice"
_______________________________________________
Emms-help mailing list
https://lists.gnu.org/mailman/listinfo/emms-help

[Yoni Rabkin]

Post by Fran Burstall
Hi,
Look in the emms-playlist-limit branch for a new version of
emms-playlist-limit.el that operates on the playlist in the current
buffer rather than the current playlist.  While I was there, I tried
to make the doc-strings a little more expressive.

It seems to work well (haven't tried it a lot.) This can be merged into
master.

I pushed a small patch to fix the copyright header.

Post by Fran Burstall
Meanwhile, I just got burned by emms-playlist-sort having the same
behaviour: no matter what playlist buffer you hit "S a" in, it is the
current playlist that gets sorted by info-artist.  I was mashing the
keys and not understanding why the playlist I was looking at did not
sort!  
If you agree that this is a bug, I am happy to fix...

I'm going to go ahead and say that probably anywhere this behavior is
found it is a bug, or at least an older and unwanted behavior. Care
would need to be taken to read the respective doc-strings in case they
explicitly mention acting on the current buffer.

Post by Fran Burstall
---Fran

thanks!

Post by Fran Burstall

Post by Fran Burstall
Here I was replicating the previous behaviour.
Thinking about it: if I don't kill the buffer and I later run

the

Post by Fran Burstall
same limiting action, I will want to at least clear the derived
buffer so as not to present stale results.  So maybe better to

just

Post by Fran Burstall
kill it and document it in the doc-string.  Either way, I agree

that

Post by Fran Burstall
the current doc-string does not capture what the function

does. 

Post by Fran Burstall
What do you think?  Kill the derived buffer or not? 

It wouldn't really present stale results since each call to
`emms-playlist-new' creates a unique, numbered buffer.
(emms-playlist-new "foo") => #<buffer foo>
(emms-playlist-new "foo") => #<buffer foo<2>>
The question is therefore if two calls from the same buffer, using the
same limit, should overwrite the derived buffer, or simply create a new
one.
I don't have a strong opinion about that (If someone else has an opinion
they can certainly chime in). Buffers are cheap, but you also may not
want to spam buffers. Feel free to make that as you see fit.

Post by Fran Burstall
   
     I've added emms-playlist-limit to the documentation.
   
     As I was writing it occurred to me that
     `emms-playlist-limit-to-all'
     perhaps should not kill the derived buffer. At least not

without

Post by Fran Burstall
     adding
     a mention of that to the function documentation, which

currently

Post by Fran Burstall
     simply
     reads:   "Show all tracks again."
   
     --
        "Cut your own wood and it will warm you twice"
   
     _______________________________________________
     Emms-help mailing list
     https://lists.gnu.org/mailman/listinfo/emms-help

--
   "Cut your own wood and it will warm you twice"
_______________________________________________
Emms-help mailing list
https://lists.gnu.org/mailman/listinfo/emms-help

[Fran Burstall]

Post by Yoni Rabkin

Post by Fran Burstall
Hi,
Look in the emms-playlist-limit branch for a new version of
emms-playlist-limit.el that operates on the playlist in the current
buffer rather than the current playlist. While I was there, I tried
to make the doc-strings a little more expressive.

It seems to work well (haven't tried it a lot.) This can be merged into
master.

Will do.

Post by Yoni Rabkin
I pushed a small patch to fix the copyright header.

Thanks!

Post by Yoni Rabkin
Meanwhile, I just got burned by emms-playlist-sort having the same

Post by Fran Burstall
behaviour: no matter what playlist buffer you hit "S a" in, it is the
current playlist that gets sorted by info-artist. I was mashing the
keys and not understanding why the playlist I was looking at did not
sort!
If you agree that this is a bug, I am happy to fix...

I'm going to go ahead and say that probably anywhere this behavior is
found it is a bug, or at least an older and unwanted behavior. Care
would need to be taken to read the respective doc-strings in case they
explicitly mention acting on the current buffer.

OK---I will have a look at emms-playlist-sort.el with that in mind.

---Fran

[Yoni Rabkin]

Post by Fran Burstall
Hi,
Look in the emms-playlist-limit branch for a new version of
emms-playlist-limit.el that operates on the playlist in the current
buffer rather than the current playlist.  While I was there, I tried
to make the doc-strings a little more expressive.
Meanwhile, I just got burned by emms-playlist-sort having the same
behaviour: no matter what playlist buffer you hit "S a" in, it is the
current playlist that gets sorted by info-artist.  I was mashing the
keys and not understanding why the playlist I was looking at did not
sort!  
If you agree that this is a bug, I am happy to fix...

It of course goes without saying they you would need to be curatorial in
your application of these fixes; functions such as `emms-next'
definitely need to act only on the current playlist buffer.

Post by Fran Burstall
---Fran

Post by Fran Burstall
Here I was replicating the previous behaviour.
Thinking about it: if I don't kill the buffer and I later run

the

Post by Fran Burstall
same limiting action, I will want to at least clear the derived
buffer so as not to present stale results.  So maybe better to

just

Post by Fran Burstall
kill it and document it in the doc-string.  Either way, I agree

that

Post by Fran Burstall
the current doc-string does not capture what the function

does. 

Post by Fran Burstall
What do you think?  Kill the derived buffer or not? 

It wouldn't really present stale results since each call to
`emms-playlist-new' creates a unique, numbered buffer.
(emms-playlist-new "foo") => #<buffer foo>
(emms-playlist-new "foo") => #<buffer foo<2>>
The question is therefore if two calls from the same buffer, using the
same limit, should overwrite the derived buffer, or simply create a new
one.
I don't have a strong opinion about that (If someone else has an opinion
they can certainly chime in). Buffers are cheap, but you also may not
want to spam buffers. Feel free to make that as you see fit.

Post by Fran Burstall
   
     I've added emms-playlist-limit to the documentation.
   
     As I was writing it occurred to me that
     `emms-playlist-limit-to-all'
     perhaps should not kill the derived buffer. At least not

without

Post by Fran Burstall
     adding
     a mention of that to the function documentation, which

currently

Post by Fran Burstall
     simply
     reads:   "Show all tracks again."
   
     --
        "Cut your own wood and it will warm you twice"
   
     _______________________________________________
     Emms-help mailing list
     https://lists.gnu.org/mailman/listinfo/emms-help

--
   "Cut your own wood and it will warm you twice"
_______________________________________________
Emms-help mailing list
https://lists.gnu.org/mailman/listinfo/emms-help

[Fran Burstall]

Post by Yoni Rabkin

Post by Fran Burstall
If you agree that this is a bug, I am happy to fix...

It of course goes without saying they you would need to be curatorial in
your application of these fixes; functions such as `emms-next'
definitely need to act only on the current playlist buffer.

Very true!

[Mike Kazantsev]

On Tue, 25 Sep 2018 16:00:00 -0400

Post by Yoni Rabkin

Post by Fran Burstall
What do you think?  Kill the derived buffer or not? 

The question is therefore if two calls from the same buffer, using the
same limit, should overwrite the derived buffer, or simply create a new
one.

I think it's a good idea that "/ /" key combo operates in the same
limit-buffer without killing it, as if I want the other behavior,
it's easy to just kill this limited buffer as you'd do with any regular
buffer and switch to original playlist.

[Fran Burstall]

Post by Mike Kazantsev
I think it's a good idea that "/ /" key combo operates in the same
limit-buffer without killing it, as if I want the other behavior,
it's easy to just kill this limited buffer as you'd do with any regular
buffer and switch to original playlist.

Agreed. The implementation on master simply buries the limited buffer on
"/ /".

---Fran

[Mike Kazantsev]

On Mon, 24 Sep 2018 20:23:15 +0100

Post by Fran Burstall
Have a look at branch emms-playlist-limit for a re-write of
emms-playlist-limit.el. This is my first piece of elisp for public
consumption so criticism very welcome and almost certainly necessary.

It's not an elisp complaint, but more of a feature request:

As I wanted to try out limiting feature, looking at playlist buffer,
first thing that came to mind is to limit it by regexp going over what
is displayed there.

That's probably the most relevant info, encompassing several fields
that user cares about, which is why emms-track-description-function
is set to display these.

And unfortunately, there doesn't seem to be an option for that,
only for filtering over attributes of internal track representation.
Unless I just missed it, that is...

[Yoni Rabkin]

Post by Mike Kazantsev
On Mon, 24 Sep 2018 20:23:15 +0100

Post by Fran Burstall
Have a look at branch emms-playlist-limit for a re-write of
emms-playlist-limit.el. This is my first piece of elisp for public
consumption so criticism very welcome and almost certainly necessary.

As I wanted to try out limiting feature, looking at playlist buffer,
first thing that came to mind is to limit it by regexp going over what
is displayed there.
That's probably the most relevant info, encompassing several fields
that user cares about, which is why emms-track-description-function
is set to display these.
And unfortunately, there doesn't seem to be an option for that,
only for filtering over attributes of internal track representation.
Unless I just missed it, that is...

There is no problem implementing such a feature. But since many people
(myself included) modify `emms-track-description-function', such as
feature must not make any assumptions about what is being displayed,

[Mike Kazantsev]

On Fri, 05 Oct 2018 09:39:56 -0400

Post by Yoni Rabkin

Post by Mike Kazantsev
And unfortunately, there doesn't seem to be an option for that,
only for filtering over attributes of internal track representation.
Unless I just missed it, that is...

There is no problem implementing such a feature. But since many people
(myself included) modify `emms-track-description-function', such as
feature must not make any assumptions about what is being displayed,

Yeah, that's actually why internal fields aren't good enough in my
use-case either - track-description-function can use stuff from bunch
of different tags, fallback to filename (splitting file/directory
names into fields), replace underscores with spaces and do all sorts of
other tweaks there.

So it's hard or even impossible to tell what to match from internal
fields from just looking at such playlist buffer.

[Fran Burstall]

Post by Mike Kazantsev
On Fri, 05 Oct 2018 09:39:56 -0400

Post by Yoni Rabkin

Post by Mike Kazantsev
And unfortunately, there doesn't seem to be an option for that,
only for filtering over attributes of internal track representation.
Unless I just missed it, that is...

There is no problem implementing such a feature. But since many people
(myself included) modify `emms-track-description-function', such as
feature must not make any assumptions about what is being displayed,

Yeah, that's actually why internal fields aren't good enough in my
use-case either - track-description-function can use stuff from bunch
of different tags, fallback to filename (splitting file/directory
names into fields), replace underscores with spaces and do all sorts of
other tweaks there.
So it's hard or even impossible to tell what to match from internal
fields from just looking at such playlist buffer.

Have a look at a new version on the emms-playlist-limit branch.

Now "/ d" filters by regexp on what the playlist buffer shows (strictly, on
what `emms-track-description-function' returns for each track). I hope
this gives what Mike wants while addressing Yoni's concern.

---Fran

[Mike Kazantsev]

On Sat, 6 Oct 2018 00:03:59 +0100

Post by Fran Burstall
Have a look at a new version on the emms-playlist-limit branch.
Now "/ d" filters by regexp on what the playlist buffer shows (strictly, on
what `emms-track-description-function' returns for each track). I hope
this gives what Mike wants while addressing Yoni's concern.

Indeed it works and is very useful, thanks!

Also very intuitive to me how to use such limiting in general,
as it's same pattern as with ibuffer and such using the / key.

One random small thing I've noticed at the top of "git log -u
origin/emms-playlist-limit":

diff --git a/lisp/emms-playlist-limit.el b/lisp/emms-playlist-limit.el
index 5f0cb28..9fcc74b 100644
--- a/lisp/emms-playlist-limit.el
+++ b/lisp/emms-playlist-limit.el
@@ -45,6 +45,7 @@
;; / a emms-playlist-limit-to-info-artist
;; / b emms-playlist-limit-to-info-album
;; / c emms-playlist-limit-to-info-composer
+;; / d emms-playlist-limit-to-description
;; / g emms-playlist-limit-to-info-genre
;; / n emms-playlist-limit-to-name
;; / p emms-playlist-limit-to-info-performer
@@ -79,11 +80,11 @@ the current playlist." attribute)

^^^ it looks like a tab slipped-in there among spaces or vice-versa.

[Fran Burstall (Gmail)]

Post by Mike Kazantsev
On Sat, 6 Oct 2018 00:03:59 +0100

Post by Fran Burstall
Have a look at a new version on the emms-playlist-limit branch.
Now "/ d" filters by regexp on what the playlist buffer shows (strictly,

on

Post by Fran Burstall
what `emms-track-description-function' returns for each track). I hope
this gives what Mike wants while addressing Yoni's concern.

Indeed it works and is very useful, thanks!
Also very intuitive to me how to use such limiting in general,
as it's same pattern as with ibuffer and such using the / key.
One random small thing I've noticed at the top of "git log -u
diff --git a/lisp/emms-playlist-limit.el b/lisp/emms-playlist-limit.el
index 5f0cb28..9fcc74b 100644
--- a/lisp/emms-playlist-limit.el
+++ b/lisp/emms-playlist-limit.el
@@ -45,6 +45,7 @@
;; / a emms-playlist-limit-to-info-artist
;; / b emms-playlist-limit-to-info-album
;; / c emms-playlist-limit-to-info-composer
+;; / d emms-playlist-limit-to-description
;; / g emms-playlist-limit-to-info-genre
;; / n emms-playlist-limit-to-name
;; / p emms-playlist-limit-to-info-performer
@@ -79,11 +80,11 @@ the current playlist." attribute)
^^^ it looks like a tab slipped-in there among spaces or vice-versa.

Well spotted. Now fixed.

---Fran

[Fran Burstall (Gmail)]

Post by Fran Burstall (Gmail)

Post by Mike Kazantsev
On Sat, 6 Oct 2018 00:03:59 +0100

Post by Fran Burstall
Have a look at a new version on the emms-playlist-limit branch.
Now "/ d" filters by regexp on what the playlist buffer shows

(strictly, on

Post by Fran Burstall
what `emms-track-description-function' returns for each track). I hope
this gives what Mike wants while addressing Yoni's concern.

Indeed it works and is very useful, thanks!
Also very intuitive to me how to use such limiting in general,
as it's same pattern as with ibuffer and such using the / key.
One random small thing I've noticed at the top of "git log -u
diff --git a/lisp/emms-playlist-limit.el b/lisp/emms-playlist-limit.el
index 5f0cb28..9fcc74b 100644
--- a/lisp/emms-playlist-limit.el
+++ b/lisp/emms-playlist-limit.el
@@ -45,6 +45,7 @@
;; / a emms-playlist-limit-to-info-artist
;; / b emms-playlist-limit-to-info-album
;; / c emms-playlist-limit-to-info-composer
+;; / d emms-playlist-limit-to-description
;; / g emms-playlist-limit-to-info-genre
;; / n emms-playlist-limit-to-name
;; / p emms-playlist-limit-to-info-performer
@@ -79,11 +80,11 @@ the current playlist." attribute)
^^^ it looks like a tab slipped-in there among spaces or vice-versa.

Well spotted. Now fixed.

OK to merge this into master?

---Fran

[Yoni Rabkin]

On Sat, 6 Oct 2018 at 09:11, Fran Burstall (Gmail) <
On Sat, 6 Oct 2018 00:03:59 +0100

Post by Fran Burstall
Have a look at a new version on the emms-playlist-limit

branch.

Post by Fran Burstall
Now "/ d" filters by regexp on what the playlist buffer

shows (strictly, on

Post by Fran Burstall
what `emms-track-description-function' returns for each

track).  I hope

Post by Fran Burstall
this gives what Mike wants while addressing Yoni's concern.

Indeed it works and is very useful, thanks!
Also very intuitive to me how to use such limiting in
general,
as it's same pattern as with ibuffer and such using the / key.
One random small thing I've noticed at the top of "git log -u
  diff --git a/lisp/emms-playlist-limit.el b/lisp/
emms-playlist-limit.el
  index 5f0cb28..9fcc74b 100644
  --- a/lisp/emms-playlist-limit.el
  +++ b/lisp/emms-playlist-limit.el
   ;;  / a   emms-playlist-limit-to-info-artist
   ;;  / b   emms-playlist-limit-to-info-album
   ;;  / c   emms-playlist-limit-to-info-composer
  +;;  / d         emms-playlist-limit-to-description
   ;;  / g   emms-playlist-limit-to-info-genre
   ;;  / n   emms-playlist-limit-to-name
   ;;  / p   emms-playlist-limit-to-info-performer
^^^ it looks like a tab slipped-in there among spaces or vice-versa.
Well spotted.  Now fixed.
OK to merge this into master?

Please do.

More generally: unless it's a terribly dramatic change, please feel free
to merge into master at your discretion.

[Fran Burstall (Gmail)]

Post by Yoni Rabkin

On Sat, 6 Oct 2018 at 09:11, Fran Burstall (Gmail) <
On Sat, 6 Oct 2018 00:03:59 +0100

Post by Fran Burstall
Have a look at a new version on the emms-playlist-limit

branch.

Post by Fran Burstall
Now "/ d" filters by regexp on what the playlist buffer

shows (strictly, on

Post by Fran Burstall
what `emms-track-description-function' returns for each

track). I hope

Post by Fran Burstall
this gives what Mike wants while addressing Yoni's concern.

Indeed it works and is very useful, thanks!
Also very intuitive to me how to use such limiting in general,
as it's same pattern as with ibuffer and such using the / key.
One random small thing I've noticed at the top of "git log -u
diff --git a/lisp/emms-playlist-limit.el b/lisp/
emms-playlist-limit.el
index 5f0cb28..9fcc74b 100644
--- a/lisp/emms-playlist-limit.el
+++ b/lisp/emms-playlist-limit.el
@@ -45,6 +45,7 @@
;; / a emms-playlist-limit-to-info-artist
;; / b emms-playlist-limit-to-info-album
;; / c emms-playlist-limit-to-info-composer
+;; / d emms-playlist-limit-to-description
;; / g emms-playlist-limit-to-info-genre
;; / n emms-playlist-limit-to-name
;; / p emms-playlist-limit-to-info-performer
@@ -79,11 +80,11 @@ the current playlist." attribute)
^^^ it looks like a tab slipped-in there among spaces or vice-versa.
Well spotted. Now fixed.
OK to merge this into master?

Please do.

Done.

Meanwhile, I was going to document emms-playlist-limit-to-description and
was about to add to emms.texinfo:

@item / d
@kindex / d
@findex emms-playlist-limit-to-description
Create a new playlist buffer and populate it with tracks
whose track description matches the given regular
expression (default: the track description of the
track at point).

when I noticed that the other entries do not mention that the
emms-playlist-limit-to-* functions take a regexp as argument.

Was that deliberate to keep things short? Shall I follow suit?

---Fran

[Yoni Rabkin]

Post by Yoni Rabkin

On Sat, 6 Oct 2018 at 09:11, Fran Burstall (Gmail) <
   
   
     On Sat, 6 Oct 2018 at 03:31, Mike Kazantsev <
   
         On Sat, 6 Oct 2018 00:03:59 +0100
       
         > Have a look at a new version on the

emms-playlist-limit

         branch.
         >
         > Now "/ d" filters by regexp on what the playlist

buffer

         shows (strictly, on
         > what `emms-track-description-function' returns for

each

         track).  I hope
         > this gives what Mike wants while addressing Yoni's

concern.

       
         Indeed it works and is very useful, thanks!
       
         Also very intuitive to me how to use such limiting in
         general,
         as it's same pattern as with ibuffer and such using the

/

         key.
       
         One random small thing I've noticed at the top of "git

log -u

       
           diff --git a/lisp/emms-playlist-limit.el b/lisp/
         emms-playlist-limit.el
           index 5f0cb28..9fcc74b 100644
           --- a/lisp/emms-playlist-limit.el
           +++ b/lisp/emms-playlist-limit.el
            ;;  / a   emms-playlist-limit-to-info-artist
            ;;  / b   emms-playlist-limit-to-info-album
            ;;  / c   emms-playlist-limit-to-info-composer
           +;;  / d         emms-playlist-limit-to-description
            ;;  / g   emms-playlist-limit-to-info-genre
            ;;  / n   emms-playlist-limit-to-name
            ;;  / p   emms-playlist-limit-to-info-performer
       
         ^^^ it looks like a tab slipped-in there among spaces

or

         vice-versa.
   
   
     Well spotted.  Now fixed.
OK to merge this into master?

Please do.
Done.  
Meanwhile, I was going to document emms-playlist-limit-to-description
@item / d
@kindex / d
@findex emms-playlist-limit-to-description
Create a new playlist buffer and populate it with tracks
whose track description matches the given regular
expression (default: the track description of the
track at point).
when I noticed that the other entries do not mention that the
emms-playlist-limit-to-* functions take a regexp as argument. 
Was that deliberate to keep things short?  Shall I follow suit?

Probably my oversight. Please add as much documentation as you can. The
manual is the long/tl;dr form.

Please make sure the file generates (makeinfo can be persnickety) after
editing.

thanks!

Post by Yoni Rabkin
---Fran

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

[Fran Burstall]

Hi Mike,

You are right that:

1. The feature is not there.

2. It ought to be.

I will have a look at that.

---Fran

Post by Mike Kazantsev
On Mon, 24 Sep 2018 20:23:15 +0100

Post by Fran Burstall
Have a look at branch emms-playlist-limit for a re-write of
emms-playlist-limit.el. This is my first piece of elisp for public
consumption so criticism very welcome and almost certainly necessary.

As I wanted to try out limiting feature, looking at playlist buffer,
first thing that came to mind is to limit it by regexp going over what
is displayed there.
That's probably the most relevant info, encompassing several fields
that user cares about, which is why emms-track-description-function
is set to display these.
And unfortunately, there doesn't seem to be an option for that,
only for filtering over attributes of internal track representation.
Unless I just missed it, that is...
--
Mike Kazantsev // fraggod.net