fix(#142): dispWidth counts display columns, not codepoints (CJK/emoji borders) - #155
Merged
Conversation
…i borders) The zigzag REPL table renderer measured cell width by counting codepoints, so East-Asian wide characters (CJK, kana, Hangul, fullwidth forms — 2 columns) and emoji (2 columns) were undercounted and combining marks overcounted. Column widths and cell padding in renderTable/renderRecords/wrapCell came out wrong and the box-drawing borders (│ ┌ ┼ …) misaligned on any non-ASCII table content. Add a wcwidth-style codepointWidth() (0 for combining/zero-width, 2 for the East-Asian wide + common emoji ranges, 1 otherwise; ASCII/Latin-1 skip the table) and make dispWidth decode each codepoint and sum real widths. wrapCell's hard-split for over-long words is now width-aware too, so a wide word can't overflow its column. Emoji-presentation via a trailing VS16 on a text-default base is left at width 1 (documented) — the CJK/emoji-plane cases that actually misalign tables are covered. New unit test in repl.zig (run by `zig build repl-test`) covers wide CJK, kana, fullwidth, precomposed vs combining, emoji, and ZWSP. Co-Authored-By: Claude Opus 4.8 (1M context) <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
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.
Fixes #142.
Problem
The zigzag REPL table renderer's
dispWidth(src/repl.zig) counted codepoints, each as width 1. East-Asian wide characters (CJK, kana, Hangul, fullwidth forms) and emoji are 2 columns; combining marks are 0. So column-width computation and cell padding inrenderTable/renderRecords/wrapCellwere wrong and the box-drawing borders (│ ┌ ┼ …) misaligned on any non-ASCII content.Fix
codepointWidth(cp)— wcwidth-style:0for combining/zero-width (combining marks, ZW*, variation selectors, BOM),2for the East-Asian wide + common emoji ranges,1otherwise. ASCII/Latin-1 short-circuit before any table lookup, so the hot path is untouched.dispWidthnow decodes each codepoint and sums real widths (with graceful fallback to 1 on decode errors).wrapCell's hard-split for over-long words is width-aware too, so a wide word can't overflow its column.Scope note: emoji-presentation via a trailing VS16 (
U+FE0F) on a text-default base is left at width 1 (documented in the code) — proper VS16 promotion needs lookahead; the CJK/kana/Hangul/fullwidth + emoji-plane cases that actually misalign tables are covered.Test
New unit test in
repl.zig(run byzig build repl-test— 17/17 pass) covers wide CJK, hiragana, fullwidth, precomposed-vs-combining, emoji, and ZWSP. Mainzig build testalso green.🤖 Generated with Claude Code