It's an interesting blend with my old solution; the new solution acts as
just a safety net.
It makes a couple of situations more jarring, where the screen moves
more than strictly necessary. But the core vibe of my apps is preserved:
the screen only updates when you do something.
Basic idea: If the goal is for the cursor to be on the viewport, focus
the code on ensuring that constraint by construction.
Motivation: The downstream driver.love fork still has persistent bugs.
And I'm seeing some inconclusive signs that edit.lua might be failing to
change screen_top some of the time when it needs to. But this only
happens in driver.love, never in lines.love. So the null hypothesis is
that there's some subtle assumption in lines.love that we're violating
when rendering it on a surface.
What do you do with such subtleties? It might actually be
counterproductive to fix them at source. You end up with complexity
upstream that won't actually matter there if it breaks. Which is a
recipe for it to break silently and far away from the downstream fork
that might actually care about it. Or it might confuse people in future
who don't care about the downstream forks, just lines.love.
Maybe it makes sense to modify edit.lua here and take the hit on all
possible future merge conflicts. But considering the cost of tracking
this down, it seems simplest to:
a) come up with the constraint I care about, and
b) modify outside edit.lua, either what it sees or its results, to
preserve the new constraint.
Long ago I used to have this assertion in pensieve.love that the cursor
must be within the viewport, but I ended up taking it out because it
kept breaking for me when I was trying to do real work. It seems clear
that there are possible assertions that are useful and yet
counterproductive. If you can't keep it out of the product in the course
of testing, then it annoys users where ignoring it would be a more
graceful experience. Even when the user is just yourself! So it turns
out this is not a problem only for large teams of extrinsically
motivated people who don't eat their own dog food. No, for some things
you have to fix the problem by construction, not just verify it with an
assertion.
This plan isn't fully working yet in this commit. I've only fixed cases
for down-arrow. I need to address up arrow, and there might also be
changes for left/right arrows. Hmm, I'm going to try to follow the
implementation of bring_cursor_of_cursor_node_in_view() in
pensieve.love.
In the process of doing this I also noticed a bug with page-up/down. It
already existed, but this approach has made it more obvious.
Kartik K. Agaram