Fork of lines.love without drawings; useful starting point for further forks

snapshot

I'm still trying to get those two tests to scroll and keep cursor on screen: typing in text at bottom screen line of screen until it wraps hitting down arrow from bottom screen line of screen (assuming pane extends further down)

But this small tweak to keychord_pressed_on_editable_pane isn't the answer. It ensures down arrow makes forward progress, but the first down arrow past bottom still makes the cursor invisible. Unclear why it gets into that state and how it's able to get out of that state now.

Things I remember now:

  • pane.cursor_y tracks the bottom pixel of the cursor
  • when you press down arrow in an editor and it doesn't use it, only the rest of the surface pans, thanks to ignore_editable_cursor_pane.

Another thing I've learned: the bug with down arrow is unrelated to wrapping lines. I can reproduce it in an editor containing all single-char lines.

It's almost like snap_cursor_to_bottom_of_screen isn't operating exactly opposite to draw in some situations. Assuming no line wrapping: screen_top = snap_cursor_to_bottom_of_screen(cursor) screen_bottom = edit.draw() assert(cursor.line == screen_bottom.line)

This is getting violated somehow?! Even if the screen height isn't an integral multiple of line_height, it seems like straightforward modulo arithmetic. If cursor is at bottom screen line and there's no wrapping: screen_top.line = cursor.line - math.floor(App.screen.height/line_height) screen_bottom.line = screen_top.line + math.floor(App.screen.height/line_height) assert(cursor.line == screen_bottom.line)

I'm still juggling tons of state in my head, feeling incredibly stupid.

Created by  Kartik K. Agaram  on August 16, 2022
QBL4YDQ5QC4MZ7RFS4ZSEBPN5WATAJ7UQLUPTXDUMXAMGBGQDOOQC
Dependencies
In channels
main
Change contents