Add a way to tell terminal that interpreter use animation

[jcubic]

I have an idea for a new feature for jQuery Terminal

Some commands may use different forms of animation example echo stuff and use delay in between lines. It would be nice to have API method that can be called to indicate that the interpreter is doing animation, even if it returns a promise.

Possible name Terminal::animate()

Example usage:

$('body').function({
  hello: async function(...args) {
    this.animate();
    for (let arg of args) {
        this.echo(arg);
        await delay(100);
    }
  }
});

Right now async will pause the terminal and wait for the result. It can be a different name instead of animate() since it was reported that someone wanted to use async code to do something and he needed to wrap in an anonymous async function.

TODO:

• [x] Write the code
• [ ] Write unit tests
• [ ] refactor and add this to Terminal collection:
  • [ ] https://codepen.io/jcubic/pen/OJoZWqa?editors=1010
  • [ ] https://codepen.io/jcubic/pen/QWgwVVq?editors=0010

[jcubic]

This can be much better API:

var term = $('body').terminal(function() {
    return this.animation(asyc () => {
        for (let arg of args) {
           await this.echo(arg, { typig: true });
           await delay(100);
        }
    });
});

a single function animation that accepts a function that returns a promise.

[jcubic]

with current API the animation can look like this:

animation: function(fn) {
   paused = true;
   returnn fn().then($.noop);
}

But maybe it would be a good time to refactor this and have a state for animation that is not paused.

[jcubic]

New API https://codepen.io/jcubic/pen/QWgwVVq?editors=0010

[jcubic]

Consider adding simple state machine, with states:

• paused (soft/hard)
• animating
• frozen

[jcubic]

return the animation can be optional since we call a function that is async or note we can manage the state inside without the need to return a promise from the interpreter.

[jcubic]

Revisiting this idea:

There is also a need to hide the prompt between animations. Right now, it doesn't look good that you need to save the prompt before you can animate. It's leaking the implementation details.