Will not survive window resizing

[karelbilek]

When you start asciinema in a large terminal window, then resize the window (during recording) to smaller size, the video comes out all wrong.

Interestingly enough, it survives well in the opposite way.

In this example, I run sl - my favourite program - in a big terminal window, then resize the window to small window (that's the "awkward pause" - me resizing the window) and run sl again. The second run looks OK, but the first is mangled.

https://asciinema.org/a/5wvarzb4545pohhfqnj8g9fta

For illustration, this is opposite example. Starting small, then resizing to big. Both runs work well.

http://asciinema.org/a/d9u278gcavlymvywrleh0kbup

[ku1ik]

asciinema doesn't record screen but the stdout stream. It also saves the current terminal dimensions at the end of the recording session. Some terminal apps (as sl) are depending on the actual terminal size. They produce escape sequences that are suited for the current terminal width/height at any given point in time. Because asciinema player actually interprets/executes recorded stdout, these escape sequences are executed against the current asciinema terminal size.

In other words, to solve this problem asciinema would need to save the terminal resize events (this can be done) and then use them to resize its own "terminal" during the playback. However, that would cause the resizing of the player itself, which would look funny (when replayed on asciinema.org) and be impractical (when embedded on a site).

[karelbilek]

I understand the challenges and I understand if you don't want to fix it, I just wanted to let you know.

It could be solved by making the player the maximal width of all the widths and the maximal height of all the heights and the text could be in top left - it would be the same case as if you start with small terminal and end with big terminal. I don't know if it's worth fixing though :)

[ku1ik]

It's not that I don't want to fix it, but there are more subtleties with this (your proposed solution would still give bad results in some cases). Anyway, this is kind of an edge case, and I'm too not sure if it's worth fixing.

I'm leaving this open though.

[xloem]

This is issue would prohibit casual use of asciinema to record all daily work, creating an irritating limitation to never shrink terminal windows.

[mukkachaitanya]

I think there must be a flexibility for dimens. I had recorded a video (here) and it came out in awkward dimens, i.e. the embedded video took more that the height of the page. Now, I have no choice other than recording again.
I even tried to change the width and height in the .json, which of course didn't work well, as I was having overlapping (this)

P.S Even though this is off topic of the above discussion, this was the closest issue I could find regarding this.

[ku1ik]

@xloem @mukkachaitanya I am designing new recording format (#196). Maybe we could make it support "terminal resize" event...

[safinaskar]

I need some util to "backup" my terminal activity. And, of course, this util should "just work" even if I resize terminal. Maybe there are other programs out there, which support the feature?

[jiangts]

could you shed some light on how to capture the terminal resize event? Would be really useful in a branch I'm working on for realtime asciicasts (and the resize case during recording I'm sure)

[ku1ik]

@jiangts here's the place where the recorder handles terminal resize (SIGWINCH signal): https://github.com/asciinema/asciinema/blob/develop/asciinema/pty_recorder.py#L108

[ku1ik]

The fix is coming asciinema/asciinema-player#244