Skip to content

fix(textarea): count runes, not display width, for CharLimit#1008

Open
sueun-dev wants to merge 1 commit into
charmbracelet:mainfrom
sueun-dev:fix-textarea-charlimit-rune-count
Open

fix(textarea): count runes, not display width, for CharLimit#1008
sueun-dev wants to merge 1 commit into
charmbracelet:mainfrom
sueun-dev:fix-textarea-charlimit-rune-count

Conversation

@sueun-dev

Copy link
Copy Markdown

Length() sums uniseg.StringWidth per row, so CharLimit is enforced by display width rather than character count. Wide runes (CJK, emoji) take two cells, so a textarea with CharLimit=N stops accepting input at about N/2 characters. This contradicts the godoc on both Length() ("the number of characters currently in the text input") and CharLimit ("the maximum number of characters"), and disagrees with textinput, which enforces the same limit by rune count.

Repro: with CharLimit = 5, typing five wide runes one at a time leaves only three in the textarea, while five ASCII characters are accepted. textinput with the same limit accepts all five wide runes.

The fix counts runes (len(row), where row is []rune), matching the godoc and textinput. uniseg is still used for rendering, and the existing ASCII CharLimit tests are unchanged (width equals rune count for ASCII). Added TestCharLimitWideRunes covering the wide-rune case.

Length summed uniseg.StringWidth per row, so CharLimit (documented as
"the maximum number of characters") was enforced by display width. Wide
runes (CJK, emoji) occupy two cells, so a textarea with CharLimit=N
stopped accepting input at about N/2 characters. textinput enforces the
same CharLimit by rune count, so the two components disagreed.

Count runes instead, which matches Length's godoc and textinput.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant