Fix TUI panic on narrow terminal: negative strings.Repeat count#19
Merged
Conversation
When the terminal is resized so that m.width-m.treeWidth-5 drops below 4,
SetSize stored a small/negative raw width in s.width while clamping only
the viewport's innerWidth. updateContent then computed contentWidth as
s.width-4 (negative), passed it through to renderItem, where
strings.Repeat("─", min(width, 60)) panicked with "negative Repeat
count" and crashed the TUI.
Clamp contentWidth in updateContent to a minimum of 1, mirroring the
existing innerWidth clamp in SetSize, and defensively guard the
strings.Repeat call site so a negative width can never reach it again.
Closes claude-esp-5k0
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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
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.
Summary
strings: negative Repeat count) that crashed the TUI when the terminal was resized so that the stream pane's effective inner width dropped below 4 columns.-10.Root cause
StreamView.SetSizeclampedinnerWidth/innerHeightfor the viewport but stored the raw caller-provided width ins.width. With the tree visible,model.go:456callsSetSize(m.width-m.treeWidth-5, ...), which can go negative on narrow terminals.updateContentthen computedcontentWidth := s.width - 4(more negative), passed it torenderItem, wherestrings.Repeat(\"─\", min(width, 60))panicked.Trace from the user's crash:
Fix
contentWidthto a minimum of 1 inupdateContent, mirroring the existinginnerWidthclamp inSetSize.strings.Repeatsite inrenderItemso a negative width can never reach it again.Audit
I scanned the TUI for the same class of bug:
tree.go— threestrings.Repeatsites; each already gated byif X < 1 { X = 1 }orif gap >= 1. Safe.stream.go::truncateContent— already guards withwidth > 0. Safe.model.go::wrappedRows— guardsm.width <= 0. Safe.The only similar-class bug was the one fixed here.
Test plan
go build ./...go test ./...passesTestStreamView_NarrowResizeDoesNotPanicpanics on the unfixed code (verified by temporarily reverting) and passes with the fixCloses claude-esp-5k0.
🤖 Generated with Claude Code