The way Text.draw is called by edit.draw, we know it'll never be called
for lines above screen_top1.line. Comparing every line on screen with
screen_top1 makes no sense. The intent is really just to compare with
screen_top1 only for the first line, and otherwise to ignore this check.
scenario:
slowly press down mouse button and drag to draw a line
release mouse button
Before this commit the point would jump just a little bit on release,
and points would go slightly to the left of where I expect.
Yet another thing it's hard to write an automated test for.
Thanks Lion Kimbro for pointing out this issue.
I still have to use floats for start/end angles of arcs. That might be a
sign that I don't have the right serialization yet for them. Or that
that feature needs to go.
I started out with a hazy idea of only using 8-bit ints for coordinates,
but now I'm not sure how committed I am to that constraint. While the
width is always 256 units, it might be nice to create long portrait
drawings at some point, whose height is greater than 256 units.
Disquieting that none of my tests caught these. On the other hand, I
also haven't noticed any issues in practice. Perhaps cache invalidation
is often unnecessary.
The published version of lines.love was broken for almost an hour. The
cursor would render one position to the right of where it really is. To
fix it, this commit rolls back 26ba6e4e5a. There doesn't seem a good
way to test it.
I've been sloppy about this so far, and outside of tests I can't find
any examples where it matters, but it matters in a potential fork where
I'm rendering multiple columns of text.
It's unfortunate that my tests have this level of brittleness. What I'd
really like to assert in many of these changed lines is that the text
stays inside the margins and that more text would overflow margins.