about summary refs log tree commit diff stats
path: root/undo.lua
Commit message (Collapse)AuthorAgeFilesLines
* clean up some issues I now feel confident aboutKartik K. Agaram2024-08-311-2/+1
|
* delete some seemingly redundant codeKartik K. Agaram2024-07-081-11/+0
| | | | | We're patching line_cache and then immediately clearing it using Text.redraw_all.
* simplify some code now that lines contains no derived dataKartik K. Agaram2024-07-081-9/+1
|
* fix a couple of asserts missed in the recent auditKartik K. Agaram2023-12-091-1/+0
|
* audit all assertsKartik K. Agaram2023-11-181-7/+7
| | | | | | | | | | | | | Each one should provide a message that will show up within LÖVE. Stop relying on nearby prints to the terminal. I also found some unnecessary ones. There is some potential here for performance regressions: the format() calls will trigger whether or not the assertion fails, and cause allocations. So far Lua's GC seems good enough to manage the load even with Moby Dick, even in some situations that caused issues in the past like undo.
* minor cleanup and a todo for laterKartik K. Agaram2023-04-011-7/+2
|
* line.y -> line_cache.starty in a few more placesKartik K. Agaram2022-07-271-2/+2
| | | | | | 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.
* separate data structure for each line's cache dataKartik K. Agaram2022-07-171-0/+11
| | | | I have no idea what the performance implications of this are..
* add state arg to a few functionsKartik K. Agaram2022-07-121-24/+24
| | | | | | | - record_undo_event - undo_event - redo_event - snapshot
* group all editor globalsKartik K. Agaram2022-07-121-20/+20
| | | | We're still accessing them through a global. But we'll change that next.
* stop saving the entire file when modifying drawingsKartik K. Agaram2022-06-101-4/+2
| | | | Now we just disallow that entirely.
* undo creating new drawingsKartik K. Agaram2022-06-101-0/+5
|
* crisp font renderingKartik K. Agaram2022-06-021-1/+0
|
* more efficient undo/redoKartik K. Agaram2022-06-021-2/+35
| | | | | Now the bottleneck shifts to applying undo/redo in large files. But things should be snappy if you don't use the sluggish feature.
* renameKartik K. Agaram2022-06-021-1/+1
|
* after much struggle, a brute-force undoKartik K. Agaram2022-06-021-0/+78
Incredibly inefficient, but I don't yet know how to efficiently encode undo mutations that can span multiple lines. There seems to be one bug related to creating new drawings; they're not spawning events and undoing past drawing creation has some weird artifacts. Redo seems to consistently work, though.