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.
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.
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.
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.
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.
Before this commit it was scrolling up too much. Like, 2 screens up
instead of 1.
This commit seems like a follow-up to commits dabb7a6c4 and a9a8d5c17.
I'm not analyzing it too much, just focusing on this location after some
debug logs.
Those commits should probably have noticed the missing symmetric
keystroke. But I'm probably ignoring similar concerns in dealing with
this so superficially.
Scenario: press C-f and search for something.
Some of the time we get a crash with this call stack:
Error
text.lua:970: attempt to compare nil with number
Traceback
[love "callbacks.lua"]:228: in function 'handler'
text.lua:970: in function 'lt1'
search.lua:72: in function 'search_next'
run.lua:985: in function 'search_next_in_pane'
run.lua:939: in function 'search_next'
run.lua:784: in function 'text_input'
main.lua:237: in function <main.lua:230>
app.lua:31: in function <app.lua:22>
[C]: in function 'xpcall'
Not fixed yet.
The cause: plan_draw is conservative and sometimes tries to render panes
that never overlap the viewport.
This bug was exacerbated by fixing the inscript bug which started
setting screen_bottom1 to nil. But the problem existed before as well,
we just operated on stale screen_bottom1 locations.
This bug doesn't generalize to many other scenarios. It isn't a problem
for forks without the surface metaphor, though it might affect
driver.love as well. Even in pensieve.love, the only place that uses
screen_bottom while spanning multiple editors is find across the entire
surface.
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.
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
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
Kartik K. Agaram