Re: [emms-help] Avoid emms-playlist-current-kill kill the buffer if there're remaining playlists

[Carlos Pita]

Trying to implement the above I realized of a couple of things. First of all,

(defun emms-playlist-mode-current-kill ()
  "If the current buffer is an EMMS playlist buffer, kill it. <---- 0
Otherwise, kill the current EMMS playlist buffer."
  (interactive)
  (if (and emms-playlist-buffer-p  <---- 1
           (not (eq (current-buffer) emms-playlist-buffer)))  <---- 2
      (kill-buffer (current-buffer))
    (emms-playlist-current-kill)))  <---- 3

doesn't really kill the current buffer if it's a playlist buffer but
it happens to be also the current playlist buffer (2) and there is
only a playlist left: it will delegate to emms-playlist-current-kill
(3) which will just bury it since it's the only playlist. This
behavior contradicts the docstring (0). In both cases, I think the
most unsurprising behavior would be that the respective function kills
playlists one by one up to emptying the playlist list, but maybe there
is a good reason to forbid reaching a nil list. Be that as it may, the
docstring of emms-playlist-mode-current-kill is incompatible with its
behavior and the one for emms-playlist-current-kill is rather
ambiguous as noted before. Some action is needed there.

Second, it's quite easy to implement the behavior I suggested (move to
the next playlist instead of leaving emms) since the conjunction of
clauses (1) and (2) ensures that there are at least two playlists (the
one in the current buffer and the current one). Then we can simply
call emms-playlist-mode-next. That is, substitute the then clause
above by:

      (let ((buf (current-buffer)))
        (call-interactively #'emms-playlist-mode-next)
        (kill-buffer buf))

This will move to the next playlist (cycling if at the end of the
list) and kill the previous playlist in case there is two or more
playlists in the list. While this works fine and it's a really minor
change, I'm still unsatisfied with the complexity of what's happening
in emms-playlist-mode-current-kil: two very different paths are being
followed depending on the current buffer containing a playlist that is
current or not. Maybe all this complexity (keeping a non empty list of
playlists, branching depending on the "currentness" of the playlist,
etc.) is necessary, maybe not, what do you think? if it is, the change
above implements what I described in my first email and I could send a
proper patch if you like it; if it isn't necessary, then it might be a
moment to think about it and come to a simpler approach.

Best regards
--
Carlos