In neoirc-cli, every UI method that changes the screen calls QueueUpdateDraw from tview. In tview v0.42.0, that call waits until the event loop has run the update. Key handlers and the Enter handler of the input line run on the event loop itself. When one of them calls such a method, it waits for itself, and the client stops responding.
It happens on:
Alt and a digit (initKeyCapture in internal/cli/ui.go).
Any typed line whose command writes to the screen, such as /connect, /help, /window, or text typed while not connected. initInput in internal/cli/ui.go calls handleInput in internal/cli/app.go from the event loop.
The tests in internal/cli miss it because they call these handlers from the test, not from the running event loop. A throwaway test sent Alt and 1, and x then Enter, to a running UI: both stopped the event loop. Alt and x, which updates nothing, did not.
In `neoirc-cli`, every `UI` method that changes the screen calls `QueueUpdateDraw` from `tview`. In `tview` v0.42.0, that call waits until the event loop has run the update. Key handlers and the Enter handler of the input line run on the event loop itself. When one of them calls such a method, it waits for itself, and the client stops responding.
It happens on:
- Alt and a digit (`initKeyCapture` in `internal/cli/ui.go`).
- Any typed line whose command writes to the screen, such as `/connect`, `/help`, `/window`, or text typed while not connected. `initInput` in `internal/cli/ui.go` calls `handleInput` in `internal/cli/app.go` from the event loop.
The tests in `internal/cli` miss it because they call these handlers from the test, not from the running event loop. A throwaway test sent Alt and `1`, and `x` then Enter, to a running UI: both stopped the event loop. Alt and `x`, which updates nothing, did not.
Found while working on https://git.eeqj.de/sneak/neoirc/issues/221.
Model: opus-5-5
Plan: confirmed on next. QueueUpdate in tview v0.42.0 waits for the event loop to run the update, so a call from a key handler or the input line's Enter handler never returns. This comes right after #221, which changes the same files, and before the other open bugs.
Fix: the smallest plain change in internal/cli so that no handler running on the event loop waits on it, while updates from other goroutines, such as the poll loop, still go through QueueUpdateDraw. Typed lines must still be handled in the order they were typed. Change nothing else.
Definition of done
Alt and a digit, and every typed line (commands and plain text, connected or not), update the screen without the client hanging.
Messages that arrive from the server while the user types are still drawn.
A test in internal/cli runs a real UI event loop on a tcell simulation screen, sends Alt and 1, then a typed line and Enter, and fails within a few seconds if the event loop stops responding.
One reviewed PR against next.
Model: opus-5-5
Plan: confirmed on `next`. `QueueUpdate` in `tview` v0.42.0 waits for the event loop to run the update, so a call from a key handler or the input line's Enter handler never returns. This comes right after https://git.eeqj.de/sneak/neoirc/issues/221, which changes the same files, and before the other open bugs.
Fix: the smallest plain change in `internal/cli` so that no handler running on the event loop waits on it, while updates from other goroutines, such as the poll loop, still go through `QueueUpdateDraw`. Typed lines must still be handled in the order they were typed. Change nothing else.
## Definition of done
1. Alt and a digit, and every typed line (commands and plain text, connected or not), update the screen without the client hanging.
2. Messages that arrive from the server while the user types are still drawn.
3. A test in `internal/cli` runs a real UI event loop on a `tcell` simulation screen, sends Alt and `1`, then a typed line and Enter, and fails within a few seconds if the event loop stops responding.
4. One reviewed PR against `next`.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
In
neoirc-cli, everyUImethod that changes the screen callsQueueUpdateDrawfromtview. Intviewv0.42.0, that call waits until the event loop has run the update. Key handlers and the Enter handler of the input line run on the event loop itself. When one of them calls such a method, it waits for itself, and the client stops responding.It happens on:
initKeyCaptureininternal/cli/ui.go)./connect,/help,/window, or text typed while not connected.initInputininternal/cli/ui.gocallshandleInputininternal/cli/app.gofrom the event loop.The tests in
internal/climiss it because they call these handlers from the test, not from the running event loop. A throwaway test sent Alt and1, andxthen Enter, to a running UI: both stopped the event loop. Alt andx, which updates nothing, did not.Found while working on #221.
Model: opus-5-5
Plan: confirmed on
next.QueueUpdateintviewv0.42.0 waits for the event loop to run the update, so a call from a key handler or the input line's Enter handler never returns. This comes right after #221, which changes the same files, and before the other open bugs.Fix: the smallest plain change in
internal/cliso that no handler running on the event loop waits on it, while updates from other goroutines, such as the poll loop, still go throughQueueUpdateDraw. Typed lines must still be handled in the order they were typed. Change nothing else.Definition of done
internal/cliruns a real UI event loop on atcellsimulation screen, sends Alt and1, then a typed line and Enter, and fails within a few seconds if the event loop stops responding.next.Model: opus-5-5