about summary refs log tree commit diff stats
path: root/text.lua
Commit message (Collapse)AuthorAgeFilesLines
* remove some support for long lines from source editorKartik K. Agaram2023-04-191-0/+3
| | | | | | | | | | | | 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
* rename a variableKartik K. Agaram2023-04-081-6/+5
|
* switch source side to new screen-line-based renderKartik K. Agaram2023-04-031-1/+0
| | | | 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-021-2/+2
|
* avoid saving fragments in linesKartik K. Agaram2023-04-011-67/+46
| | | | | | | 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..
* start thinking of compute_fragments as a detailKartik K. Agaram2023-04-011-1/+1
| | | | | | | | | | 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.
* stop creating a singleton table for every wordKartik K. Agaram2023-04-011-10/+10
|
* clean up some debug printsKartik K. Agaram2023-04-011-8/+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-011-14/+8
| | | | 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-011-11/+8
| | | | | 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.
* bugfix: naming pointsKartik K. Agaram2023-03-261-0/+1
|
* more bugfixKartik K. Agaram2023-03-171-1/+1
| | | | Don't crash on showing the log browser.
* bugfixKartik K. Agaram2023-03-171-9/+14
| | | | Thanks Mikoláš Štrajt.
* get rid of all bifold textKartik K. Agaram2023-03-171-1/+0
| | | | | | | | | | | | | | | 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)
* bugfix: up arrow when line above is a drawingKartik K. Agaram2023-01-311-1/+1
| | | | This bug was introduced in commit 528c64d690 on 2022-09-05 :/
* reduce use of rfindKartik K. Agaram2023-01-131-0/+24
|
* make love event names consistentKartik K. Agaram2022-12-231-3/+3
| | | | | I want the words to be easy to read, and to use a consistent tense. update and focus seem more timeless; let's make everything like those.
* support selections in the source editorKartik K. Agaram2022-09-061-1/+0
| | | | | I've only tested side A so far, and included a statement of how I want side B to behave.
* support drawings in the source editorKartik K. Agaram2022-09-051-17/+22
|
* editing source code from within the appKartik K. Agaram2022-09-031-5/+0
| | | | | integrated from pong.love via text.love: https://merveilles.town/@akkartik/108933336531898243
* set color for each fragmentKartik K. Agaram2022-08-231-1/+1
| | | | | In general it seems like good practice to minimize assumptions about the current color.
* helper: trimming whitespace from stringsKartik K. Agaram2022-08-231-0/+12
|
* fix a nameKartik K. Agaram2022-08-191-4/+4
|
* couple of accidental globalsKartik K. Agaram2022-08-181-2/+2
| | | | Luckily they didn't bite me yet.
* get rid of some ridiculous codeKartik K. Agaram2022-08-181-15/+5
| | | | | | I guess I wrote it before I settled into the idiom of: * first change cursor * then scroll if necessary
* spurious argsKartik K. Agaram2022-08-181-18/+18
|
* dead codeKartik K. Agaram2022-08-181-2/+0
|
* generalize a functionKartik K. Agaram2022-08-181-9/+10
|
* extract a variableKartik K. Agaram2022-08-181-2/+3
|
* simplifyKartik K. Agaram2022-08-181-4/+1
|
* move caching behavior inside compute_fragmentsKartik K. Agaram2022-08-171-6/+6
|
* remove some unnecessary workKartik K. Agaram2022-08-171-1/+3
|
* standardize scroll check in a few placesKartik K. Agaram2022-08-171-3/+3
| | | | | | | | | | | | I'm taking some lessons from pensieve.love here. It seem like specific pixel thresholds don't matter too much for plain lines.love. I'd probably feel safer if I just used Text.cursor_out_of_screen in these places, but it means we draw the screen twice for most events[1]. Let's see if we can get by with the current approach. [1] Or we have to start scheduling things for the next draw, which is more complex to orchestrate.
* simplify cursor-on-screen checkKartik K. Agaram2022-08-171-6/+6
|
* swap return valuesKartik K. Agaram2022-08-171-5/+5
|
* obsolete commentKartik K. Agaram2022-08-161-2/+0
|
* moveKartik K. Agaram2022-08-151-28/+28
|
* drop some unnecessary callsKartik K. Agaram2022-08-151-6/+0
|
* stop confusingly reading a globalKartik K. Agaram2022-08-151-2/+2
| | | | | | | The way Text.draw is called by edit.draw, we know it'll never be called for lines above screen_top1.line. Comparing every line on screen with screen_top1 makes no sense. The intent is really just to compare with screen_top1 only for the first line, and otherwise to ignore this check.
* bugfix: handle drawings when updating screen topKartik K. Agaram2022-08-111-0/+1
|
* renameKartik K. Agaram2022-08-111-24/+24
|
* bugfix: pagedown was sometimes bouncing upKartik K. Agaram2022-08-101-1/+1
|
* bugfix: backspace from start of final lineKartik K. Agaram2022-08-101-1/+5
|
* unnecessary argsKartik K. Agaram2022-08-101-1/+1
|
* click to the left of a lineKartik K. Agaram2022-07-291-2/+1
|
* bugfix: searchKartik K. Agaram2022-07-211-1/+1
| | | | | Broken since commit 188bbc73 9 days ago :/ At least we have a test for it now.
* use line cache for drawings as wellKartik K. Agaram2022-07-201-26/+26
|
* bugfix: where cursor is drawnKartik K. Agaram2022-07-201-4/+11
| | | | | | | The published version of lines.love was broken for almost an hour. The cursor would render one position to the right of where it really is. To fix it, this commit rolls back 26ba6e4e5a71. There doesn't seem a good way to test it.
* .Kartik K. Agaram2022-07-201-0/+2
|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-20 15:23:20 +0000