| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| | |
|
|\| |
|
| | |
|
| | |
|
| |
| |
| |
| | |
The old name was confusing, as its description showed.
|
|\| |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\| |
|
| |
| |
| |
| |
| | |
We had this problem because our test fakes were out of sync with reality.
And just in the source app.
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Broken since 2022-09 X-(
Scenario:
* switch to source editor
* draw a line
* wait 3 seconds
Before this commit the app would crash and then fail to restart until
you deleted the created .lua file from save dir.
This is not the first time I've confused Lua's files and LÖVE's
droppedFile objects. Just never rely on multiple args in file:write().
|
|\| |
|
| | |
|
| |
| |
| |
| |
| | |
I added this to catch a rare bug. I've had it locally for a few weeks
now without hitting it. Doesn't hurt to publish it.
|
|\| |
|
| |
| |
| |
| |
| |
| | |
Scenario: a long line containing a hyperlink towards the end.
Before this commit the underline for the hyperlink was being rendered on
an x pixel starting from the start of the line.
|
|\| |
|
| |
| |
| |
| |
| | |
Before this change the cursor was moving, but not being highlighted
properly when the cursor line contained unicode before the cursor.
|
|\| |
|
| |
| |
| |
| |
| |
| | |
This is a violation of an existing rule in Manual_tests.md. The
following command weakly suggests there aren't any others:
grep ':sub(' *.lua |grep pos
|
|\| |
|
| | |
|
|\| |
|
| | |
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A code editor is unlikely to need support for extremely long lines. And
that kind of scroll is jarring anyway in a code editor. We don't read
code like a novel, and less scroll per page implies more scrolling work.
I'd gotten rid of this functionality and the test for it [1] back in the
spokecone fork, but only took out the test when first pulling it into
the source editor.
[1] test_pagedown_often_shows_start_of_wrapping_line
|
|\| |
|
| | |
|
| | |
|
|\| |
|
| | |
|
|\| |
|
| | |
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This repo does not support freewheeling modification. It's a primitive
to enable freewheeling modification in downstream forks.
The source editor is a convenience, but it's a sharp tool and can easily
leave the app in a broken state that requires dropping down to external
tools (editor, file manager) to fix.
|
|\| |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
I missed that comments only get highlighted at start of line.
This seems a bit hacky. But it continues to trade off CPU for reduced
memory footprint.
|
|\| |
|