Add new entry next in the queue with /qan

[girlmaya]

I often find myself adding a video to the queue with /qa, and then dragging the video up to the point in the queue below the current video. A /qan command would simplify the process.
A /qans command (queue add next and select) would also be useful, though the command would probably need a better name.

[Et0h]

These additional commands seem reasonable to me and shouldn't be too hard to code. I actually half thought we might already had a queue next feature so had to double check (you can see I mostly use the GUI) because it seems like a common enough use case for CLI users. The downside is of course that it adds yet more commands which could be a bit daunting to non-power users, but they will mostly use the GUI rather than CLI in any case.

Based on the other commands I think /qan and /qans seem like logical names as we use 'qa for queue add, 'qas' for queue add and select' and 'qn' for select next in queue and so this would just be re-using the existing meanings.

However, I get your point that /qans is a bit cumbersome and we don't have any other three letter commands.

One shorter and therefore less cumbersome alternative to /qans would be /qns which could be seen as queue (add) next and select. What it misses is the 'a' for adding to the queue which the other commands to add to the queue all have, and it could make one think that /qn is queue add next which it is not (it is instead play next in queue). /qas for queue add (next) and select would be shorter but problematic for similar reasons as it would be skipping the 'next' part of the logic and so its behaviour could be confused with /qa which adds to the bottom of the playlist.

As such, both of the alternatives that seem to have a clear rationale would miss out an important element that could allow for it to be confused with a different behaviour. The consequences of the wrong behaviour is small and people can learn, but there is a trade off between short command line switches on the one hand and easy to associate the command and the logic in ones memory on the other.

Another alternative to /qans is /qasn for queue add select next, which therefore extends /qas with 'n' rather than /qan with 's'. This would probably have been equally good if the command was introduced at the same time as all the others, but it might make sense for all new commands introduced at the same time to be more consistent with each other as people would need to learn them both at the same time and so would associate the command more as a /qan with select than a /qas with next.

Happy to hear people's thoughts on this.

[girlmaya]

I agree it's a bit tricky and don't really have a preference on the options you gave. But here's another option:

If you were to rework the queue commands entirely, we could have /queue add <file> (/q a <file>), with additional flags (for the add subcommand) like /queue add --next <file> (/q an <file>) and /queue add --select <file> (/q as <file>). These should be able to be combined so that the user would be able to use /q ans <file> or /q asn <file> to add a video next in the queue, and select it for playback. Other existing queue management commands like /ql, /qs, /qn, /qd could get their own /queue subcommands (list, select/sel, next, delete/del), possibly even keeping the old commands as aliases. That way the only old command that would break is /queue, though I'd guess most people (including me) typically use /qa, which currently does the same thing.

I assume (without having looked at the code) that this would involve a rework of the command system. I don't think this is the absolute necessary solution, nor am I sure it is even better than simply adding /qan and /qans (might be a bit too convoluted). Just a suggestion.

FYI I am not a CLI user - I use the GUI but add to the queue with /qa (usually from youtube).

[Et0h]

If there were any changes to rationalise things then I'd still probably want the old commands to still work for backwards compatibility reasons.

I will tag some people who have made commits or issue comments relating to CLI to give them an opportunity to comment on these proposed changes: @crabdancing @gospodin55 @rtix @csandras05 @odrling @xNinjaKittyx @luke-jr

[odrling]

If you were to rework the queue commands entirely, we could have /queue add <file> (/q a <file>), with additional flags (for the add subcommand) like /queue add --next <file> (/q an <file>) and /queue add --select <file> (/q as <file>). These should be able to be combined so that the user would be able to use /q ans <file> or /q asn <file> to add a video next in the queue, and select it for playback. Other existing queue management commands like /ql, /qs, /qn, /qd could get their own /queue subcommands (list, select/sel, next, delete/del), possibly even keeping the old commands as aliases. That way the only old command that would break is /queue, though I'd guess most people (including me) typically use /qa, which currently does the same thing.

I assume (without having looked at the code) that this would involve a rework of the command system. I don't think this is the absolute necessary solution, nor am I sure it is even better than simply adding /qan and /qans (might be a bit too convoluted). Just a suggestion.

While it feels instinctively right to implement commands this way, I feel like in practice most users would still prefer to use short aliases in Syncplay (if they even use them) because having more characters to type means you have more chances to make a typo (and it also just takes more time).

That said I think a good thing that could come from having longer commands (without necessarily implementing subcommands and flags) is user defined aliases. These aliases could still default to mimicking the commands we have currently to keep backwards compatibility, and then it would be possible e.g. to alias the /t command to /r (which then would replace the /r alias) and /qa to /a.