| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
We don't want to do this during app initialization because other forks
might not start out with an editor on screen even if this one does.
We don't want to perform this side-effect on edit.mouse_press, which
also runs in tests.
|
|\| |
|
| | |
|
| | |
|
|\| |
|
| | |
|
|\| |
|
| |
| |
| |
| | |
Not really useful here, but other forks might make use of it.
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Renamed from the 'error' state.
Now we no longer overload Error_message; it's only used for actual
errors that trigger opening the source editor.
I was tempted to hide Skip_rest_of_key_events inside the 'warning' state
as well, but that isn't right. It applies to all Current_app
transitions, not just those in and out of 'warning'.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| | |
This is still ugly, but hopefully easier to follow.
|
|\| |
|
| | |
|
| | |
|
|\| |
|
| |
| |
| |
| | |
We have an early exit for 'error' mode in this function.
|
| |
| |
| |
| |
| |
| |
| | |
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.)
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To do this I need some support for multiple versions. And I need an
'error' mode to go with existing 'run' and 'source' modes
(`Current_app`). Most errors will automatically transition to 'source'
editor mode, but some errors aren't really actionable in the editor. For
those we'll use 'error' mode.
The app doesn't yet work with LÖVE v12. There are some unit tests failing
because of differences in font rendering.
|
|\| |
|
| |
| |
| |
| |
| |
| |
| | |
Now that we have decent error handling, I think we can encourage people
to press ctrl+e again.
This reverts commit 4b43e9e85d985bcedd105fa9693ae751e5b6d0b6.
|
|\| |
|
| |
| |
| |
| |
| |
| | |
Error_message is a special global. It's set when the app (Current_app = 'run')
encounters an error and switches to the source editor, and cleared when
switching from source editor back to the app.
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This repo does not support freewheeling modification. It's a primitive
to enable freewheeling modification in downstream forks.
The source editor is a convenience, but it's a sharp tool and can easily
leave the app in a broken state that requires dropping down to external
tools (editor, file manager) to fix.
|
|\| |
|
| | |
|
|\| |
|
| |
| |
| |
| |
| | |
I notice my laptop's fan starts coming on when running many of my apps.
An empty app takes 10% CPU where it used to take just 1-2%.
|
|\| |
|
| | |
|
|\| |
|
| |
| |
| |
| | |
Thanks Nils Berg for the suggestion!
|
| | |
|
|\| |
|
| | |
|
| | |
|
|\| |
|
| | |
|
| |
| |
| |
| |
| | |
I want the words to be easy to read, and to use a consistent tense.
update and focus seem more timeless; let's make everything like those.
|
|\| |
|
| |
| |
| |
| | |
We only need time differences.
|
|\| |
|
| |
| |
| |
| |
| |
| | |
I'm starting to edit the sources from within the app in ernest. First
question: why does the file navigation menu skip some files? These
prints answer the question.
|
|\| |
|
| |
| |
| |
| |
| | |
I've only tested side A so far, and included a statement of how I want
side B to behave.
|
|\| |
|
| | |
|