jp_term measures display width two ways

• Status: Todo
• Kind: Chore
• Authors: jp
• Date: 2026-09-08
• Label: package=jp_term
• Label: type=task

jp_term now holds two independent implementations of "how wide is this text on screen", which arrived from different directions and have never been compared.

• jp_term::width::display_width strips ANSI with strip-ansi-escapes, then measures with unicode-width. Its neighbours (truncate_to_width, wrap_ranges, prefix_end_for_width) walk grapheme clusters and probe for ligatures that collapse.
• jp_term::ansi::visual_width tokenizes with ansi::segments, joins the visible runs, and measures the result. advance_column builds on it and adds tab stops and carriage returns.

They disagree in at least one way that matters: visual_width counts a tab as one column and advance_column exists because of it, while the width module has no notion of a tab at all. Whether they disagree on OSC 8 hyperlinks, partial escapes, or ligature collapse is unknown — nothing tests them against each other.

Why it is worth doing

The duplication was invisible while the two lived in different crates. Now a reader of jp_term has to pick one, and the names give no help: display_width and visual_width are the same phrase.

Shape of a fix

Start with a test that runs both over the same inputs — plain ASCII, CJK, VS16 emoji, ZWJ sequences, tabs, OSC 8 links, escapes split mid-sequence — and records where they differ. That answers whether this is one function with two names or two functions with one job each.

If they agree except on tabs, collapse to one and keep advance_column as the cursor-position variant. If they genuinely differ, the names have to say how.