scenario: type a single long line wrapping past bottom of line
Before this commit we were overflowing the window.
Root cause: not understanding the precise semantics of edit.bottom.
Many of our apps want to print an extra line just so we can see the
letters peeking out from the bottom.
Still klunky in one place: when you open the driver the failing test
isn't highlighted in red. I need to communicate the structured data of
test failures in run-time errors when the tests weren't triggered by a
driver command.
Scenario:
* run a whole new app (no save dir yet) as a .love file
* open the driver, make an edit
Before this commit, I was seeing errors due to the save dir not
existing. Let's depend on love.filesystem as needed. Another "good seam"
IMO (https://lobste.rs/s/idi1wt/open_source_vs_ux).
Changes inside on.initialize are minefields. Until now, if you made a
mistake when modifying on.initialize, you could end up in a situation
where the app would fail irrecoverably on the next startup. You'd have
to go dig up a text editor to fix it.
After this commit, errors in on.initialize wait for commands from
driver.love just like any other error.
Recovering from errors during initialization is a little different than
normal. I don't know how much of initialization completed successfully,
so I redo all of it.
I think this should be safe; the sorts of things we want to do on
startup tend to be idempotent just like the sorts of things we do within
an event loop with our existing error handling.
Things are still not ideal. Initialization by definition happens only
when the app starts up. When you make changes to it, you won't find out
about errors until you restart the app[1], which can be much later and a
big context switch. But at least you'll be able to fix it in the usual
way. Slightly more seamless[2].
One glitch to note: at least on Linux, an app with an initialization
error feels "sticky". I can't seem to switch focus away from it using
Alt-tab. Hitting F4 on the driver also jarringly brings the client app
back in focus when there was an initialization error. But the mouse does
work consistently. This feels similar to the issues I find when an app
goes unresponsive sometimes. The window manager really wants me to
respond to the dialog that it's unresponsive.
Still, feels like an improvement.
[1] I really need to provide that driver command to restart the app! But
there's no room in the menus! I really need a first-class command
palette like pensieve.love has!
[2] https://lobste.rs/s/idi1wt/open_source_vs_ux
The intent of hiding errors is to see if a code change I made improved
things. But many commands from the driver don't involve a code change.
It seems more useful to leave the error up in those situations.
In particular, I want to be able to switch to 'error' mode rather than
throw a real error() on test failures, because that's a little more
responsive and might be recoverable. (On some Android devices the font
is slightly different, and tests fail as a result.)
before:
stack traceback:
[string "text.lua"]:9: in function 'draw'
[string "edit.lua"]:200: in function 'draw'
[string "run.lua"]:140: in function 'draw'
[string "main.lua"]:162: in function <[string "main.lua"]:155>
[C]: in function 'xpcall'
[string "app.lua"]:38: in function <[string "app.lua"]:20>
[C]: in function 'xpcall'
[love "boot.lua"]:370: in function <[love "boot.lua"]:337>
after:
stack traceback:
text.lua:9: in function 'draw'
edit.lua:200: in function 'draw'
run.lua:140: in function 'draw'
main.lua:162: in function <[string "main.lua"]:155>
[C]: in function 'xpcall'
app.lua:38: in function <[string "app.lua"]:20>
[C]: in function 'xpcall'
[love "boot.lua"]:370: in function <[love "boot.lua"]:337>
It seems to have been introduced in commit 46889593da back in Jan, and I
was using it to summarize multiple failing tests. However, it's not used
in that scenario anymore (and anyway it seems wasteful to compute the
stack for each failing test and then throw it all away).