| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
We had a regression since commit 60e1023f0 on Nov 27. Turns out we do
need the ancient hack after all.
But no, we won't go back to the hack. It's a simple problem to fix
right. And while we're at it, we'll fix the test harness to be more
realistic so it would have caught this problem.
|
| |
|
| |
|
|
|
|
| |
We only need time differences.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
integrated from pong.love via text.love:
https://merveilles.town/@akkartik/108933336531898243
|
| |
|
|
|
|
|
|
| |
This is compatible with Javascript, and it also seems like a better
default; when people forget to think about return values in click
handlers, they should be consumed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Symptom: a test (test_click_to_create_drawing) started randomly failing
after I inserted a `return` 2 commits ago.
Cause: my tests call edit.draw, but button handlers only get cleared in
app.draw. So my tests weren't clearing button handlers, and every call
to edit.draw was accumulating states. Still unclear why those were going
to different state objects after the `return`, but anyway. I'm not going
to understand every last thing that happens when things go wrong, just
guarantee they can't go wrong. And the way to do that is to decentralize
button handlers to each state that receives them.
The State object in buttons.lua doesn't have to be Editor_state. It just
has to be some table that provides a Schelling Point for shared state.
|
|
|
|
| |
Most button onpress1 handlers will want to return true.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Disquieting that none of my tests caught these. On the other hand, I
also haven't noticed any issues in practice. Perhaps cache invalidation
is often unnecessary.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
I have no idea what the performance implications of this are..
|
| |
|
|
|
|
| |
- Text.to_pos_on_line
|
|
|
|
| |
- Text.in_line
|
| |
|
| |
|
| |
|
| |
|