[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
decision.
> 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
experiment.
Rasmus
--
Vote for proprietary math!