It's a hack:
- if you start selecting from below final line the start of the
selection is the most recent click even if it was forever ago
- (the crash we're currently fixing) if you start up and immediately
select all then click below final line => crash. recent_mouse was
never set.
- getting rid of it breaks no tests (except the crash we're currently
fixing)
Text.mouse_pos can sometimes set recent_mouse.time but not
recent_mouse.x/y. I'd assumed x/y is never nil in those situations, but
that's violated. It's most easily seen when typing C-a and then
clicking.
The bug has been spotted twice:
1. In snap.love, I selected text in one node, then another, and hit:
Error: text.lua:789: attempt to compare nil with number
stack traceback:
text.lua:789: in function 'lt1'
select.lua:19: in function 'clip_selection'
text.lua:32: in function 'draw'
edit.lua:117: in function 'draw'
[string "REPL"]:21: in function 'draw'
main.lua:152: in function 'draw'
app.lua:102: in function <app.lua:84>
[C]: in function 'xpcall'
app.lua:112: in function <app.lua:111>
[C]: in function 'xpcall'
Couldn't reproduce.
2. In text.love, inscript selected all text in a small buffer and then
clicked outside the text. And got:
Error: text.lua:784: attempt to compare nil with number
Traceback
[love "callbacks.lua"]:228: in function 'handler'
text.lua:784: in function 'lt1'
select.lua:19: in function 'clip_selection'
text.lua:27: in function 'draw'
edit.lua:117: in function 'draw'
run.lua:136: in function 'draw'
main.lua:148: in function 'draw'
app.lua:42: in function <app.lua:22>
[C]: in function 'xpcall'
This is reproducible, and also across forks.
Broken since 2022-09 X-(
Scenario:
* switch to source editor
* draw a line
* wait 3 seconds
Before this commit the app would crash and then fail to restart until
you deleted the created .lua file from save dir.
This is not the first time I've confused Lua's files and LÖVE's
droppedFile objects. Just never rely on multiple args in file:write().
Scenario: a long line containing a hyperlink towards the end.
Before this commit the underline for the hyperlink was being rendered on
an x pixel starting from the start of the line.
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
There's a protocol invariant to preserve here: If a live command sends a
response in any situation, it needs to send a response in all
situations. Otherwise the driver can't decide whether to wait or not.
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.)