Fran Burstall <[email protected]> writes: > 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. > 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. > ---Fran thanks! > > > > > On Tue, 25 Sep 2018 at 21:00, Yoni Rabkin <[email protected]> wrote: > > Fran Burstall <[email protected]> writes: > > > 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. > > > > > On Tue, 25 Sep 2018 at 19:30, Yoni Rabkin <[email protected]> > wrote: > > > > > > 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 > > [email protected] > > https://lists.gnu.org/mailman/listinfo/emms-help > > > > > > > > -- > "Cut your own wood and it will warm you twice" > > _______________________________________________ > Emms-help mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/emms-help > > > -- "Cut your own wood and it will warm you twice" _______________________________________________ Emms-help mailing list [email protected] https://lists.gnu.org/mailman/listinfo/emms-help
