fix(textarea): prevent infinite loop in wordLeft on empty/start-of-text input - #1019
Open
djedi-knight wants to merge 1 commit into
Open
fix(textarea): prevent infinite loop in wordLeft on empty/start-of-text input#1019djedi-knight wants to merge 1 commit into
djedi-knight wants to merge 1 commit into
Conversation
wordLeft used an unconditional for{} that only exits on a non-space rune.
On empty input (row 0, col 0) characterLeft is a no-op and the break
condition 0 < 0 is never true, freezing the event loop on alt+left/alt+b.
Add a start-of-text guard mirroring doWordRight's end-of-text break.
Fixes charmbracelet/bubbletea#1652
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.
Suggested PR
Title:
fix(textarea): prevent infinite loop in wordLeft on empty/start-of-text inputDescription:
Summary
textarea's word-backward motion (alt+left/alt+b) could spin forever and freeze the event loop when the textarea was empty or the cursor was already at the start of the text.wordLeft()used an unconditionalfor {}that only exits once it finds a non-space rune:When the textarea is empty (
m.value == [][]rune{{}}, cursor atrow=0, col=0),characterLeft(true)is a no-op and the break conditionm.col < len(m.value[m.row])evaluates to0 < 0 == false. The loop never terminates, hanging the program.Fix
Add a start-of-text guard at the top of the loop, mirroring the end-of-text break that
doWordRight()already has. SincecharacterLeftalways makes progress (moving up a row and/or left a column) until it reachesrow 0, col 0, returning at that point guarantees termination and makes the motion a no-op on empty input.Related helpers audited
deleteWordLeft/deleteWordRight— already guardm.col == 0/len(m.value[m.row]) == 0; safe.doWordRight(and its callerswordRight,uppercaseRight,lowercaseRight,capitalizeRight,deleteWordRight) — already break at end of text; safe.wordLeftwas the only word-motion helper missing the boundary guard.Testing
Added
TestWordBackwardEmptyTextareaTerminates, which drives an empty textarea withalt+leftandalt+b. The update runs on a goroutine guarded by a 2s timeout, so a regression fails the test rather than hanging the suite, and asserts the motion is a no-op (cursor stays atrow 0, col 0, value stays empty).Verified the test fails against the unpatched code (times out) and passes with the fix.
go test ./...,go vet ./..., andgofmt -l .are all clean.Fixes charmbracelet/bubbletea#1652