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?

1 files changed, 2 insertions, 0 deletions

diff --git a/edit/001-editor.mu b/edit/001-editor.mu
index 807cf442..f7b7fb89 100644
--- a/edit/001-editor.mu
+++ b/edit/001-editor.mu
@@ -207,6 +207,7 @@ def render screen:&:screen, editor:&:editor -> last-row:num, last-column:num, sc
 def clear-screen-from screen:&:screen, row:num, column:num, left:num, right:num -> screen:&:screen [
   local-scope
   load-ingredients
+  stash [clear-screen-from] row column [between] left [and] right
   # if it's the real screen, use the optimized primitive
   {
     break-if screen
@@ -217,6 +218,7 @@ def clear-screen-from screen:&:screen, row:num, column:num, left:num, right:num
   screen <- move-cursor screen, row, column
   clear-line-until screen, right
   clear-rest-of-screen screen, row, left, right
+  screen <- move-cursor screen, row, column
 ]
 
 def clear-rest-of-screen screen:&:screen, row:num, left:num, right:num -> screen:&:screen [