Data loss when resizing

[blink1073]

Resizing should preserve the existing text.

Details

• Browser and browser version:
• OS version: OSX 10.11
• xterm.js version: 269540b

Steps to reproduce

1. Run the demo
2. Reduce the column count
3. Increase the column count and the original data is not restored.

Iterm2 handles this by reflowing the rows when you decrease the width.

vs.

[parisk]

Thanks for reporting @blink1073. Will take a deeper look on this.

[Tyriar]

I've been closing most of these in favor of #103 but they're technically different issues I guess. Let's use this to track not retaining characters off screen (Related request to support wrapping #166) and #103 to track only the prompt.

[ebertmi]

I've experienced the same errors as I am using xterm.js without a "real" process (I am using https://github.com/skulpt/skulpt). I am just piping in my stdin and stdout streams.

[Tyriar]

I believe fixing this may fix some of the escape sequence tests. I think the reason t0021-CUB.in is failing for example is because the cursor position is reset to 0 after a line is wrapped but it should be cols.

[ppot]

@Tyriar Any input on when this resizing issue will be resolve?

[Tyriar]

@imsnif was handling this one. Still a WIP, see #404

[ppot]

Got it! Looking at it right now.

[imsnif]

Still working on it! :)
I don't yet have an ETA, but am close to finishing a prototype (this is a very big change). Hoping to have more information on the weekend, but I don't want to make any promises.

[ppot]

@imsnif Any input on what you still need to do?

[imsnif]

@ppot - in short: right now in my prototype resize, refresh and write are working with the external line index. There are some kinks I need to work out with them (including some performance issues) and then make sure all the other parts of the code work as well (eraseRight, etc.)

Then pull from upstream (I'm a little behind), write tests, clean everything up and we're good. Once I get the prototype to work (shouldn't be long now, I hope) I'll have a much clearer ETA of when the rest will be done.

[blink1073]

Fixed by #616, thanks @LucianBuzzo!