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

[Yoni Rabkin]

Fran Burstall <address@hidden> 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 <address@hidden> wrote:
>
>     Fran Burstall <address@hidden> 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 <address@hidden>
>     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
>     >    address@hidden
>     >     https://lists.gnu.org/mailman/listinfo/emms-help
>     >
>     >
>     >
>    
>     --
>        "Cut your own wood and it will warm you twice"
>    
>     _______________________________________________
>     Emms-help mailing list
>     address@hidden
>     https://lists.gnu.org/mailman/listinfo/emms-help
>
>
>

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