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.
Being smart about the y coordinate is difficult, so they just bounce to
top of column for now. That way we're guaranteed the cursor pane will be
on screen.
I'm learning the hard way that resizing the window is a big deal. Only
do this when someone explicitly requests it, otherwise follow LÖVE's
defaults.
Therefore we're also going to stop trying to be smart when showing the
log browser. Leave window resizing to manual operations.
Now initialization looks a lot more similar for the run and source apps.
I just noticed we hadn't got this bugfix for Linux on the main app. How
had we not noticed this issue before? Answer: lines.love windows tend to
be tall and skinny, and resize must keep the window entirely within the
screen. So the window was staying in place just because it happened to
be running up against the bottom.
I find myself having to search rather than C-f a few times lately. Most
recently the post I was looking for was 39 above. Pensieve has been
rock-solid lately, so it seems worth growing the window a bit. Let's
just go aggressively to 100, see how things look.
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.
Kartik K. Agaram