| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
| |
Also ensure we autosave.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
I found some code in the process that seems unreachable. Some chance of
a regression here..
|
| | |
|
| | |
|
| |
|
|
| |
Still a few more we can write.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
In the process I notice an issue: we seem to be adding no-op undo
records after every drawing operation.
|
| |
|
|
|
|
|
| |
I've been adding diligently to manual_tests but not actually
_performing_ any manual tests before releases. They were just a todo
list of automated tests to write, and long out of date. Now the list is
up to date and much shorter.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
The default font seems somehow different than the font created by
newFont with just a font size.
|
| |
|
|
| |
All places where string.sub was being passed a _pos variable.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
manifestation: clicking past end of a long, wrapping line containing
non-ASCII would cause the cursor to disappear rather than position past
end of screen line. Hitting enter would then throw an assertion with the
following stack trace:
Error: text.lua:381: bad argument #2 to 'sub' (number expected, got nil)
stack traceback:
[love "boot.lua"]:345: in function <[love "boot.lua"]:341>
[C]: in function 'sub'
text.lua:381: in function 'insert_return'
text.lua:179: in function 'keychord_pressed'
main.lua:495: in function 'keychord_pressed'
keychord.lua:10: in function <keychord.lua:5>
app.lua:34: in function <app.lua:25>
[C]: in function 'xpcall'
cause: the click caused a call to Text.to_pos_on_line whose result was
not on a UTF-8 character boundary.
fix: make to_pos_on_line utf8-aware.
|
| | |
|
| | |
|
| |
|
|
|
| |
For commit e4e12c77ad which fixed a regression caused by commit
24a0d162ef.
|
| |
|
|
|
|
|
|
|
|
| |
For commit ff88a2a927 which fixed a regression caused by commit
e51ce12969.
I'm trying to provide enough guardrails for myself and future readers
without causing a combinatorial explosion in tests. The previous commit
was able to get more value out of existing tests, but this test feels
necessary. And useful in general without reference to a specific bug.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
Any time I press a ctrl- chord LÖVE actually sees two key chords:
C-lctrl
C-... (the real one)
But it's not just that. There's also a lot in the codebase that's just
habit-based. I need more tests.
|
| |
|
|
| |
I messed up a function call in commit 391d764e13.
|
| |
|
|
| |
This fixes part of #4, but not the BSOD.
|
| | |
|
| | |
|
| |
|
|
|
| |
However, I think a lot of the benefit comes from just turning JIT off.
Turning it on is still noticably sluggish.
|
| |
|
|
| |
Things seem to be working..
|
| | |
|
| |
|
|
|
|
| |
We have a regression since we started reclaiming love Text fragments
more aggressively in commit 69c5d844ccc. Pressing pageup no longer knows
about any line's screen lines. Not fixed yet.
|
| | |
|
| | |
|
| |
|
|
|
| |
We don't need to perform the scroll calculations after inserting every
single character from the clipboard.
|
| | |
|
| |
|
|
| |
But this is too slow.
|
| | |
|
| | |
|
| | |
|