about summary refs log tree commit diff stats
path: root/text_tests.lua
Commit message (Collapse)AuthorAgeFilesLines
* commentKartik K. Agaram2024-06-111-2/+2
|
* stop caching startyKartik K. Agaram2024-06-111-5/+5
| | | | | 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-106/+0
| | | | | | | | | | | | | | | | | | | 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.
* fix a crash involving mouse and drawingsKartik K. Agaram2024-06-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Thanks Alex Schroeder for reporting this crash. The scenario: * Edit a file like say this repo's Readme. * The second line is empty and there's a '+' to insert a drawing. Click on that. * Resize the window so just the first line of text and the drawing are visible. * Close the window. * Reopen lines.love, it will reopen the same file. * Click on the left margin to the left of the drawing. Before this commit these steps yielded the following crash: Error: bad argument #1 to 'len' (string expected, got nil) text.lua:626: in function 'pos_at_end_of_screen_line' edit.lua:298: in function 'mouse_press' There were two distinct problems here: 1. State.screen_bottom1 is not required to point to a text line, it could just as well be a drawing. I have been sloppy in handling that. 2. The bug was partially masked (the need to close and reopen the window) by a second bug: inserting a drawing was not invalidating the cache I save of starty coordinates for each line. (I've inserted and deleted starty invalidations a few times in the past, but it looks like I'd never had one in this particular location edit.draw before.) How did these issues get missed for years? - Even though I use lines.love on a daily basis, it turns out I don't actually create line drawings all that often. - When I do, I'm still living in files that are mostly text with only an occasional drawing. - I keep my windows fairly large. Between these 3 patterns, the odds of running into a drawing as the first or bottom-most line on the screen were fairly small. And then I had to interact with it. I suspect I tend to interact with drawings after centering them vertically. --- Bug #1 in particular has some interesting past history. * Near the start of the project, when I implemented line-wrapping I started saving screen_bottom, the bottom-most line displayed on screen. I did this so I could scroll down easily just by assigning `screen_top = screen_bottom`. (On the other hand, scrolling up still required some work. I should perhaps get rid of it and just compute scrolls from scratch each time.) * Also near the start of the project, I supported selecting text by a complex state machine spanning keypress, mouse press and mouse release: mouse click (press and immediate release) moves cursor mouse drag (press and much later release) creates selection shift-click selects from current cursor to click location shift-movement creates/grows a selection * On 2023-06-01, inscript reported a bug. Opening a window with just a little bit of text (lots of unused space in the window), selecting all the text and then clicking below all the text would crash the editor. To fix this I added code at the bottom of edit.mouse_press which computed the final visible line+pos location and used that in the cursor-move/text-selection state machine. It did this computation based on.. screen_bottom. But I didn't notice that screen_bottom could be a drawing (which has no pos). This commit's bug/regression was created. * On 2023-09-20, Matt Wynne encountered a crash which got me to realize I need code at the bottom of edit.mouse_release symmetric to the code at the bottom of edit.mouse_press. I still didn't notice that screen_bottom could be a drawing. So in fixing inscript's bug report, I introduced (at least) 2 regressions, because I either had no idea or quickly forgot that screen_bottom could point at a drawing. While I created regressions, the underlying mental bug feels new. I just never focused on the fact that screen_bottom could point at a drawing. This past history makes me suspicious of my mouse_press/mouse_release code. I think I'm going to get rid of screen_bottom entirely as a concept. I'll still have to be careful though about the remaining locations and which of them are allowed to point at drawings: - cursor and selection are not allowed to point at drawings - screen_top and screen_bottom are allowed to point at drawings I sometimes copy between these 4 location variables. Auditing shows no gaps where cursor could ever end up pointing at a drawing. It's just when I started using screen_bottom for a whole new purpose (in the mouse_press/release state machine) that I went wrong. I should also try getting rid of starty entirely. Is it _really_ needed for a responsive editor? I think I introduced it back when I didn't know what I was doing with LÖVE and was profligately creating text objects willy-nilly just to compute widths. Getting rid of these two fairly global bits of mutable state will hopefully make lines much more robust when the next person tries it out in 6 months :-/ X-( Thanks everyone for the conversation around this bug: https://merveilles.town/@akkartik/112567862542495637 --- Bug #2 has some complexity as well, and might lead to some follow-on cleanup. When I click on the button to insert a new drawing, the mouse_release hook triggers and moves the cursor below the new drawing. This is desirable, but I'd never noticed this happy accident. It stops working when I invalidate starty for all lines (which gets recomputed and cached for all visible lines on every frame). Fixing this caused a couple of unit tests start crashing for 2 reasons that required their own minor fixes: - My emulated mouse press and release didn't have an intervening frame and so mouse_release no longer receives starty. Now I've added a call to edit.draw() between press and release. This might actually bite someone for real someday, if they're running on a slow computer or something like that. I've tried to click really fast but I can't seem to put mouse_press and release in the same frame (assuming 30 frames per second) - My tests' window dimensions often violate my constraint that the screen always have one line of text for showing the cursor. They're unrealistically small or have a really wide aspect ratio (width 2x of height). I suspect lines.love will itself crash in those situations, but hopefully they're unrealistic. Hmm, I wonder what would happen if someone maximized in a 16:9 screen, that's almost 2x.. Anyways, I've cleaned a couple of tests up, but might need to fix up others at some point. I'd have to rejigger all my brittle line-wrapping tests if I modify the screen width :-/ X-(
* bugfix in cursor positioningKartik K. Agaram2024-02-081-6/+6
| | | | | | | | | | | | | | | | 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.
* more carefully pass the 'key' arg aroundKartik K. Agaram2024-02-041-81/+81
|
* streamline button.luaKartik K. Agaram2023-12-161-0/+1
|
* fix all tests in LÖVE v12Kartik K. Agaram2023-10-091-3/+10
| | | | | | | | | | | | | | | | This is all quite hacky. Many of my tests are unfortunately brittle to changes in text rendering. Fortunately there's only one test that currently requires a hacky special case (and a second test I tweaked slightly to be more robust). I can't think of a better approach. It doesn't help to standardize the font, because version changes still come with changes to text-shaping algorithms even if the font itself is unchanged. I could base all my assertions on the widths of individual characters, but that would make the tests much less readable and not express intent as clearly. So here we are, with hopefully just a few hacky special cases (there might be a few more as LÖVE v12 advances towards publication, and in further versions).
* bugfix: clear selection when clicking above or below linesKartik K. Agaram2023-09-201-0/+24
| | | | | | | | | | | | | | | | | | | Matt Wynne pointed out that snap.love would crash when a node went off screen. While debugging it I noticed that selection1 was being set when it shouldn't be. Turns out I introduced a bug when I fixed the inscript bug back in June (commit 9656e137742). One invariant I want to preserve is: selection1 should be unset after a mouse click (press and release without intervening drag). This invariant was violated in my bugfix back in June. I was concerned only with selection back then, and I didn't realize I was breaking the mouse click case (in a fairly subtle way; you can have selection set, and when it's set identically to the cursor everything looks the same). I think there might still be an issue in snap.love after this fix. I noticed screen_bottom1.pos was nil, and as far as I recall that should never happen.
* bugfix: inscript's bugKartik K. Agaram2023-06-041-0/+27
| | | | | | | | | | To fix this I have to first stop incrementally updating screen_bottom1 in the middle of a frame. Now it always has a good value from the end of a frame. I'm also running into some limitations in the test I'd ideally like to write (that are documented in a comment), but I still get some sort of automated test for this bugfix.
* handle wrapping linesKartik K. Agaram2023-06-031-0/+17
|
* change how we handle clicks above top marginKartik K. Agaram2023-06-031-24/+19
|
* get rid of recent_mouseKartik K. Agaram2023-06-011-23/+23
| | | | | | | | | | | It's a hack: - if you start selecting from below final line the start of the selection is the most recent click even if it was forever ago - (the crash we're currently fixing) if you start up and immediately select all then click below final line => crash. recent_mouse was never set. - getting rid of it breaks no tests (except the crash we're currently fixing)
* failing test now looks realisticKartik K. Agaram2023-06-011-0/+46
|
* bugfix: searching files containing unicodeKartik K. Agaram2023-05-131-10/+10
| | | | | Before this change the cursor was moving, but not being highlighted properly when the cursor line contained unicode before the cursor.
* avoid saving fragments in linesKartik K. Agaram2023-04-011-1/+1
| | | | | | | 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..
* give a test a unique nameKartik K. Agaram2023-03-191-3/+3
|
* bugfixKartik K. Agaram2023-03-171-0/+22
| | | | Thanks Mikoláš Štrajt.
* bugfix: up arrow when line above is a drawingKartik K. Agaram2023-01-311-0/+50
| | | | This bug was introduced in commit 528c64d690 on 2022-09-05 :/
* deduce test names on failuresKartik K. Agaram2023-01-201-533/+438
|
* overzealous search-and-replaceKartik K. Agaram2022-12-231-1/+1
|
* make love event names consistentKartik K. Agaram2022-12-231-22/+22
| | | | | 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.
* streamline one more test nameKartik K. Agaram2022-12-131-14/+14
|
* more streamlined test namesKartik K. Agaram2022-12-131-29/+29
| | | | https://lobste.rs/messages/e1rimy
* remove a duplicate testKartik K. Agaram2022-12-131-27/+10
|
* bugfix: check after cursor on same line when searching upwardsKartik K. Agaram2022-08-111-0/+19
|
* bugfix: search upwardsKartik K. Agaram2022-08-111-0/+19
|
* bugfix: check before cursor on same lineKartik K. Agaram2022-08-111-0/+19
|
* bugfix: pagedown was sometimes bouncing upKartik K. Agaram2022-08-101-0/+17
|
* bugfix: backspace from start of final lineKartik K. Agaram2022-08-101-0/+16
|
* click to the left of a lineKartik K. Agaram2022-07-291-0/+19
|
* line.y -> line_cache.starty in a few more placesKartik K. Agaram2022-07-271-4/+4
| | | | | | Disquieting that none of my tests caught these. On the other hand, I also haven't noticed any issues in practice. Perhaps cache invalidation is often unnecessary.
* bugfix: skip over drawings when searchingKartik K. Agaram2022-07-251-7/+2
|
* bugfix: searchKartik K. Agaram2022-07-211-0/+33
| | | | | Broken since commit 188bbc73 9 days ago :/ At least we have a test for it now.
* bugfix: where cursor is drawnKartik K. Agaram2022-07-201-10/+10
| | | | | | | 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.
* exclude left margin from my word-split heuristicKartik K. Agaram2022-07-201-2/+2
| | | | | Gratifying how few tests need changing. Recent commits seem on the right track.
* allow Text.nearest_pos_less_than to return 0Kartik K. Agaram2022-07-201-2/+2
| | | | This eliminates another case of overflowing margins.
* unify two similar functionsKartik K. Agaram2022-07-191-13/+12
| | | | | | The cost is just having to tweak a few more brittle tests. I can't actually perceive any difference in how the cursor moves when I click on text.
* keep text from overflowing right marginKartik K. Agaram2022-07-191-36/+33
| | | | | | | | | | I've been sloppy about this so far, and outside of tests I can't find any examples where it matters, but it matters in a potential fork where I'm rendering multiple columns of text. It's unfortunate that my tests have this level of brittleness. What I'd really like to assert in many of these changed lines is that the text stays inside the margins and that more text would overflow margins.
* delete some duplicate initializationKartik K. Agaram2022-07-191-4/+0
|
* bugfix: couple of margin-relative computationsKartik K. Agaram2022-07-171-1/+61
|
* separate data structure for each line's cache dataKartik K. Agaram2022-07-171-12/+96
| | | | I have no idea what the performance implications of this are..
* bring back a set of constantsKartik K. Agaram2022-07-161-1/+1
| | | | | It's starting to sink in that I don't want hard-coded constants inside objects.
* more decoupling editor tests from AppKartik K. Agaram2022-07-161-1/+1
|
* more decoupling editor tests from AppKartik K. Agaram2022-07-161-3/+3
|
* make test initializations a little more obviousKartik K. Agaram2022-07-151-93/+93
|
* left/right margin -> left/right coordinatesKartik K. Agaram2022-07-121-121/+214
| | | | | Editor state initialization now depends on window dimensions, so we have to more carefully orchestrate startup.
* call edit rather than App callbacks in testsKartik K. Agaram2022-07-121-101/+101
|
* start passing in Editor_state explicitlyKartik K. Agaram2022-07-121-76/+77
| | | | | | | | | | | | In this commit, top-level edit functions: - edit.draw - edit.update - edit.quit - edit.mouse_pressed - edit.mouse_released - edit.textinput - edit.keychord_pressed - edit.key_released
* initialize contains test stateKartik K. Agaram2022-07-121-87/+0
|