diff options
author | Kartik K. Agaram <vc@akkartik.com> | 2017-06-23 14:09:11 -0700 |
---|---|---|
committer | Kartik K. Agaram <vc@akkartik.com> | 2017-06-23 15:39:14 -0700 |
commit | b1e558cfe42029df630e1c2d9399d4b52c187801 (patch) | |
tree | 35fba14030c48c8e3a5e1792ffef9a84095cfe85 /087file.cc | |
parent | 0bf322d6f04c28d4b38eb07f5ee9bd588187a058 (diff) | |
download | mu-b1e558cfe42029df630e1c2d9399d4b52c187801.tar.gz |
3941
Even though the bug of commit 3938 is now fixed, I'm still trying to track down why the failure looked different on the fake screen than on the real one. Snapshot as I try to track down the difference. One key lesson is that the approach of commit 3860 -- updating the cursor before rather than after printing each character -- turns out to be untenable. A sequence of `print` followed by `cursor-position` needs to behave the same as the real screen. But it's still not clear how the real screen. When you get to the end of a line the cursor position wraps after print to the left margin (column 0) on the next row. When you get to the bottom right the cursor position wraps to the *bottom left* margin. How the heck does it know to scroll on the next print, then? Is there some hidden state in the terminal?
Diffstat (limited to '087file.cc')
0 files changed, 0 insertions, 0 deletions