[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [emms-help] [patch] move tracks in playlist

From: Rasmus
Subject: Re: [emms-help] [patch] move tracks in playlist
Date: Mon, 25 May 2015 00:30:50 +0200
User-agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux)

Yoni Rabkin <address@hidden> writes:

> I'm afraid that having separate track and track-string arguments to the
> insert function would be inviting a lot of breakage and confusion down
> the road,

I can create a separate function if that's better.  Or make the moving
function monolithic.

> and separate M-up and M-down keys don't make sense.

I don't understand this part.  We can add support for moving tracks via
killing as well, Emacs way.

M-{up, down} is how stuff is moved around in Org.

> The playlist wasn't designed to display covers, different faces, have
> indentation, etc. This is because you are trying to use
> emms-playlist-mode for stuff that it wasn't designed for. The playlist
> mode isn't messy, it's just that trying to shoehorn a graphical UI into
> a mode which is a vertical list of textual lines is very messy. This is
> by design.

OK.  The fact that emms-add-... and that emms-browser-add (or whatever)
uses different functions is messy.  There should be one function to add
tracks to the playlist to ensure consistency.

> I don't use the browser; I don't need or want anything but a single line
> of non-fancy, non-indented simple text per track without pictures,
> photos or covers etc.. I want my playlist to be as close to a regular
> Emacs buffer with normal Emacs movements as possible (both visually and
> in terms of key-bindings, if I wanted something else, I wouldn't be
> using Emacs but a player with a graphical UI.)

In this case it's like an Org buffer.  In any case, I respect your

> The solution is either for you to create a separate playlist mode
> designed from the ground up for the browser, or for me to create
> something like emms-purelist-mode or something, which continues to serve
> my purposes (and the purposes of other people with eye problems, who
> need as little graphical fanciness as possible). In either case, after
> the split, you would be able to make the changes you need without
> unnecessarily overloading the playlist mode with exceptions and
> additional code paths, and you won't need to worry about whether your
> design is breaking anything for people like me who need to the playlist
> buffer to remain the same.

Would that not break emms-add-whatever?  Anyway, it could be interesting


Vote for proprietary math!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]