| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
I have no idea what the performance implications of this are..
|
|
|
|
| |
- Text.to_pos_on_line
|
|
|
|
| |
- Text.in_line
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Text.cursor_at_final_screen_line
- Text.move_cursor_down_to_next_text_line_while_scrolling_again_if_necessary
- Text.snap_cursor_to_bottom_of_screen
- Text.in_line
- Text.to_pos_on_line
- Text.to2
- Text.to1
- Text.previous_screen_line
- Text.tweak_screen_top_and_cursor
- Text.redraw_all
|
|
|
|
|
| |
- Text.pos_at_start_of_cursor_screen_line
- Text.cursor_past_screen_bottom
|
|
|
|
|
|
|
| |
- record_undo_event
- undo_event
- redo_event
- snapshot
|
|
|
|
|
|
|
|
|
|
|
| |
- Text.draw_highlight
- Text.clip_selection
- Text.selection
- Text.cut_selection
- Text.delete_selection
- Text.delete_selection_without_undo
- Text.mouse_pos
- Text.to_pos
|
|
|
|
| |
We're still accessing them through a global. But we'll change that next.
|
| |
|
|
|
|
|
| |
One advantage of this approach: we don't end up with multiple lexical
scopes containing duplicates of the same modules.
|
|
|
|
| |
- Text.pos_at_start_of_cursor_screen_line
|
|
|
|
| |
- Text.to_pos_on_line
|
|
|
|
| |
- Text.in_line
|
|
|
|
|
|
|
|
|
| |
- Text.clip_selection
- Text.cut_selection
- Text.delete_selection
- Text.delete_selection_without_undo
- Text.mouse_pos
- Text.to_pos
|
| |
|
| |
|
| |
|
|
|
|
| |
Let's just make all the utf8.offset calculations more defensive.
|
|
|
|
|
|
| |
Not sure where that idiom comes from or why strings work in some places
(auto-coercion?). I picked it up off some example apps. But
https://love2d.org/wiki/love.mouse.isDown says it should be an integer.
|
|
|
|
|
|
|
| |
If I'd had this stuff in my test harness earlier, two recent commits
would have failed tests and given me early warning:
ff88238ff1
ff88a2a927
|
|
|
|
| |
I need more tests.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: repeatedly copying (relatively large) sections of text quickly
makes the app sluggish until it has to be killed. (Thanks John Blommers
for the report.)
When I instrument with prints, the sluggishness seems to happen in
random draw() calls many times after I perform the copy.
I don't know for sure, but I'm initially checking if the cause is
garbage generated by repeated string concatenation.
This attempt doesn't seem to make any difference.
|
| |
|
| |
|
|
|