cli-truncate

Issue When is , the input is returned with a truncation character always appended — so the output is longer than the input and nothing is actually truncated. It happens for any input, even an empty string: Easy repro How shows up in practice The common idiom of reserving a margin off the terminal width: When stdout is not a TTY (piped to a file, redirected, or CI), is , so is : Fix A budget means the target width is unknown, so return the text untruncated instead of appending a truncation character. Other non-finite inputs are unchanged: already returned the text, negatives already returned . Added a test (plain + ANSI-styled input).

With , the budget is split with without reserving room for the truncation character. When the character does not fit in the remaining space (most visibly with , where it becomes , width 3), the right slice clamps to empty while the left slice plus the character already exceed : This breaks the documented invariant that the result occupies at most columns (/ stay within budget at the same widths). The fix caps the left slice at , so the two slices plus the truncation character never exceed , and drops the padding spaces when the padded character itself would not fit (so some text can still be shown). Normal widths are unchanged — still yields . Verified across ASCII and wide-character text for every position and setting (264 combinations); existing wide-char test (issue #28) still passes. Added regression assertions.

Summary Fixes #28 — output exceeds when the truncation boundary falls inside an East Asian wide (CJK) character Adds wrapper that re-slices with a 1-column narrower range when rounds up Applied to all three positions (, , ) Workaround for chalk/slice-ansi#43 Test plan [x] Added test that verifies for all widths 1–25 across all three positions with CJK input [x] All existing tests pass