about summary refs log tree commit diff stats
path: root/source_text.lua
Commit message (Collapse)AuthorAgeFilesLines
* purge obsolete term 'fragment'Kartik K. Agaram2024-07-081-7/+7
|
* use deepcopy where possibleKartik K. Agaram2024-06-231-14/+14
| | | | It's shorter and conveys intent better.
* crap, fix some final changes in the source editorKartik K. Agaram2024-06-111-7/+5
|
* stop caching startyKartik K. Agaram2024-06-111-6/+29
| | | | | This is quite useful because I used to have a long list of places in which to invalidate the cache.
* stop caching screen_bottom1Kartik K. Agaram2024-06-111-44/+79
| | | | | | | | | | | | | | | | | | | I'm not sure this is very useful. I had an initial idea to stop using screen_bottom1 in final_text_loc_on_screen, by starting from screen_top1 rather than screen_bottom1. But that changes the direction in which we scan for the text line in situations where there is somehow no text on screen (something that should never happen but I have zero confidence in that). Still, it doesn't seem like a bad thing to drastically reduce the lifetime of some derived state. Really what I need to do is throw this whole UX out and allow the cursor to be on a drawing as a whole. So up arrow or left arrow below a drawing would focus the whole drawing in a red border, and another up arrow and left arrow would skip the drawing and continue upward. I think that change to the UX will eliminate a whole class of special cases in the code.
* bugfix in source editorKartik K. Agaram2024-06-091-0/+19
|
* bugfix in cursor positioningKartik K. Agaram2024-02-081-1/+1
| | | | | | | | | | | | | | | | scenario: - create a long wrapping line - tap past end of first screen line Before this commit the cursor would be positioned not quite at the end of the screen line but one character before. In effect there was no way to position cursor at end of a wrapping line. I'm not sure how this bug has lasted so long. It was introduced in commit 8d3adfa36 back in June 2022, which was itself billed as a bugfix for "clicking past end of screen line". But when I go back to it this bug exists even back then. How did I miss it?! I wrote a test back then -- and the test was wrong, has always been wrong.
* use editor state font for width calculationsKartik K. Agaram2024-01-121-29/+29
|
* bugfix: utf-8Kartik K. Agaram2023-12-261-1/+2
|
* make button backgrounds optionalKartik K. Agaram2023-12-181-1/+1
|
* fix a couple of asserts missed in the recent auditKartik K. Agaram2023-12-091-2/+1
|
* port keyboard layout handling to source editorKartik K. Agaram2023-11-251-1/+8
|
* bugfix: infinite loop inside a very narrow windowKartik K. Agaram2023-11-241-1/+3
| | | | | | I'm not sure this can trigger everywhere (I've only been able to exercise it in Lua Carousel), but it seems like a safety net worth having against future modifications by anybody.
* establish a fairly fundamental invariantKartik K. Agaram2023-11-241-0/+6
| | | | | | | This commit doesn't guarantee we'll always catch it. But if this invariant is violated, things can get quite difficult to debug. I found in the Lua Carousel fork that all the xpcalls I keep around were actively hindering my ability to notice this invariant being violated.
* audit all assertsKartik K. Agaram2023-11-181-23/+22
| | | | | | | | | | | | | Each one should provide a message that will show up within LÖVE. Stop relying on nearby prints to the terminal. I also found some unnecessary ones. There is some potential here for performance regressions: the format() calls will trigger whether or not the assertion fails, and cause allocations. So far Lua's GC seems good enough to manage the load even with Moby Dick, even in some situations that caused issues in the past like undo.
* clearer API for drawing a buttonKartik K. Agaram2023-10-161-1/+1
| | | | | | Make it more obvious that the color passed in is just for the background. The icon will do the rest. r/g/b keys are more consistent with App.color().
* hide line numbers from log browserKartik K. Agaram2023-09-151-3/+5
|
* always show line numbers in source editorKartik K. Agaram2023-09-141-0/+2
| | | | | | The drawing buttons are now absolutely positioned, which is a horrible hack. But for just the source editor it seems good enough. The alternative is to modify magic constants in all the tests :/
* reorganize some commentsKartik K. Agaram2023-07-311-2/+2
| | | | | This keeps things consistent with other forks (links, lines-and-links) that are "conceptually upstream" of the source editor.
* bugfix: search highlight straddling screen linesKartik K. Agaram2023-07-311-7/+8
|
* remove a duplicate print to screenKartik K. Agaram2023-07-311-11/+9
| | | | In addition to being more efficient, this will simplify the next bugfix.
* extract a variableKartik K. Agaram2023-07-311-1/+2
|
* bugfix: highlight search patterns on the right lineKartik K. Agaram2023-07-311-2/+7
| | | | | | | | | | | | scenario: * position a wrapped line on screen * search for the word immediately after the point of wrapping Before this commit the word would be highlighted twice: - at the end of the first screen line - at the start of the second screen line Now it shows up at the right place.
* hoist and duplicate a conditionalKartik K. Agaram2023-07-311-3/+5
| | | | | | I'm duplicating the bounds check when drawing cursor and search highlight because they're separate concerns and require subtly different logic.
* improve a commentKartik K. Agaram2023-07-311-1/+1
|
* port inscript's bugfix to source editorKartik K. Agaram2023-06-041-0/+15
|
* add an assertKartik K. Agaram2023-05-141-0/+1
| | | | | 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.
* 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.
* bugfix: never use utf8 pos in string.subKartik K. Agaram2023-05-061-1/+3
| | | | | | 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
* remove some support for long lines from source editorKartik K. Agaram2023-04-191-13/+4
| | | | | | | | | | | | 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/+6
|
* 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.
* switch source side to new screen-line-based renderKartik K. Agaram2023-04-031-94/+111
| | | | Also copy over the implementation of links from pensieve.love.
* 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-12/+12
|
* 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-16/+10
| | | | 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.
* get rid of to_textKartik K. Agaram2023-04-011-2/+1
| | | | | | | | | | | | | 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
* update stale source X-(Kartik 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-784/+92
| | | | | | | | | | | | | | | 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-171-4/+20
|
* bugfix: up arrow when line above is a drawingKartik K. Agaram2023-01-311-2/+2
| | | | This bug was introduced in commit 528c64d690 on 2022-09-05 :/
* 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.
* hide editor cursor while in file navigatorKartik K. Agaram2022-09-181-3/+3
|
* support selections in the source editorKartik K. Agaram2022-09-061-1/+60
| | | | | I've only tested side A so far, and included a statement of how I want side B to behave.
* support hyperlinks in the source editorKartik K. Agaram2022-09-051-0/+33
| | | | Integrated from the pensieve fork.
* support drawings in the source editorKartik K. Agaram2022-09-051-60/+137
|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-03 11:48:47 +0000