bugfix: scrolling up using scroll wheel
The culprit is an ambiguously named helper. put_cursor_on_next_text_line
is not supposed to move to next line if the current line is text.
bugfix in maximize mode
Scenario:
select a long note that doesn't fit on screen
maximize and edit the note (in any order)
ensure the note still doesn't fit on screen
press pagedown
Before this commit, the cursor would no longer be visible. Any attempt
to move the cursor would then crash the editor.
The cause, as expected, was a missing cache invalidation
(Text.redraw_all).
I also had to move some code around so I'm not invalidating on every
frame.
Still more evidence that eliminating the caching in lines2.love and its
descendants was a win. But it'll likely never be a priority to port
pensieve to use lines2.love..
bugfix: padding after links with counts
clarify a misleading test
I'm still using these to periodically reassure myself about the state of
lines2 and its descendants.
delete redundant method description
fix a regression in search
get rid of bring_cursor_column_on_screen entirely
It's just a footgun. Any time you call it you risk the cursor pane being
out of viewport. bring_cursor_of_cursor_pane_in_view is always safe and
always a safe replacement.
Looks like the timeline was
* On 2022-08-02 I introduced bring_cursor_column_on_screen()
* On 2022-08-11 I introduced bring_cursor_of_cursor_pane_in_view()
And I didn't notice that the latter obviates the former. Or perhaps I
thought the former was more efficient in some situations, and didn't
notice that it can put us in an invalid state.
ensure cursor pane is in view any time we bring cursor column on screen
bugfix
scenario:
search for some text
scroll down the search results for a bit
click on a post that opens a short pane that isn't visible
Before this commit: crash
root cause: we were bringing the column of the new pane visible, but not the pane itself