per /help $timer
"$timer(3).secs returns number of seconds left before timer is triggered"
In this example, the portions after "timername:" are identical identifiers:
//timerbar 12 1 echo 6 -ag bar: secs $!timer(foo).secs reps $!timer(foo).reps | /timerfoo 2 5 echo 4 -ag foo: secs $!timer(foo).secs reps $!timer(foo).reps
Bug: on the last execution of the timer (or the only execution if you change "2 5" to "1 5", the .secs property jumps up to either .DELAY or .DELAY-1sec even though it immediately halts right after displaying the 4 or 5. It should show 0 because that timer will not be triggered again. This non-zero .secs also happens with -h or -m when using intervals of 1004ms or greater and shows 0 with lesser ms intervals, though I'm sure that number will vary depending on the OS and cpu speed.
This also happens if you use -e to accelerate the one-and-only time the timer executes, except in this situation .secs shows the final countdown at the time -e triggered the execution instead of .delay-1sec. Again, it's a non-zero value that should be showing 0 because that timer will not be executed again:
//timerfoo 1 999 echo 4 -ag foo: secs $!timer(foo).secs reps $!timer(foo).reps | timerbar 1 9 echo 6 -ag secs $!timer(foo).secs reps $!timer(foo).reps | timerfoobar 1 10 timerfoo -e
Regarding backwards compatibility with existing scripts, it's not needed to have the final execution show non-zero .secs in order to allow timers to revive themselves, because they should be using .delay instead of .secs. Since .secs is often (.delay -1sec), a timer that used its own .secs to revive itself will quickly find itself with a delay decrementing to 0.
