| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|
|
|
| |
This is a holdover from the days of bifold text.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a backport of a bugfix in pensieve.love. It's not _technically_
a bug here in lines.love, but it seems worth establishing an
architectural invariant (or rather lack of invariant).
LÖVE's standard event loop performs the following sequence of operations
in a single frame:
* process events
* update
* draw
Ideally any mutations to global state happen during the first two
phases, while drawing includes no mutation.
However, there is a special case: `starty`, the top y coordinate for
each each line in the editor. This is used all over the place, and the
cheapest way to compute it is to simply save it while drawing.
However, draw by definition only updates `starty` for lines that are
drawn on screen. To avoid stale data on lines off screen, say after
scrolling, events often clear `starty` for all lines, leaving it to the
next draw phase to repopulate the right lines.
Sandwiched between the above two "however"s, the update phase needs to
gracefully handle `starty` being nil in the occasional frame right after
an event.
I think I've audited all our uses of `starty`, and this commit fixes the
only place that violates this rule.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All the Text functions assume the cursor is always on a text line. I was
violating that invariant.
* When scrolling up, I start the cursor at the top-most line below the
screen top.
* When scrolling down, I start the cursor at the top-most line below the
screen bottom.
I think it would feel slightly more natural for it to be the
bottom-most line above the screen bottom.
However, the Text functions maintain an invariant that the bottom-most
line in a buffer will be text. There's no such invariant for the
top-most line.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Earlier the ghost while drawing wouldn't quite match the final shape.
Now the math is identical in draw_pending_shape.
It's a little unfortunate that we have this duplication of formulae.
At least there are no other stray calls of App.mouse_x in
draw_pending_shape.
|
|
|
|
|
|
| |
The drawing buttons are now absolutely positioned, which is a horrible
hack. But for just the source editor it seems good enough. The
alternative is to modify magic constants in all the tests :/
|
|
|
|
|
|
|
| |
Now that we have decent error handling, I think we can encourage people
to press ctrl+e again.
This reverts commit 4b43e9e85d985bcedd105fa9693ae751e5b6d0b6.
|
|
|
|
| |
This time it really does work with pensieve.love
|
|
|
|
|
| |
Annoying dangers of testing in one fork and committing upstream
(where it isn't used yet).
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
If we're already in source editor we'll quit as before.
It's ugly that app.lua now knows about run.lua. But it's a start.
|
|
|
|
| |
It doesn't work on Android, and it's not much work to avoid.
|
|
|
|
|
| |
The key API change I'd underestimated: opening a file used to return nil
on failure, and now returns false.
|
|
|
|
| |
We now need to explicitly select the directory we want to read from.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 was so sure my comments were clear when I wrote this a year ago. They
were shit. So, most probably, is the current iteration. Feedback
appreciated.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This keeps things consistent with other forks (links, lines-and-links)
that are "conceptually upstream" of the source editor.
|
| |
|
|
|
|
| |
In addition to being more efficient, this will simplify the next bugfix.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
I'm duplicating the bounds check when drawing cursor and search
highlight because they're separate concerns and require subtly different
logic.
|
| |
|
| |
|
|
|
|
|
| |
We shouldn't be thinking about saving settings when we're initializing
window geometry.
|
|
|
|
| |
We don't ever call one app's settings while Current_app is the other.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Initialization is getting complex, and I'm finding bugs.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
It'll only work after LÖVE v12 comes out.
|
|
|
|
| |
https://pijul.org
|
|
|
|
|
| |
It works right so rarely that it's a net negative. I'll bring it back
if I ever start tokenizing on non-whitespace.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
The old name was confusing, as its description showed.
|