This is a violation of an existing rule in Manual_tests.md. The
following command weakly suggests there aren't any others:
grep ':sub(' *.lua |grep pos
Second issue introduced in commit a2451aa26. It's worth checking error
recovery in the simpler test, even though it's technically caught in the
next one. A little redundancy seems good here.
Bug was introduced in commit a2451aa26 32 hours ago, because I didn't go
over the manual tests for the error-handling protocol after modifying
the error-handling protocol. (I only tested them in template-live.)
The first time you connect to an app with driver.love, it'll request and
obtain any available default_map to show you. That should make for a
better initial experience. Past that point you're free to move
definitions around, and the default map will stop getting in your way.
Not directly relevant here, but forks of this project that permit
zooming can run into weird glitches if margins are not a whole number of
pixels.
I'd always assumed a type system that divided ints into floats was
strictly superior, but now I have experienced a situation where
requiring ints isn't just a compromise for the underlying CPU
implementation. Particularly since Lua's print() silently hides really
tiny fractions.
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.
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.
Still lots to do, but the eventual hope is that this will make this
project's code easier to reuse from other LÖVE projects.
One gotcha: even as we start putting code more aggressively into nested
tables, tests must remain at the top-level. Otherwise they won't run.