| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
To fix this I have to first stop incrementally updating screen_bottom1
in the middle of a frame. Now it always has a good value from the end of
a frame.
I'm also running into some limitations in the test I'd ideally like to
write (that are documented in a comment), but I still get some sort of
automated test for this bugfix.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It's a hack:
- if you start selecting from below final line the start of the
selection is the most recent click even if it was forever ago
- (the crash we're currently fixing) if you start up and immediately
select all then click below final line => crash. recent_mouse was
never set.
- getting rid of it breaks no tests (except the crash we're currently
fixing)
|
|
|
|
|
| |
This helps, but doesn't address the C-a case. As it stands, literally my
first click of the mouse might need access to recent_mouse.line/pos
|
|
|
|
|
|
|
| |
Text.mouse_pos can sometimes set recent_mouse.time but not
recent_mouse.x/y. I'd assumed x/y is never nil in those situations, but
that's violated. It's most easily seen when typing C-a and then
clicking.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bug has been spotted twice:
1. In snap.love, I selected text in one node, then another, and hit:
Error: text.lua:789: attempt to compare nil with number
stack traceback:
text.lua:789: in function 'lt1'
select.lua:19: in function 'clip_selection'
text.lua:32: in function 'draw'
edit.lua:117: in function 'draw'
[string "REPL"]:21: in function 'draw'
main.lua:152: in function 'draw'
app.lua:102: in function <app.lua:84>
[C]: in function 'xpcall'
app.lua:112: in function <app.lua:111>
[C]: in function 'xpcall'
Couldn't reproduce.
2. In text.love, inscript selected all text in a small buffer and then
clicked outside the text. And got:
Error: text.lua:784: attempt to compare nil with number
Traceback
[love "callbacks.lua"]:228: in function 'handler'
text.lua:784: in function 'lt1'
select.lua:19: in function 'clip_selection'
text.lua:27: in function 'draw'
edit.lua:117: in function 'draw'
run.lua:136: in function 'draw'
main.lua:148: in function 'draw'
app.lua:42: in function <app.lua:22>
[C]: in function 'xpcall'
This is reproducible, and also across forks.
|
|
|
|
|
| |
In the process I discovered the horrible fact that Text.x allocates a new Text.
And it gets called (just once, thank goodness) on every single frame.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|