cli-truncate

picks the cut point assuming the truncation character occupies a single column. With a wider (for example the common , width 3) the result exceeds . The and branches hard-code and , reserving a single column for the truncation character. The non- paths already reserve , and the branch already uses . This brings the two branches in line so the result stays within . With the default (width 1) the output is unchanged. Adds a regression test asserting for / + with a multi-column truncation character.

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.