The attached ttyrecord file was generated by running vim, entering a few
lines, and exiting. When I try to play this back with ttyplay, it
plays back the command line part of the session, but then displays:

this is
~
~
~
~
...
~
-- INSERT --

And stalls forever. The amount of text that it shows
varies, but the stall does not. Pressing a key does not
skip ahead. A strace of ttyrec is attached, it shows it
stalling in a select.

Apparently this code in ttyplay is firing:

        case '0':
            speed = 0.0;
            break;

But, I am *not* pressing 0 on the keyboard!

The full text that ttyplay reads from stdin looks like this:

^[[>1;2801;0c

So vim originally sends a terminal escape sequence that causes the
terminal to respond with this, and the playback causes this to reoccur,
and be misinterpreted as a user pause request. I have not tried to look
up what the terminal response code here is used for, but there seem to
be several standard ones. http://www.termsys.demon.co.uk/vtansi.htm

One approach to fix this would be to ignore incoming terminal escape
sequences that come immediately after '\e'. An alternate approach
would be to try to filter out the recorded escape sequences that would
result in such responses. Another option would be to stop treating 0 and
1 on stdin as pause/unpause, and instead perhaps let the user press the
space bar to toggle playback. I've attached a patch that does that.

BTW, I can reproduce the problem with recordings taken in xterm and sakura
(a VTE based emulator), but not at the linux console.