A line that arrives in a window that is not shown is counted as unread, and AddLine then calls refreshStatusBar. That function was empty, so the window joined the status bar's unread list ([Act: ...]) only at the next SetStatus, such as after /window, /join or /connect.
UI now keeps the nick, target and connection state last passed to SetStatus, in fields read and written only on the event loop. refreshStatusBar redraws the status bar with them, and SetStatus stores them and then calls it. The new test TestUnreadLine sets the status bar, adds a line to a window that is not shown on a running UI, and reads the status bar back.
What a reader might trip over:
SwitchBuffer and SwitchToBuffer also call refreshStatusBar, so they now redraw the status bar with the previous target. The SetStatus that internal/cli/app.go calls right after each of them still sets the final text.
TestStatusBar adds its unread line before SetStatus, which is why it never caught this. The new test adds the line after SetStatus.
Disclosures:
Judgement call: renderStatusBar keeps its parameters, and refreshStatusBar passes it the stored values. This keeps the change small.
Model: opus-5-5
A line that arrives in a window that is not shown is counted as unread, and `AddLine` then calls `refreshStatusBar`. That function was empty, so the window joined the status bar's unread list (`[Act: ...]`) only at the next `SetStatus`, such as after `/window`, `/join` or `/connect`.
`UI` now keeps the nick, target and connection state last passed to `SetStatus`, in fields read and written only on the event loop. `refreshStatusBar` redraws the status bar with them, and `SetStatus` stores them and then calls it. The new test `TestUnreadLine` sets the status bar, adds a line to a window that is not shown on a running UI, and reads the status bar back.
What a reader might trip over:
- `SwitchBuffer` and `SwitchToBuffer` also call `refreshStatusBar`, so they now redraw the status bar with the previous target. The `SetStatus` that `internal/cli/app.go` calls right after each of them still sets the final text.
- `TestStatusBar` adds its unread line before `SetStatus`, which is why it never caught this. The new test adds the line after `SetStatus`.
Disclosures:
- Judgement call: `renderStatusBar` keeps its parameters, and `refreshStatusBar` passes it the stored values. This keeps the change small.
Model: opus-5-5
A line that arrives in a window that is not shown is counted as
unread, but refreshStatusBar did nothing, so the window joined the
status bar's unread list only at the next SetStatus. UI now keeps
the nick, target and connection state last passed to SetStatus, and
refreshStatusBar redraws the status bar with them.
Model: opus-5-5
PASS: a line that arrives in a window that is not shown now adds that window to the status bar's unread list at once, and the status bar keeps the nick, target and connection state last set.
Judgement call: switching window now redraws the status bar with the previous target until the SetStatus that follows it; every switch in internal/cli/app.go is followed by one and no typed line is handled in between, so I did not count it as a defect.
Model: opus-5-5
PASS: a line that arrives in a window that is not shown now adds that window to the status bar's unread list at once, and the status bar keeps the nick, target and connection state last set.
Judgement call: switching window now redraws the status bar with the previous target until the `SetStatus` that follows it; every switch in `internal/cli/app.go` is followed by one and no typed line is handled in between, so I did not count it as a defect.
Model: opus-5-5
clawbot
merged commit 2b1a49e59b into next2026-11-02 06:03:54 +01:00
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.
A line that arrives in a window that is not shown is counted as unread, and
AddLinethen callsrefreshStatusBar. That function was empty, so the window joined the status bar's unread list ([Act: ...]) only at the nextSetStatus, such as after/window,/joinor/connect.UInow keeps the nick, target and connection state last passed toSetStatus, in fields read and written only on the event loop.refreshStatusBarredraws the status bar with them, andSetStatusstores them and then calls it. The new testTestUnreadLinesets the status bar, adds a line to a window that is not shown on a running UI, and reads the status bar back.What a reader might trip over:
SwitchBufferandSwitchToBufferalso callrefreshStatusBar, so they now redraw the status bar with the previous target. TheSetStatusthatinternal/cli/app.gocalls right after each of them still sets the final text.TestStatusBaradds its unread line beforeSetStatus, which is why it never caught this. The new test adds the line afterSetStatus.Disclosures:
renderStatusBarkeeps its parameters, andrefreshStatusBarpasses it the stored values. This keeps the change small.Model: opus-5-5
PASS: a line that arrives in a window that is not shown now adds that window to the status bar's unread list at once, and the status bar keeps the nick, target and connection state last set.
Judgement call: switching window now redraws the status bar with the previous target until the
SetStatusthat follows it; every switch ininternal/cli/app.gois followed by one and no typed line is handled in between, so I did not count it as a defect.Model: opus-5-5