about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* Merge lines.loveKartik K. Agaram2023-05-301-5/+10
|\
| * bugfix: drawings in source editorKartik K. Agaram2023-05-302-10/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Broken since 2022-09 X-( Scenario: * switch to source editor * draw a line * wait 3 seconds Before this commit the app would crash and then fail to restart until you deleted the created .lua file from save dir. This is not the first time I've confused Lua's files and LÖVE's droppedFile objects. Just never rely on multiple args in file:write().
* | Merge lines.loveKartik K. Agaram2023-05-144-3/+5
|\|
| * hide cursor in log browser windowKartik K. Agaram2023-05-142-3/+3
| |
| * add an assertKartik K. Agaram2023-05-142-0/+2
| | | | | | | | | | I added this to catch a rare bug. I've had it locally for a few weeks now without hitting it. Doesn't hurt to publish it.
* | Merge lines.loveKartik K. Agaram2023-05-141-1/+1
|\|
| * bugfix: rendering hyperlinks in wrapping linesKartik K. Agaram2023-05-141-1/+1
| | | | | | | | | | | | Scenario: a long line containing a hyperlink towards the end. Before this commit the underline for the hyperlink was being rendered on an x pixel starting from the start of the line.
* | Merge lines.loveKartik K. Agaram2023-05-133-48/+62
|\|
| * bugfix: searching files containing unicodeKartik K. Agaram2023-05-133-48/+62
| | | | | | | | | | Before this change the cursor was moving, but not being highlighted properly when the cursor line contained unicode before the cursor.
* | Merge lines.loveKartik K. Agaram2023-05-063-4/+7
|\|
| * bugfix: never use utf8 pos in string.subKartik K. Agaram2023-05-063-4/+7
| | | | | | | | | | | | This is a violation of an existing rule in Manual_tests.md. The following command weakly suggests there aren't any others: grep ':sub(' *.lua |grep pos
* | Merge lines.loveKartik K. Agaram2023-04-211-4/+0
|\|
| * delete inapplicable issueKartik K. Agaram2023-04-211-4/+0
| |
* | Merge lines.loveKartik K. Agaram2023-04-211-2/+2
|\|
| * correct a characterizationKartik K. Agaram2023-04-211-2/+2
| |
* | Merge lines.loveKartik K. Agaram2023-04-191-13/+4
|\|
| * remove some support for long lines from source editorKartik K. Agaram2023-04-192-13/+7
| | | | | | | | | | | | | | | | | | | | | | | | A code editor is unlikely to need support for extremely long lines. And that kind of scroll is jarring anyway in a code editor. We don't read code like a novel, and less scroll per page implies more scrolling work. I'd gotten rid of this functionality and the test for it [1] back in the spokecone fork, but only took out the test when first pulling it into the source editor. [1] test_pagedown_often_shows_start_of_wrapping_line
* | Merge lines.loveKartik K. Agaram2023-04-112-5/+32
|\|
| * primitives for writing testsKartik K. Agaram2023-04-112-1/+28
| |
| * couple of typosKartik K. Agaram2023-04-111-4/+4
| |
* | Merge lines.loveKartik K. Agaram2023-04-101-0/+49
|\|
| * editor documentationKartik K. Agaram2023-04-101-0/+49
| |
* | Merge lines.loveKartik K. Agaram2023-04-092-12/+264
|\|
| * include a brief reference enabling many useful appsKartik K. Agaram2023-04-092-12/+264
| |
* | Merge lines.loveKartik K. Agaram2023-04-093-3/+17
|\|
| * deemphasize the source editorKartik K. Agaram2023-04-093-3/+17
| | | | | | | | | | | | | | | | | | This repo does not support freewheeling modification. It's a primitive to enable freewheeling modification in downstream forks. The source editor is a convenience, but it's a sharp tool and can easily leave the app in a broken state that requires dropping down to external tools (editor, file manager) to fix.
* | Merge lines.loveKartik K. Agaram2023-04-082-13/+17
|\|
| * rename a variableKartik K. Agaram2023-04-082-12/+11
| |
| * bugfix: syntax highlighting in source editorKartik K. Agaram2023-04-081-2/+7
| | | | | | | | | | | | | | I missed that comments only get highlighted at start of line. This seems a bit hacky. But it continues to trade off CPU for reduced memory footprint.
* | Merge lines.loveKartik K. Agaram2023-04-082-2/+2
|\|
| * enhance bugfix of commit a9aa3436f (Dec 2024)Kartik K. Agaram2023-04-082-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Scenario: * start out with some text on screen * select some text A, delete * select some more text B, delete * press C-z twice to restore A and B * press C-y twice Before this commit only the first C-y was having an effect (deleting B). The second was failing to delete A.
* | Merge lines.loveKartik K. Agaram2023-04-039-110/+118
|\|
| * switch source side to new screen-line-based renderKartik K. Agaram2023-04-039-106/+115
| | | | | | | | Also copy over the implementation of links from pensieve.love.
| * change cursor bounds check slightlyKartik K. Agaram2023-04-021-1/+1
| | | | | | | | | | | | This doesn't affect this fork directly, but it's a bad idea to assume the _app_ is always going to be doing just what a particular subsystem (here, the text editor in edit.lua+text.lua) is doing.
| * streamline the interface for Text.drawKartik K. Agaram2023-04-022-3/+2
| |
* | Merge lines.loveKartik K. Agaram2023-04-0218-250/+116
|\|
| * 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
* | Merge lines.loveKartik K. Agaram2023-03-300-0/+0
|\|
| * .Kartik K. Agaram2023-03-301-1/+0
| |
* | Merge lines.loveKartik K. Agaram2023-03-301-11/+8
|\|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-19 12:32:06 +0000