before:
stack traceback:
[string "text.lua"]:9: in function 'draw'
[string "edit.lua"]:200: in function 'draw'
[string "run.lua"]:140: in function 'draw'
[string "main.lua"]:162: in function <[string "main.lua"]:155>
[C]: in function 'xpcall'
[string "app.lua"]:38: in function <[string "app.lua"]:20>
[C]: in function 'xpcall'
[love "boot.lua"]:370: in function <[love "boot.lua"]:337>
after:
stack traceback:
text.lua:9: in function 'draw'
edit.lua:200: in function 'draw'
run.lua:140: in function 'draw'
main.lua:162: in function <[string "main.lua"]:155>
[C]: in function 'xpcall'
app.lua:38: in function <[string "app.lua"]:20>
[C]: in function 'xpcall'
[love "boot.lua"]:370: in function <[love "boot.lua"]:337>
It seems to have been introduced in commit 46889593da back in Jan, and I
was using it to summarize multiple failing tests. However, it's not used
in that scenario anymore (and anyway it seems wasteful to compute the
stack for each failing test and then throw it all away).
I connect keys and values bidirectionally ways inside Definitions:
* Definitions is a table, and the key points at the value.
* Each value (node; a table) also contains the corresponding key.
However, before this commit I was not updating the key inside the node
when I was moving nodes around inside Definitions. And that was leading
to errors when I moved nodes around the surface like:
Error: [string "REPL"]:12: attempt to index local 'node' (a nil value)
stack traceback:
[string "REPL"]:12: in function 'A1'
[string "REPL"]:22: in function 'update'
main.lua:196: in function 'update'
app.lua:99: in function <app.lua:85>
[C]: in function 'xpcall'
app.lua:113: in function <app.lua:112>
[C]: in function 'xpcall'
Why did I make this mistake? Because it's been easy to forget about
node.key.
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.
driver.love still failing a couple of manual tests. It's slightly
non-deterministic depending on the precise alignment of screenlines on
screen. I need to adjust how I make space for the menu bar.