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.
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.
Before:
- notes directory is saveDir/data by default
where saveDir = love.filesystem.getSaveDirectory()
- providing a commandline arg of x makes the notes directory saveDir/data.x
Now:
- there is no default directory; you get an error message instead
telling you what to do.
- the commandline arg is the (preferably absolute) path of the notes
directory you want to load
Unchanged: once you set the notes directory it gets remembered for
future runs.
Now the Readme is a lot simpler.
I tried to make migrating simpler, but this is complicated enough (see
Manual_tests.md)
Now pensieve.love always manages notes in the data/ subdirectory of the
save dir, and stores its settings in the 'config' file in the save dir.
And main.lua is now much more similar to upstream and most forks. I made
this edit using an external editor, just to keep the comparison with
lines.love in view.
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.
Scenario:
* get 2 copies of a note on screen at once (say by running 'extract'
on a note at the top of recent changes)
* click on one of them to focus cursor on it
* press ctrl-e to edit then again to stop editing
* press ctrl-e again to edit, then hit enter
Before this commit the app would crash on an assertion failure; a pane's
line and line_cache were no longer in sync.
I'm fixing it by reloading all other copies of a pane from disk
immediately after writing it to disk. Which may well be massively
slower, but is a) likely cached by the OS, and b) not noticeable.
This bug has likely been present since 2022-11 (commit 813e06fd4d).
I've adjusted mouse_wheel_move to work even when there's no editable
pane. It could be improved though. This app really wants some sense of
acceleration.
I've also had to hack in a check for cursor_x/cursor_y being nil when
scrolling in an editable pane.
There can be many frames between a keypress and key release event.
I ran into this a couple of months ago.
keypress and textinput still happen on the same frame. Hmm.
I should just track when an event actually does any work, and only
plan_draw then. That way if keypress and textinput have disjoint cases
of activation there'll be no duplication.
Kartik K. Agaram