Re: [emms-help] Playlist buffer read-only-isms in Emms2

[Jorgen Schaefer]

Yoni Rabkin Katzenell <address@hidden> writes:

> The decision is what kind of restrictions we put on the user in
> the playlist-mode. Do we make it act like Gnus or Dired?

It is not very meaningful to edit the display of tracks. The
operation of editing tracks is, for the user, semantically
equivalent to changing the data which was used to display the
tracks, i.e. the ID3/OGG tag and/or filename, etc. Since the
display is usually less structured than those tags, the playlist
mode shouldn't allow free-form editing because it can't guarantee
that it understands the intent of the user correctly. Like in
emms 1 (IIRC), a tag editor should bind a key of the playlist mode
map, and after anything is changed, it should tell the playlist to
re-display the track.

This means that the playlist buffer should be read-only. It should
still allow useful "intuitive" operations, like C-w, C-k, C-y etc.

Btw, if the core ever gives an error because the playlist buffer
is read-only, that's a bug :-)

> I'm not excluding the ability to enter free text in future, indeed I'm
> writing the playlist-mode without the pretence that every line is a
> track. But text entry will have to have a special command to enter free
> text mode. I think that being able to enter nice labels and titles in
> your playlist mode can be a nice thing.
>
> Other than that, what do people think?

I would agree here, with a single note: If the user can enter
free-form data, the playlist needs to be able to save it. dbrock's
bongo player uses a scheme where he (roughly) just serializes the
whole buffer including properties with (prin1 (buffer-string)),
which would be a useful thing to do here, too, if we allow free
form entry.

Greetings,
        -- Jorgen
-- 
((email . "address@hidden") (www . "http://www.forcix.cx/";)
 (gpg   . "1024D/028AF63C")   (irc . "nick forcer on IRCnet"))