about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* avoid saving fragments in linesKartik K. Agaram2023-04-013-69/+48
| | | | | | | Now we render lines one screen line at a time rather than one word at a time. I can't port the source side just yet; I need to fix hyperlinks first..
* show count of test failuresKartik K. Agaram2023-04-011-1/+1
|
* minor cleanup and a todo for laterKartik K. Agaram2023-04-012-14/+4
|
* clean up some final bifold codeKartik K. Agaram2023-04-012-19/+3
|
* start thinking of compute_fragments as a detailKartik K. Agaram2023-04-012-2/+2
| | | | | | | | | | I think all we need to maintain is the populate_screen_line_starting_pos array. It's easy to render screen lines one by one from it, and we'll only ever construct one additional screen line at a time. I'd hoped to delete other calls to Text.populate_screen_line_starting_pos, but it turns out we need to update it when editing sometimes. Give up on that for now; it's a no-op if not needed.
* update documentation on fragmentsKartik K. Agaram2023-04-012-2/+2
| | | | | | 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.
* stop creating a singleton table for every wordKartik K. Agaram2023-04-012-22/+22
|
* clean up some debug printsKartik K. Agaram2023-04-012-16/+0
| | | | | It's starting to become apparent just how little line_cache.fragments does for me now. Let's see if we can get rid of it entirely.
* no more Text allocationsKartik K. Agaram2023-04-015-41/+18
| | | | Is it just my imagination, or does the app feel lighter and more fluffy?
* App.width can no longer take a TextKartik K. Agaram2023-04-0111-71/+28
| | | | | 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.
* get rid of to_textKartik K. Agaram2023-04-017-42/+31
| | | | | | | | | | | | | I've been misunderstanding what Text objects are. They can render a lot of text with a given line height, word wrap, colors in various places. And I've been creating one for every word :facepalm: Unwinding this will take some time. This is just a first baby step for ad hoc text objects. Turns out I don't need to convert to Text to get something's rendered width, just the Font can do that. Thanks to the LÖVE Discord for educating me: https://discord.com/channels/329400828920070144/330089431379869708/1091535487333826580
* .Kartik K. Agaram2023-03-301-1/+0
|
* obsolete manual testKartik K. Agaram2023-03-301-4/+0
|
* better formattingKartik K. Agaram2023-03-281-9/+11
|
* update stale source X-(Kartik K. Agaram2023-03-262-11/+17
|
* bugfix: naming pointsKartik K. Agaram2023-03-264-5/+44
|
* bugfixKartik K. Agaram2023-03-262-4/+37
|
* bugfixKartik K. Agaram2023-03-261-2/+4
| | | | | | | | | | | | | | | | | | 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'
* clean up some absolute coordinatesKartik K. Agaram2023-03-252-3/+3
|
* update stale informationKartik K. Agaram2023-03-252-3/+3
|
* stop reusing cursor locations between filesKartik K. Agaram2023-03-251-1/+2
|
* experiment at avoiding some merge conflictsKartik K. Agaram2023-03-252-0/+27
| | | | https://merveilles.town/@akkartik/110084833821965708
* some minor cleanupKartik K. Agaram2023-03-234-5/+5
| | | | | 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.
* mouse wheel supportKartik K. Agaram2023-03-236-12/+84
|
* mention a new toolKartik K. Agaram2023-03-211-0/+2
|
* give a test a unique nameKartik K. Agaram2023-03-192-6/+6
|
* get typed in keystrokes to show on screen on iPadKartik K. Agaram2023-03-182-0/+21
| | | | Many thanks to Myte for helping test this!
* extract a functionKartik K. Agaram2023-03-181-10/+14
|
* consistently use App names for methods everywhereKartik K. Agaram2023-03-182-9/+9
|
* move default file locationKartik K. Agaram2023-03-181-1/+1
| | | | | | | | 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.
* remove a stale issueKartik K. Agaram2023-03-171-2/+0
|
* more bugfixKartik K. Agaram2023-03-173-6/+4
| | | | Don't crash on showing the log browser.
* bugfixKartik K. Agaram2023-03-174-18/+72
| | | | Thanks Mikoláš Štrajt.
* get rid of all bifold textKartik K. Agaram2023-03-174-874/+120
| | | | | | | | | | | | | | | It's just uneconomic to maintain given how little I've used it. I have a bug right now and no time to port the bugfix to all the complexities of the B side. I briefly considered tossing out the entire source editor. But I _have_ been using it to browse logs across sessions. The live editor doesn't quite cover all my use cases just yet. We now have duplication in the source editor only for: * syntax highlighting * hyperlinking [[WikiWords]] * ability to hide cursor (when showing file browser or Focus is in log browser)
* bring a few things in sync between run and sourceKartik K. Agaram2023-03-173-8/+29
|
* bugfix: disallow font size of 0Kartik K. Agaram2023-03-172-4/+8
| | | | Thanks Mikoláš Štrajt.
* state validation in source editor as wellKartik K. Agaram2023-03-172-2/+25
|
* more robust state validationKartik K. Agaram2023-03-172-7/+26
|
* bugfixKartik K. Agaram2023-02-092-0/+2
| | | | | | | | | | | 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.
* document the version of LÖVE I've been usingKartik K. Agaram2023-02-071-0/+3
|
* bugfix: up arrow when line above is a drawingKartik K. Agaram2023-01-314-3/+103
| | | | This bug was introduced in commit 528c64d690 on 2022-09-05 :/
* create a place for graphical log handlersKartik K. Agaram2023-01-302-1/+3
| | | | | | | | | | | | | Currently only used in pong.love, but let's keep the bad merge that had it broken since September from occurring again. To do that we'll be consistent across forks on where globals are initialized. I haven't appreciated the implications of main.lua for load order. log.lua comes first just because it's shared by both the main app and its 'source' editing environment. And it just so happens that source.lua was loading after log.lua resulting in the pong.love breakage. Now let's lean into that and enshrine that one should initialize log_render in log.lua.
* wait a little to flush disk before quittingKartik K. Agaram2023-01-281-0/+2
| | | | | | | 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.
* include instructions to install LÖVEKartik K. Agaram2023-01-241-1/+5
|
* demote codeberg.org in the list of mirrorsKartik K. Agaram2023-01-231-2/+2
| | | | It's been slow to push to lately, so I'm going to update it less frequently.
* remove a conditionKartik K. Agaram2023-01-221-1/+1
|
* clean up a printKartik K. Agaram2023-01-201-1/+0
|
* show another detail on test failureKartik K. Agaram2023-01-201-1/+1
|
* deduce test names on failuresKartik K. Agaram2023-01-207-1375/+1159
|
* link to default love.run for comparisonKartik K. Agaram2023-01-201-2/+2
|