Before this commit, any error in on.code_change would show in the driver only until the next keypress, whereupon it would disappear.
The sequence of events that caused this:
Driver
receives 'F4'
submit_definition
live.send_definition_to_app
App
* triggers live.receive_from_driver (within love.update)
* processes incoming message in live.run
* live.send_to_driver
live.receive_from_app (still within submit_definition)
on.code_submit
There's no load error (the syntax of the definition is totally fine)
Manifest_navigator.reload = true
Meanwhile, the app continues running after live.send_to_driver
* on.code_change
* error within on.code_change
* live.handle_error
* live.send_run_time_error_to_driver
driver pops up the run-time error
press a key
Since Manifest_navigator.reload is true, driver sends 'MANIFEST' (in case the previous F4 created a new definition, which must be added to the command palette up top)
live.send_to_app clears all errors
* since it's just a 'MANIFEST' command, on.code_change doesn't run
* no error
driver doesn't receive a new error to replace the error that was cleared.
Phew!
This commit is one way to fix it, but I'm not sure it's ideal.
It argues that there's no reason to update manifest once the app has a run-time error. Just wait for a new code change to eventually fix the error, and it'll update the manifest.
(Once I start caring about run-time errors in on.code_submit, I also need to wait a little to give run-time errors the opportunity to trigger, before running on.code_submit in the driver, so that Manifest_navigator.reload doesn't get set in on.code_submit.)
But you could also argue that on.code_submit shouldn't be concerned with run-time errors.
Perhaps the real culprit being hinted at here is updating the manifest asynchronously after a code submission. Perhaps all code submissions should automatically return a manifest. Or perhaps only when the manifest needs changing. If I do that, the global state of Manifest_navigator.reload would disappear entirely.
Thinking through all this benefited from 2 large monitors, 3 virtual workspaces and at least 5 windows (app and driver, terminals with logs for each, then a meta-driver window to make changes to the driver's source code). Which is a change from my usual setup for programming Freewheeling Apps: a single laptop monitor, single workspace and 2 windows.
YAOMNMRL77O3H2IYGWZ7F7SJONKMHICK2VIVJYYK55BJGB5GX5UAC