I'm starting to feel better after replacing 1 line with 20 and 2 new
bits of global state. I'm now handling two scenarios more explicitly:
* If I change Current_app within key_press, the corresponding text_input
and key_release events go to the new app. If it's an editor it might
insert the key, which is undesirable. Putting such handlers in
key_release now feels overly clever, particularly since it took me
forever to realize why I was getting stuck in an infinite loop.
* Both 'run' and 'source' can hit the version check, so we need to be
able to transition from the 'error' app to either. Which
necessitates yet another global bit of state: Next_app.
When I stopped running the version check before the tests I also stopped
initializing Version, which can be used in tests to watch out for font
changes across versions. As a result I started seeing a test failure
with LÖVE v12.
It looks like all manual tests pass now. And we're also printing the
warning about version checks before running tests, which can come in
handy if a new version ever causes test failures. The only thing that
makes me unhappy is the fact that we're calling the version check twice.
And oh, the fact that this part around initialization and version
management is clearly still immature.
I'll capture some desires and fragmentary thought processes around them:
* If there's an error, go to the source editor.
* But oh, don't go to source editor on some unactionable errors, so we
include a new `Current_app` mode for them:
* Unsupported version requires an expert. Just muddle through if you
can or give a warning someone can send me.
* A failing test might be spurious depending on the platform and font
rendering scheme. So again just provide a warning someone can send
me.
[Source editor can be confusing for errors. Also an editor! But not
showing the file you asked for!]
* But our framework clears the warning after running tests:
* If someone is deep in developing a new feature and quits -> restore
back in the source editor.
[Perhaps `Current_app` is the wrong place for this third hacky mode,
since we actually want to continue running. Perhaps it's orthogonal to
`Current_app`.]
[Ideally I wouldn't run the tests after the version check. I'd pause,
wait for a key and then resume tests? "Muddle through" is a pain to
orchestrate.]
* We store `Current_app` in settings. But we don't really intend to
persist a `Current_app` of 'error'. Only the main app or 'source'
editor.
[Another vote against storing 'error' in `Current_app`.]
* So we need to rerun the version check after running tests to actually
show the warning.
[Perhaps I need to separate out the side-effect of setting `Version`
from the side-effect of changing `Current_app`. But that's not right
either, because I do still want to raise an error message if the
version check fails before running tests. Which brings us back to
wanting to run the tests after raising the version check..]
One good thing: none of the bugs so far have been about silently
ignoring test failures. I thought that might be the case for a bit,
which was unnerving.
I grew similar muddiness in Mu's bootstrap system over time, with
several surrounding modes around the core program that interacted poorly
or at least unsatisfyingly with each other. On one level it just feels
like this outer layer reflects muddy constraints in the real world. But
perhaps there's some skill I still need to learn here..
Why am I even displaying this error if we're going to try to muddle
through anyway? In (vain) hopes that someone will send me that
information. It's not terribly actionable even to me. But it's really
intended for when making changes. If a test fails then, you want to
know.
The code would be cleaner if I just threw an unrecoverable error from
the version check. Historically, the way I arrived at this solution was:
* I used the default love.errorhandler for a while
* I added xpcall and error recovery, but now I have situations where I
would rather fall back on love.errorhandler. How to tell xpcall
that?
But no, this whole line of thought is wrong. LÖVE has a precedent for
trying to muddle through on an unexpected version. And spurious test
failures don't merit a hard crash. There's some irreducible requirement
here. No point making the code simplistic when the world is complex.
Perhaps I should stop caching Version and just recompute it each time.
It's only used once so far, hardly seems worth the global.
We have two bits of irreducible complexity here:
* If tests fail it might be a real failure, or it might not.
* Even if it's an unexpected version, everything might be fine.
And the major remaining problem happens at the intersection of these two
bits. What if we get an unexpected version with some difference that
causes tests to fail? But this is a hypothetical and not worth thinking
about since I'll update the app fairly quickly in response to new
versions.
Not quite ideal: the scrollbar computation only considers
screen_bottom1.line and not screen_bottom1.pos, and so it always assumes
the final line is at the bottom of the screen.
I'm making a deeper change here that I might come to regret. I want to
avoid creating new book-keeping for editor mutations, so I'm putting the
work of computing scrollbar data into clear_screen_line_cache. But that
implies the editor should never clear before updating data, and I caught
one place that wasn't true before. A better name helps avoid this in
future. Let's see how much toil this causes in resolving conflicts.
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.
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
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.