about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
...
| * | 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 text.loveKartik K. Agaram2023-05-063-4/+7
|\| |
| * | 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 text.loveKartik K. Agaram2023-04-211-4/+0
|\| |
| * | Merge lines.loveKartik K. Agaram2023-04-211-4/+0
| |\|
| | * delete inapplicable issueKartik K. Agaram2023-04-211-4/+0
| | |
* | | Merge text.loveKartik K. Agaram2023-04-211-2/+2
|\| |
| * | Merge lines.loveKartik K. Agaram2023-04-211-2/+2
| |\|
| | * correct a characterizationKartik K. Agaram2023-04-211-2/+2
| | |
* | | Merge text.loveKartik K. Agaram2023-04-191-13/+4
|\| |
| * | 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 text.loveKartik K. Agaram2023-04-112-5/+32
|\| |
| * | 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 text.loveKartik K. Agaram2023-04-101-0/+49
|\| |
| * | Merge lines.loveKartik K. Agaram2023-04-101-0/+49
| |\|
| | * editor documentationKartik K. Agaram2023-04-101-0/+49
| | |
* | | Merge text.loveKartik K. Agaram2023-04-092-12/+264
|\| |
| * | Merge lines.loveKartik K. Agaram2023-04-092-12/+264
| |\|
| | * include a brief reference enabling many useful appsKartik K. Agaram2023-04-092-12/+264
| | |
* | | Merge text.loveKartik K. Agaram2023-04-093-3/+17
|\| |
| * | 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 text.loveKartik K. Agaram2023-04-082-13/+17
|\| |
| * | 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 text.loveKartik K. Agaram2023-04-082-2/+2
|\| |
| * | 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 text.loveKartik K. Agaram2023-04-039-110/+118
|\| |
| * | 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 text.loveKartik K. Agaram2023-04-0217-249/+115
|\| |
| * | 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?
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2025-07-21 15:18:43 +0000