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.
unicode-width
Determine displayed width of char and str types according to Unicode Standard Annex #11
and other portions of the Unicode standard.
This crate is #![no_std].
use unicode_width::UnicodeWidthStr;
fn main() {
let teststr = "Hello, world!";
let width = teststr.width();
println!("{}", teststr);
println!("The above string is {} columns wide.", width);
let width = teststr.width_cjk();
println!("The above string is {} columns wide (CJK).", width);
}
NOTE: The computed width values may not match the actual rendered column width. For example, many Brahmic scripts like Devanagari have complex rendering rules which this crate does not currently handle (and will never fully handle, because the exact rendering depends on the font):
extern crate unicode_width;
use unicode_width::UnicodeWidthStr;
fn main() {
assert_eq!("क".width(), 1); // Devanagari letter Ka
assert_eq!("ष".width(), 1); // Devanagari letter Ssa
assert_eq!("क्ष".width(), 2); // Ka + Virama + Ssa
}
Additionally, defective combining character sequences and nonstandard Korean jamo sequences may be rendered with a different width than what this crate says. (This is not an exhaustive list.) For a list of what this crate does handle, see docs.rs.
crates.io
You can use this package in your project by adding the following
to your Cargo.toml:
[dependencies]
unicode-width = "0.2"
Changelog
0.2.0
- Treat
\nas width 1 (#60) - Treat ambiguous
Modifier_Letters as narrow (#63) - Support
Grapheme_Cluster_Break=Prepend(#62) - Support lots of ligatures (#53)
Note: If you are using unicode-width for linebreaking, the change treating \n as width 1 may cause behavior changes. It is recommended that in such cases you feed already-line segmented text to unicode-width. In other words, please apply higher level control character based line breaking protocols before feeding text to unicode-width. Relying on any character producing a stable width in this crate is likely the sign of a bug.