about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
...
* allow buttons to nest as wellKartik K. Agaram2022-08-231-2/+11
|
* flip return value of button handlersKartik K. Agaram2022-08-232-6/+4
| | | | | | 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.
* stop putting button state in a globalKartik K. Agaram2022-08-233-9/+13
| | | | | | | | | | | | | | | | 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.
* improve explanation for buttonsKartik K. Agaram2022-08-231-1/+4
|
* allow buttons to interrupt eventsKartik K. Agaram2022-08-232-2/+6
| | | | Most button onpress1 handlers will want to return true.
* indentKartik K. Agaram2022-08-231-1/+3
|
* distinguish consistently between mouse buttons and other buttonsKartik K. Agaram2022-08-233-30/+30
|
* include pensieve.love even though it's in developmentKartik K. Agaram2022-08-221-0/+5
|
* include a forkKartik K. Agaram2022-08-211-0/+2
|
* correct a commentKartik K. Agaram2022-08-211-1/+1
| | | | We no longer have undo history directly in globals.
* regression: dropping files on the windowKartik K. Agaram2022-08-192-0/+3
| | | | Also improve the test to catch this next time.
* fix a nameKartik K. Agaram2022-08-191-4/+4
|
* reclaim a couple more functions after testsKartik K. Agaram2022-08-191-0/+2
|
* couple of accidental globalsKartik K. Agaram2022-08-181-2/+2
| | | | Luckily they didn't bite me yet.
* get rid of some ridiculous codeKartik K. Agaram2022-08-181-15/+5
| | | | | | I guess I wrote it before I settled into the idiom of: * first change cursor * then scroll if necessary
* spurious argsKartik K. Agaram2022-08-181-18/+18
|
* dead codeKartik K. Agaram2022-08-181-2/+0
|
* generalize a functionKartik K. Agaram2022-08-183-12/+13
|
* drop some obsolete argsKartik K. Agaram2022-08-181-2/+2
|
* subsection headings in a long switchKartik K. Agaram2022-08-181-0/+2
|
* extract a variableKartik K. Agaram2022-08-181-2/+3
|
* simplifyKartik K. Agaram2022-08-181-4/+1
|
* simpler location comparisonKartik K. Agaram2022-08-171-5/+2
|
* move caching behavior inside compute_fragmentsKartik K. Agaram2022-08-171-6/+6
|
* remove some unnecessary workKartik K. Agaram2022-08-171-1/+3
|
* standardize scroll check in a few placesKartik K. Agaram2022-08-171-3/+3
| | | | | | | | | | | | I'm taking some lessons from pensieve.love here. It seem like specific pixel thresholds don't matter too much for plain lines.love. I'd probably feel safer if I just used Text.cursor_out_of_screen in these places, but it means we draw the screen twice for most events[1]. Let's see if we can get by with the current approach. [1] Or we have to start scheduling things for the next draw, which is more complex to orchestrate.
* simplify cursor-on-screen checkKartik K. Agaram2022-08-172-11/+9
|
* swap return valuesKartik K. Agaram2022-08-173-8/+8
|
* obsolete commentKartik K. Agaram2022-08-161-2/+0
|
* moveKartik K. Agaram2022-08-151-28/+28
|
* drop some unnecessary callsKartik K. Agaram2022-08-151-6/+0
|
* stop confusingly reading a globalKartik K. Agaram2022-08-151-2/+2
| | | | | | | The way Text.draw is called by edit.draw, we know it'll never be called for lines above screen_top1.line. Comparing every line on screen with screen_top1 makes no sense. The intent is really just to compare with screen_top1 only for the first line, and otherwise to ignore this check.
* new mirrorKartik K. Agaram2022-08-141-0/+1
|
* more cogent onboarding instructionsKartik K. Agaram2022-08-141-4/+7
| | | | Someone looking at the repo will probably prefer the terminal.
* remove some duplicationKartik K. Agaram2022-08-142-13/+8
|
* bugfix: obsolete location for attributeKartik K. Agaram2022-08-141-2/+2
|
* overzealous search-and-replaceKartik K. Agaram2022-08-131-1/+1
|
* bugfix: check after cursor on same line when searching upwardsKartik K. Agaram2022-08-112-1/+28
|
* search: transparently handle drawings everywhereKartik K. Agaram2022-08-111-22/+18
|
* bugfix: search upwardsKartik K. Agaram2022-08-112-1/+20
|
* bugfix: check before cursor on same lineKartik K. Agaram2022-08-112-1/+31
|
* bugfix: handle drawings when updating screen topKartik K. Agaram2022-08-111-0/+1
|
* renameKartik K. Agaram2022-08-111-24/+24
|
* bugfix: pagedown was sometimes bouncing upKartik K. Agaram2022-08-102-1/+18
|
* bugfix: backspace from start of final lineKartik K. Agaram2022-08-102-1/+21
|
* unnecessary argsKartik K. Agaram2022-08-101-1/+1
|
* hardcode some assumptions about how this app uses loveKartik K. Agaram2022-08-061-18/+11
|
* bugfix: imprecision in drawingKartik K. Agaram2022-08-032-0/+4
| | | | | | | | | | | scenario: slowly press down mouse button and drag to draw a line release mouse button Before this commit the point would jump just a little bit on release, and points would go slightly to the left of where I expect. Yet another thing it's hard to write an automated test for.
* round one coordinateKartik K. Agaram2022-07-301-1/+1
|
* round coordinates to integers in a few placesKartik K. Agaram2022-07-291-7/+11
| | | | | | | | | | | | | Thanks Lion Kimbro for pointing out this issue. I still have to use floats for start/end angles of arcs. That might be a sign that I don't have the right serialization yet for them. Or that that feature needs to go. I started out with a hazy idea of only using 8-bit ints for coordinates, but now I'm not sure how committed I am to that constraint. While the width is always 256 units, it might be nice to create long portrait drawings at some point, whose height is greater than 256 units.