On 2009/03/24 16:26, Jeffrey Middleton <jefr...@gmail.com> wrote: > mpc: > I've been wanting to improve mpc's options (add host/port, add short > options...). Max recommended using getopt (and getopt_long if available). > Implementing getopt_long is simple enough, and everything is shiny. > Unfortunately, if getopt_long is unavailable, we still need to parse the > long options that have been around a while (--format, --no-status) so we'll > have to do manual parsing anyway.
Right, I forgot about this. > In this case, is there any point in using getopt? Yes, maybe to get the binary size down on systems which support it. Might be interesting for tiny embedded systems. > Extending the current long-only parser to include short options > won't add a whole ton of code, and it'd be great for scripting to be > able to use "mpc -q" instead of "mpc --no-status", so seems worth it > to me. For now, I'd say just extend the current integrated option parser. We might later add a compile-time option for using getopt_long() instead if available, for those users who think saving a few bytes is useful. > >From ncmpc's recent visual selection addition, I noticed that moving a large > block of songs is quite slow because it has to send a command for every song > in the block. Romain's implementation wasn't well optimized. To move a whole block one up or down, it's enough to move just one single song: e.g. to move 4:8 to 3, simply send "move 3 7". > I was going to have it simply move the neighboring song > instead, but it currently uses swapid instead of moveid... which led me to > notice: moveid actually uses a songid and a playlist index, instead of two > songids like the documentation says. Of course, moveid has been this way > since its second-to-initial commit in 2004, so I assume it will stay this > way and the documentation updated. I'll submit a bug report for this later > (patch will be pretty trivial). Good idea. We won't change the real-world behaviour of this command, too much software depends on it, even if that's different from documentation. > Anyway, I figure a moverange command is a reasonable thing to have within > mpd. I've written and tested the queue_move_range function which will be > behind it, but haven't dealt with the command parsing side yet. I figure it > should (like shuffle_range) use the same command, e.g. "move start:end to." Perfect! > That'd mean that the id form would be "moveid start-id:end-id to-index". > I'm not too clear on the reason for using the index for the second argument, > though, so I wanted to make sure. I'm not sure if "moveid" with a range is useful at all. The "moveid" (*id) command was introduced to make some methods safer when more than one client is manipulating the playlist, but we can't make a ranged "moveid" safe. We would need to add additional constraints (like playlist version). Max ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
