text.love - Fork of lines.love without drawings; useful starting point for further forks

	Commit message (Collapse)	Author	Age	Files	Lines
*	clean up some issues I now feel confident about	Kartik K. Agaram	2024-08-31	1	-2/+1
\|
*	delete some seemingly redundant code	Kartik K. Agaram	2024-07-08	1	-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 data	Kartik K. Agaram	2024-07-08	1	-9/+1
\|
*	fix a couple of asserts missed in the recent audit	Kartik K. Agaram	2023-12-09	1	-1/+0
\|
*	audit all asserts	Kartik K. Agaram	2023-11-18	1	-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 later	Kartik K. Agaram	2023-04-01	1	-7/+2
\|
*	line.y -> line_cache.starty in a few more places	Kartik K. Agaram	2022-07-27	1	-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 data	Kartik K. Agaram	2022-07-17	1	-0/+11
\| \| \| \|	I have no idea what the performance implications of this are..
*	add state arg to a few functions	Kartik K. Agaram	2022-07-12	1	-24/+24
\| \| \| \| \| \| \|	- record_undo_event - undo_event - redo_event - snapshot
*	group all editor globals	Kartik K. Agaram	2022-07-12	1	-20/+20
\| \| \| \|	We're still accessing them through a global. But we'll change that next.
*	stop saving the entire file when modifying drawings	Kartik K. Agaram	2022-06-10	1	-4/+2
\| \| \| \|	Now we just disallow that entirely.
*	undo creating new drawings	Kartik K. Agaram	2022-06-10	1	-0/+5
\|
*	crisp font rendering	Kartik K. Agaram	2022-06-02	1	-1/+0
\|
*	more efficient undo/redo	Kartik K. Agaram	2022-06-02	1	-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.
*	rename	Kartik K. Agaram	2022-06-02	1	-1/+1
\|
*	after much struggle, a brute-force undo	Kartik K. Agaram	2022-06-02	1	-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.