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.
These are like versions in nativefs, but only support absolute paths.
I want to be thoughtful about the precise location at each call-site.
It's a little ugly that app.lua now has a dependency on file.lua. Or
source_file.lua for the source editor.
Thanks to physfs and nativefs.lua
nativefs still introduces some inconsistencies with love.filesystem with
relative paths:
* love.fs.read: reads from save dir if it exists, falls back to source dir if not
* nativefs.read: reads from save dir if it exists, falls back to source dir if not ✓
* love.fs.write: always writes to save dir
* nativefs.write: always writes to source dir (since no restrictions)
* love.fs.newFile followed by file:open('r'): reads from save dir if it exists, source dir if not
* nativefs.newFile followed by file:open('r'): always reads from working dir
* love.fs.newFile followed by file:open('w'): always writes to save dir
* nativefs.newFile followed by file:open('w'): always writes to working dir
So avoid using relative paths with App primitives.
I've been misunderstanding what Text objects are. They can render a lot
of text with a given line height, word wrap, colors in various places.
And I've been creating one for every word 🤦
Unwinding this will take some time. This is just a first baby step for
ad hoc text objects. Turns out I don't need to convert to Text to get
something's rendered width, just the Font can do that.
Thanks to the LÖVE Discord for educating me:
https://discord.com/channels/329400828920070144/330089431379869708/1091535487333826580
It might reduce wear and tear on disk, and losing 3 seconds of data
doesn't feel catastrophic (short of a C-z rampage).
Thanks to the love2d.org community for the suggestion:
https://love2d.org/forums/viewtopic.php?f=14&t=93173
It's still a bit simple-minded. Most software will keep the first bound
fixed and move the second. Lines currently has the bounds in a queue of
sorts. But I have a test to indicate the behavior that is definitely
desired. We'll see if we need it to get more complex.