Forums Feature Suggestions /play -E[n] - Execute next iteration(s)

When using /play there is not a script-accessible way to progress a currently /play'ing buffer. I suggest the following:

/play -E[n]
Plays the next line of the buffer.
if n is specified the next n lines are handled
if n is specified as 0 the rest of the buffer is handled

Specifics:
The -E switch can be used, with other switches, to create a new play buffer instance. If used as such an initial number of lines will be played immediately within the script execution block.

If the -c switch is specified with -E, lines to be evaluated should be done so within the script execution block allowing such lines access to local variables and aliases. If done so on a pre-existing play buffer only the lines to be handled as a result of the /play -E call should be evaluated as such.





Example#1 - Progressing a Buffer:

Example #2 - Initial Line Handling

Example #3 - Scoping

I don't understand the use case for this switch.

The use case for /play is to explicitly handle delayed execution of line reads. I don't see why you would want to handle any lines "immediately". If you want to do this, it seems like you should just loop over the file yourself and generate your own timings. It's fairly easy to do manually. Specifically, your examples that read the first N lines and play the rest can be easily solved by looping over the first N lines and then calling /play on the N+1th line. It's only one extra line of code:



It also seems like this suggestion doesn't really deal with state leak and data race conditions. Looking at /example1, I'm trying to understand what the expected behavior would be if mIRC was already /playing another file. Consider the two lines of code:



The /example1 alias would call /play on example.txt, but that would queue the file, not play it, at which point, what exactly is /play -E expected to be doing? Should it wait until example1.txt is being played? Or should it play the first line of test.txt? I can only guess that typical implementation would cause the latter to happen, which is likely not what you want. Also, what would happen if /play was used with -a that called an alias that then called /play (to queue up a follow up play command). I'm not sure how you could get what you want to happen in all cases.

Basically, the big technical problem with this suggestion is that it assumes state preservation across calls when no such state is guaranteed. You simply can't assume that /play -E is necessarily acting on the last /play call because you can't control what the last /play call is. It may seem obvious in your simplistic examples, but it will break very quickly in more complex usage.

And for such an unreliable command, I don't see such a big use case anyway. I'm dubious about needing to trigger /play immediately, given its actual intended purpose.

It all started because he wanted to execute a command on all the lines in a file as the parameter.
Easily done with filter -k and executing the command in the alias, but the main idea was to do this more efficiently.
It happens that /play can actually execute lines as command, and in his case, he could simply write the command to the file before the 'parameter' (the file is built right before that, with JS, not mirc scripting), and voilà, that's the idea behind this suggestion.

I agree though, there are simply too much issues with his current suggestion and with the way /play works anyway. On IRC I suggested this would be much better implemented in /filter, which has the synchrone/blocking call behavior, no delay, no queue, it's only a matter of a new switch to execute the lines matched as command. If anything, a new command /execfile could be added to do this specifically but imo it's not worth it, a switch in filter is just better, "/filter -m <infile> <matchtext>" feels so much better...

Worth nothing that /play may benefit from a new switch to evaluate the line like $read does, but that should be a seperate feature.