Ugh, it's been in front of my eyes all along. The logs have been
repeatedly showing a recurrence within a single frame:
key press -> update Viewport.y from screen_top -> A -> B -> update_editor_box -> update screen_top from Viewport.y
We need both those updates, but both should never occur at the same
time to the same node.
I think this is why screen panning works if I take out the scale inside
update_editor_box: the scale has already happened "once" in
updating Viewport.y, and it doesn't converge if we perform it a second
time in a frame. But the solution is just to do one or the other to a
node, never both.
I knew this (learned it the hard way) when I first built pensieve.love,
and I had an assertion to avoid it. But my assertion was brittle, and it
kept failing, and I took it out, and then I slowly took out all the code
that prevented this recurrence.
I might have finally hit on the right approach: a hotkey that dumps
information. Doesn't swamp me with data, and also doesn't perturb
anything.
y_of_schema1 returns consistent results as I pan around.
I'm just not actually printing the lines at that y. I'm printing it at
that y/Viewport.zoom.
What might be confusing here is that I started out with a simple mental
model:
* perform computations in surface coordinates (sx,sy)
* render in viewport coordinates (vx,vy)
But for text quality reasons I need to perform many computations in
"scaled surface" coordinates.
Viewport coordinates are both offset and scaled relative to surface
coordinates. Scaled surface = just scaled relative to surface, not
offset.
I don't have a clear mental model here for when to use this.
I did already use it in one place with my simple mental model: you have
to scale distances like rect.w and rect.h but it's incorrect to offset
them. Maybe I'm getting this wrong somehow.