Usability issue: unpredictable screen layout and cursor position when paging

[nborodikhin]

Usability issue - screen layout and cursor position on the screen is unpredictable when using pagination.

Scenario 1:

• initial position:
  • first line on the screen: 1
  • cursor on line 1
• page down:
  • first line on the screen: 42
  • cursor on line 42 (first line on the screen)
• page up:
  • first line on the screen: 1
  • cursor on line 1 (first line on the screen)

Scenario 2:

• initial position:
  • first line on the screen: 1
  • cursor on line 1
• page down:
  • first line on the screen: 42
  • cursor on line 42 (first line on the screen)
• page down:
  • first line on the screen: 83
  • cursor on line 83 (first line on the screen)
• page up:
  • first line on the screen: 2
  • cursor on line 42 (last line on the screen)

[nborodikhin]

There are two common strategies to handle cursor position while paging that I see often:

1. page one screen at a time but keep relative position of selection on the screen

• example: github web file editor

3. scroll content as much as possible to keep previous selected position on the screen, move selection to the first line

• example: VSCode

revdiff does neither:

• after page down, cursor position is always at the top line on the screen
  • expected: either be at the bottom of the window, or stay on the same line on the screen
• after page up, cursor position is always at the bottom line of the screen
  • expected: either be at the top line of the window, of stay on the same line on the screen

[umputun]

fixed in #125, will ship in the next release. pgdown/pgup now preserve the cursor's on-screen row, same as ctrl-d/ctrl-u.

also fixed a related edge case found in review: paging from a line with an annotation no longer leaves the cursor off-screen (the helper loop used to exit early on the cursorOnAnnotation flip and scroll the viewport anyway).