This is compatible with Javascript, and it also seems like a better
default; when people forget to think about return values in click
handlers, they should be consumed.
Symptom: a test (test_click_to_create_drawing) started randomly failing
after I inserted a `return` 2 commits ago.
Cause: my tests call edit.draw, but button handlers only get cleared in
app.draw. So my tests weren't clearing button handlers, and every call
to edit.draw was accumulating states. Still unclear why those were going
to different state objects after the `return`, but anyway. I'm not going
to understand every last thing that happens when things go wrong, just
guarantee they can't go wrong. And the way to do that is to decentralize
button handlers to each state that receives them.
The State object in buttons.lua doesn't have to be Editor_state. It just
has to be some table that provides a Schelling Point for shared state.
I'm taking some lessons from pensieve.love here. It seem like specific
pixel thresholds don't matter too much for plain lines.love.
I'd probably feel safer if I just used Text.cursor_out_of_screen in
these places, but it means we draw the screen twice for most events[1].
Let's see if we can get by with the current approach.
[1] Or we have to start scheduling things for the next draw, which is
more complex to orchestrate.
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.