Stefan Haller 23474716ad Restore the focused main view's selection via the re-render task, not a post-hoc ReadToEnd ... Escaping to a focused main view restored the selection by scheduling, on the next UI tick, a ReadToEnd whose callback re-selected the saved line. But ReadToEnd fires its callback synchronously when the manager has no live read channel, and the re-render task triggered by the push creates that channel later, inside its own goroutine (after stopping the previous task). If the UI tick won that race, the restore ran before any content was loaded, FocusPoint no-oped against the unloaded line, and the selection was silently dropped — intermittently, and more often under load. Thread the restore through the task instead: a thenForNextTask hook on the buffer manager, folded into the next cmd/pty task's initial-read Then, mirroring scrollToOriginYForNextTask. It runs once the task has read enough to place the selection, and can't fire before the task exists. The scroll restore already applies at the task's first paint, which precedes the initial read's end, so the origin is in place when the selection is restored. This needs interactive verification (LAZYGIT_SLOW_RENDER + a real pager); see focused-main-view-notes.md §13. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>		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	Restore the focused main view's selection via the re-render task, not a post-hoc ReadToEnd	2026-08-08 12:58:59 +02:00
tasks_test.go	Let a cmd/pty task restore a saved scroll position at its first paint	2026-08-08 12:58:59 +02:00