Rudimentary animation API: a sleep that resolves immediately when skipping past a pause #94

Hi! You have made a good piece of software! I feel like I'm currently stretching it to its limit, but it's holding up pretty well.

I'm scripting many animations in my presentation, and I'm hitting the following issue:

1. One script tagged pause exec-at-unpause inserts a series of elements into the DOM, within a loop, with an await sleep(100) after each one
2. The next script, executed at the next unpause, iterates through these DOM elements, and modifies each one.

This works if I let the animation in (1) play out in its entirety before advancing onto (2), but otherwise, the change in (2) will only apply to some of the elements.

The behavior is also wonky if I undo the first unpause while the animations are still playing – my undo function clears out the parent DOM node, but the animation keeps adding new ones afterwards, resulting in a suffix of the sequence of nodes being shown on the screen.

I believe that both issues would be solved if slipshow provided its own sleep promise, with the following additional behavior:

• before performing the actions of the next unpause, make sure that the previous one has finished, by immediately resolving any pending sleeps (up to a fixpoint, since resolving a sleep is likely to schedule another one if there's a loop involved)
• likewise, make sure the action executes fully before starting to undo it
  • conceptually it might also make sense to have that reject the promise instead, but that would create bad interactions with the onUndo hook I previously suggested (and in general create additional hard-to-test codepaths outside of the happy case)