Comment 5 for bug 1453611

My general suggestion is that libvterm ought to have a comprehensive test suite that lists (input, expected output) for every feature and edge case. This is not really specific to libvterm, so you could make it generic and share it across terminal emulators. When there are intentional differences, they could be documented.

What I have in https://github.com/MarkLodato/vt100-parser/tree/master/test is perhaps a good start. It is a collection of input (`<test>.in`) and expected output (`<test>.in` or `<test>.html`), documenting the behavior of xterm (as of 14 years ago!) for an 80x24 window. The way I implemented it was to open a new xterm window, [rawcat](https://github.com/MarkLodato/vt100-parser/blob/master/rawcat) the input file, then copy and paste the output buffer. If there was scrolling, I copied the full scrollback buffer. (This is what my tool is designed to capture, so it is not an exact match for libvterm.)

For example, [t0003-line_wrap.in](https://github.com/MarkLodato/vt100-parser/blob/master/test/t0003-line_wrap.in) keeps outputting longer and longer lines until it is exceeds 80 columns; [t0003-line_wrap.text](https://github.com/MarkLodato/vt100-parser/blob/master/test/t0003-line_wrap.text) shows the expected output.

For the bug in question, [t0084-CBT.in](https://github.com/MarkLodato/vt100-parser/blob/master/test/t0084-CBT.in) exercises the CBT feature. Here my tool and xterm differ, [t0084-CBT.text](https://github.com/MarkLodato/vt100-parser/blob/master/test/t0084-CBT.text) vs [t0084-CBT.text-xterm](https://github.com/MarkLodato/vt100-parser/blob/master/test/t0084-CBT.text-xterm) respectively.

What I am suggesting is that you could take all of my `.in` and `.text` files and create a small test program that runs each through libvterm, comparing the actual output to the `.text` file. That is exactly what I do in [run_all.py](https://github.com/MarkLodato/vt100-parser/blob/master/test/run_all.py) for my tool.

Happy to help if you need more detail!