about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 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
|\|
| * obsolete manual testKartik K. Agaram2023-03-301-4/+0
| |
| * better formattingKartik K. Agaram2023-03-281-9/+11
| |
* | Merge lines.loveKartik K. Agaram2023-03-262-11/+17
|\|
| * update stale source X-(Kartik K. Agaram2023-03-262-11/+17
| |
* | Merge lines.loveKartik K. Agaram2023-03-263-5/+76
|\|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-19 23:05:21 +0000