Collaborative wiki for a few of us. Fork of lines.love.

roll back experiment of commit 926c66a908 as well

scenario: paste enough text that the note needs to scroll Before this commit the cursor would end up outside the viewport and crash.

Turns out my experiments of commit 93683450a4 (Dec 24) and commit 926c66a908 (Dec 21) were connected. I need the latter precisely because I need the former.

Summary: the editor widget was originally implemented in isolation, to take over the whole window (App.screen). If it starts low down the window it assumes it's always going to have just a few lines of height to work with. That causes it to scroll too much. I have a little tweak to detect such situations and not use the editor's scrolling logic. But if I don't use the editor's scrolling logic I also shouldn't pretend I did.

Another way to put it: The decision of when to adjust the global viewport from within a single editor buffer can get intricate. We'll let it make any heuristic choices it likes as long as it communicates accurately with the outside whether it changed the global viewport.

One open question here: if I do my tweak it pans the viewport anyway. So why does it matter whether the outside does or not? There must be a discrepancy in bring_cursor_into_view that this commit is patching over. And I do see that comment in bring_cursor_into_view suggesting all is not right with it. It was introduced in commit 1ee1cbab6.

I'll come back again:

  • editor scrolling is jarring when editor.top is low down the screen
  • alternative logic using bring_cursor_of_cursor_pane_in_view
  • bring_cursor_of_cursor_pane_in_view has a hack to keep cursor from hiding behind search bar. But the hack is still only moving the viewport down, which should help with the above scenario.

Created by  Kartik K. Agaram  on December 29, 2022
37AATGG5QIXOBXWA3DMSVMIIDSULA36NPETHOYZIOZ4G4RZLMHCAC
Change contents