| 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.
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Scenario:
* start out with some text on screen
* select some text A, delete
* select some more text B, delete
* press C-z twice to restore A and B
* press C-y twice
Before this commit only the first C-y was having an effect (deleting B).
The second was failing to delete A.
|
|\| |
|
| |
| |
| |
| | |
Also copy over the implementation of links from pensieve.love.
|
| | |
|
|\| |
|
| |
| |
| |
| |
| |
| | |
I see a path to at least maintain a single fragment per screen line. But
can we do better? It even seems unnecessary to maintain two copies of
the data, chopped up into lines and screen lines.
|
| |
| |
| |
| | |
Is it just my imagination, or does the app feel lighter and more fluffy?
|
| |
| |
| |
| |
| | |
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.
|
|\| |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
scenario: open a file starting with a drawing
After this commit the program doesn't crash.
Error: [string "edit.lua"]:127: attempt to get length of field 'data' (a nil value)
stack traceback:
[love "boot.lua"]:345: in function '__len'
[string "edit.lua"]:127: in function 'invalid1'
[string "edit.lua"]:116: in function 'check_locs'
[string "run.lua"]:35: in function 'initialize'
main.lua:96: in function 'initialize'
[string "app.lua"]:144: in function 'run_tests_and_initialize'
[string "app.lua"]:16: in function <[string "app.lua"]:13>
[C]: in function 'xpcall'
[love "boot.lua"]:361: in function <[love "boot.lua"]:348>
[C]: in function 'xpcall'
|
| | |
|
|\| |
|
| |
| |
| |
| |
| | |
I can't see the mouse wheel ever setting dx, but it's more obvious now
that the editor doesn't support panning left/right.
|
| | |
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| | |
This works better on mobile platforms while seeming about as useful
anywhere else.
I've verified that anyone who already edited a file will continue to use
its path from settings.
|
|\| |
|
| | |
|
| |
| |
| |
| | |
Thanks Mikoláš Štrajt.
|
|\| |
|
| | |
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
scenario:
press ctrl+f, type in a string
hit down arrow if needed until the screen scrolls
press enter
click with the mouse somewhere
Before this commit the app would crash because cursor was above screen
top.
|
|\| |
|
| |
| |
| |
| |
| |
| |
| | |
I've been noticing in pensieve.love in particular that once a month or
so I lose data if I quit immediately after typing in something. Nothing
major, just the odd link between notes which leaves things in an
inconsistent state. Let's see if this helps.
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Scenario: make some edits, select some text, make some more edits. Press
ctrl-z.
Before this commit, undo would stop at the point of selection and
previous edits would become unreachable.
After this commit, both ctrl-z and ctrl-y seem able to span the point of
selection.
|
| | |
|
|\| |
|
| | |
|
| |
| |
| |
| |
| | |
I want the words to be easy to read, and to use a consistent tense.
update and focus seem more timeless; let's make everything like those.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Not directly relevant here, but forks of this project that permit
zooming can run into weird glitches if margins are not a whole number of
pixels.
I'd always assumed a type system that divided ints into floats was
strictly superior, but now I have experienced a situation where
requiring ints isn't just a compromise for the underlying CPU
implementation. Particularly since Lua's print() silently hides really
tiny fractions.
|
| | |
|