fix(tui): spinner vanished whenever the status area was occupied - #171
Merged
Conversation
The status area (plan, multi-line info, pending user message) is its own layout region between the content area and the composer, but `paint()` *also* subtracted its height from the scratch buffer's cursor. Since the viewport is sized to exactly `desired_viewport_height()`, the content area shrank by `status_height` while the composed content simultaneously moved up by `status_height` — the bottom-aligned copy then had room for nothing but the reserved blank rows, and the spinner (plus the top of the live message) fell out of the viewport. A displayed plan made the progress spinner disappear entirely. Budget the status height against its own `status_budget` (the rows the layout can actually hand out) and leave `cursor_y` to the spinner and the live message. Cap a single entry at 20 rows like `measure_status_height` does, so paint never reserves more than the viewport height that was requested. Also retire a finished plan when the user submits the next message: it stays up for the whole turn and past the agent's closing answer, but a plan whose items are all completed belongs to the request that is over. A plan with open items survives — the new message usually continues it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The status area (plan, multi-line info, pending user message) is its own layout region between the content area and the composer, but
paint()also subtracted its height from the scratch buffer's cursor. Since the viewport is sized to exactlydesired_viewport_height(), the content area shrank bystatus_heightwhile the composed content simultaneously moved up bystatus_height— the bottom-aligned copy then had room for nothing but the reserved blank rows, and the spinner (plus the top of the live message) fell out of the viewport. A displayed plan made the progress spinner disappear entirely.Budget the status height against its own
status_budget(the rows the layout can actually hand out) and leavecursor_yto the spinner and the live message. Cap a single entry at 20 rows likemeasure_status_heightdoes, so paint never reserves more than the viewport height that was requested.Also retire a finished plan when the user submits the next message: it stays up for the whole turn and past the agent's closing answer, but a plan whose items are all completed belongs to the request that is over. A plan with open items survives — the new message usually continues it.