I spent 4 days agonizing over a bug in driver.love, working up the
courage to think about it, and then a whole day trying to make sense of
scrolling and deeply questioning my right to tell anyone anything about
programming.
scenario:
definition extends above and below viewport
position cursor at bottom of viewport
press down arrow
Before this commit, the viewport would sometimes not scroll, and the
cursor would go out of view.
I spent 4 days agonizing over this and working up the courage to think
about it, then a whole day trying to make sense of scrolling and deeply
questioning my right to tell anyone anything about programming, and it's
too early to say I _understand_ this fix. Regardless, it seems clear
that the interplay between edit.lua and update_editor_box and
schema1_to_y is deeply subtle and likely hiding more bugs.
There's still one open issue:
definition starts halfway down the viewport and extends down below viewport
position cursor at bottom of viewport
press down arrow
The surface jarringly scrolls way more than it needs to just to keep the
cursor in view.
And I'm terrified to try to fix this.
Then again, perhaps I should try to port over
bring_cursor_of_cursor_pane_in_view from pensieve.love. That might get
rid of this abyss.
I don't know why this was so hard, but I don't need this variable
preserve_screen_top_of_cursor_node at all. We only set it when the
cursor is in some node, but we also only check for when the current node
is the cursor. Comparing with a nil cursor node works just as well.
I've also checked that driver.love doesn't need
preserve_screen_top_of_cursor_node. I think it came from pensieve.love,
where I've since taken it out. Did I ever need it even there?
This will make things more consistent in the long term, but I realize
one major cost: our button abstraction doesn't work well with luaML and
compute_layout. So we need something to replace it.