Stefan Haller ed72851579 Reset the scroll to the top at first paint, not when the task starts ... When a main view re-renders content different from what it last showed, the scroll resets to the top. That reset fired synchronously when the task started — but with the off-screen render the previous content stays displayed until the swap, so resetting the origin up front scrolled that still-visible content to the top before the new content replaced it: a distracting jump when switching commits (or any item) while scrolled down. Defer the reset to the task's first paint (the swap), alongside the restore that already runs there: the previous content stays at its scroll until the new content takes its place, then the new content appears at the top. A same-content re-render keeps its scroll (no reset); a restore places the scroll itself. The "loading..." indicator path also resets the origin now, since it clears the previous content to show the message and must put it at the top. The reset moves out of NewTask (it no longer needs the task key or the pending restore for this) into the read loop, driven by LinesToRead.ResetOrigin, which the cmd/pty wrappers set from the key comparison the reset used to do. The manager's onNewKey callback is renamed resetOrigin to match its now-decoupled timing.		2026-08-08 12:58:59 +02:00
..
async_handler.go	Copy gocui files into lazygit repo under pkg/gocui	2026-04-30 14:29:08 +02:00
async_handler_test.go	Copy gocui files into lazygit repo under pkg/gocui	2026-04-30 14:29:08 +02:00
tasks.go	Reset the scroll to the top at first paint, not when the task starts	2026-08-08 12:58:59 +02:00
tasks_test.go	Restore the focused main view by patch identity on escape	2026-08-08 12:58:59 +02:00