| fix(tui): measure circled digits and keycaps as 2 columns everywhere (#4479) (#5001) The v0.9.1 fix (9be600bf4) made CodeWhale's own width helpers grapheme- aware, but Ratatui's renderer still measures ambiguous-width characters through its own unicode-width dependency, whose width() reports Enclosed Alphanumerics (circled digits/letters) as 1 column while CJK terminals paint them as 2. The 1-column cell placement shifts every downstream column by one, producing the intermittent missing-characters / phantom-space glitch that mouse selection only temporarily repairs. Fix the width accounting at all three layers: 1. Patch unicode-width 0.2.2 via [patch.crates-io] so UnicodeWidthChar:: width() and UnicodeWidthStr::width() report 2 columns for Enclosed Alphanumerics (U+2460-U+24FF), Dingbat Circled Digits (U+2776-U+2793), and Circled Numbers on Black Square (U+3248-U+324F). The patch is scoped to exactly those ranges; box-drawing glyphs and ellipsis keep their 1-column non-CJK widths, so table borders and truncation do not regress. 2. Keep the explicit range override in char_display_width as a defense in depth that does not depend on the patch. 3. Keep the U+20E3 override in grapheme_display_width / markdown_grapheme_width for keycap sequences that lack an FE0F variation selector (unicode-width reports those as 1 column too). Adds regression tests asserting UnicodeWidthChar::width('\u{2460}') == Some(2) and that circled digits count as 2 columns in text_display_width, plus the existing keycap suite. 26 ui_text tests and 52 markdown_render tests pass. | 1 个月前 |