about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
...
* | Merge lines.loveKartik K. Agaram2023-09-205-26/+102
|\|
| * bugfix: clear selection when clicking above or below linesKartik K. Agaram2023-09-205-26/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Matt Wynne pointed out that snap.love would crash when a node went off screen. While debugging it I noticed that selection1 was being set when it shouldn't be. Turns out I introduced a bug when I fixed the inscript bug back in June (commit 9656e137742). One invariant I want to preserve is: selection1 should be unset after a mouse click (press and release without intervening drag). This invariant was violated in my bugfix back in June. I was concerned only with selection back then, and I didn't realize I was breaking the mouse click case (in a fairly subtle way; you can have selection set, and when it's set identically to the cursor everything looks the same). I think there might still be an issue in snap.love after this fix. I noticed screen_bottom1.pos was nil, and as far as I recall that should never happen.
* | Merge lines.loveKartik K. Agaram2023-09-171-9/+20
|\|
| * indentKartik K. Agaram2023-09-162-16/+16
| |
| * port an old fix to source editorKartik K. Agaram2023-09-161-1/+11
| |
| * bugfix to the helper I added yesterdayKartik K. Agaram2023-09-162-0/+2
| |
* | fix a bad mergeKartik K. Agaram2023-09-161-2/+0
| |
* | Merge lines.loveKartik K. Agaram2023-09-157-29/+40
|\|
| * source: show file being edited in window title barKartik K. Agaram2023-09-152-1/+2
| |
| * delete some dead codeKartik K. Agaram2023-09-152-12/+1
| | | | | | | | This is a holdover from the days of bifold text.
| * hide line numbers from log browserKartik K. Agaram2023-09-153-8/+14
| |
| * assume starty can be nil in updateKartik K. Agaram2023-09-151-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * bugfix: crash when using mouse wheelKartik K. Agaram2023-09-152-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * change a helper slightlyKartik K. Agaram2023-09-152-14/+22
| |
| * clean up a slight jitter when drawing circlesKartik K. Agaram2023-09-151-1/+2
| | | | | | | | | | | | | | | | | | | | 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.
* | Merge lines.loveKartik K. Agaram2023-09-143-3/+7
|\|
| * always show line numbers in source editorKartik K. Agaram2023-09-143-3/+7
| | | | | | | | | | | | 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 :/
* | Merge lines.loveKartik K. Agaram2023-09-103-17/+3
|\|
| * Revert "deemphasize the source editor"Kartik K. Agaram2023-09-103-17/+3
| | | | | | | | | | | | | | Now that we have decent error handling, I think we can encourage people to press ctrl+e again. This reverts commit 4b43e9e85d985bcedd105fa9693ae751e5b6d0b6.
* | Merge lines.loveKartik K. Agaram2023-09-091-11/+46
|\|
| * yet another bugfix X-(Kartik K. Agaram2023-09-091-2/+2
| | | | | | | | This time it really does work with pensieve.love
| * two bugfixesKartik K. Agaram2023-09-091-2/+3
| | | | | | | | | | Annoying dangers of testing in one fork and committing upstream (where it isn't used yet).
| * new primitives for reading/writing filesKartik K. Agaram2023-09-091-0/+34
| | | | | | | | | | | | | | | | 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.
| * reorderKartik K. Agaram2023-09-091-11/+11
| |
* | Merge lines.loveKartik K. Agaram2023-09-081-0/+13
|\|
| * a few more testable file-system operationsKartik K. Agaram2023-09-081-0/+13
| |
* | Merge lines.loveKartik K. Agaram2023-09-042-0/+9
|\|
| * show any error after switching to source editorKartik K. Agaram2023-09-042-0/+9
| | | | | | | | | | | | 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.
* | Merge lines.loveKartik K. Agaram2023-09-041-5/+36
|\|
| * switch to source editor on errorKartik K. Agaram2023-09-041-3/+18
| | | | | | | | | | | | 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.
| * stop using keyboard.isDownKartik K. Agaram2023-09-041-2/+18
| | | | | | | | It doesn't work on Android, and it's not much work to avoid.
* | Merge lines.loveKartik K. Agaram2023-08-312-2/+2
|\|
| * yet another set of bugfixesKartik K. Agaram2023-08-302-2/+2
| | | | | | | | | | The key API change I'd underestimated: opening a file used to return nil on failure, and now returns false.
* | Merge lines.loveKartik K. Agaram2023-08-306-73/+562
|\|
| * bugfix in source editorKartik K. Agaram2023-08-301-2/+8
| | | | | | | | We now need to explicitly select the directory we want to read from.
| * cleaner API for file-system accessKartik K. Agaram2023-08-304-52/+535
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * make a few names consistent with snake_caseKartik K. Agaram2023-08-304-20/+20
| |
* | Merge lines.loveKartik K. Agaram2023-08-263-177/+152
|\|
| * reorganize app.lua and its commentsKartik K. Agaram2023-08-261-166/+142
| | | | | | | | | | | | 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.
| * correct various names in this and other pre-freewheeling forksKartik K. Agaram2023-08-261-7/+7
| |
| * fix method name in documentationKartik K. Agaram2023-08-261-1/+1
| |
| * tweak wording in test listKartik K. Agaram2023-08-071-3/+2
| |
* | Merge lines.loveKartik K. Agaram2023-07-312-32/+47
|\|
| * reorganize some commentsKartik K. Agaram2023-07-311-2/+2
| | | | | | | | | | This keeps things consistent with other forks (links, lines-and-links) that are "conceptually upstream" of the source editor.
| * bugfix: search highlight straddling screen linesKartik K. Agaram2023-07-312-14/+16
| |
| * remove a duplicate print to screenKartik K. Agaram2023-07-312-17/+14
| | | | | | | | In addition to being more efficient, this will simplify the next bugfix.
| * extract a variableKartik K. Agaram2023-07-312-2/+4
| |
| * bugfix: highlight search patterns on the right lineKartik K. Agaram2023-07-312-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | 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.
| * hoist and duplicate a conditionalKartik K. Agaram2023-07-312-6/+10
| | | | | | | | | | | | I'm duplicating the bounds check when drawing cursor and search highlight because they're separate concerns and require subtly different logic.
| * improve a commentKartik K. Agaram2023-07-312-2/+2
| |
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-12-20 20:05:27 +0000