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.
scenario:
* position a wrapped line on screen
* search for the word immediately after the point of wrapping
Before this commit the word would be highlighted twice:
- at the end of the first screen line
- at the start of the second screen line
Now it shows up at the right place.
To find the first word we currently strip _all_ Lua comments. This is
really wasteful for large definitions. At least avoid all these
allocations if the first word is not a comment.
I'm learning the hard way that resizing the window is a big deal. Only
do this when someone explicitly requests it, otherwise follow LÖVE's
defaults.
Therefore we're also going to stop trying to be smart when showing the
log browser. Leave window resizing to manual operations.
Now initialization looks a lot more similar for the run and source apps.
I just noticed we hadn't got this bugfix for Linux on the main app. How
had we not noticed this issue before? Answer: lines.love windows tend to
be tall and skinny, and resize must keep the window entirely within the
screen. So the window was staying in place just because it happened to
be running up against the bottom.