[BUG] set_cell_size returns incorrect result for negative total with narrow text

[DaerenKim]

• I've checked docs and closed issues for possible solutions.
• I can't find my issue in the FAQ.

Describe the bug

set_cell_size() returns incorrectly truncated text when total is negative and the input consists entirely of single-cell-width characters.

For example:

from rich.cells import set_cell_size

print(repr(set_cell_size("ab", -1)))
print(repr(set_cell_size("abc", -1)))
print(repr(set_cell_size("abcdef", -1)))

Currently this produces:

'a'
'ab'
'abcde'

Expected:

''
''
''

The issue is caused by the total <= 0 guard being placed after the single-cell-width fast path:

if _is_single_cell_widths(text):
    size = len(text)
    if size < total:
        return text + " " * (total - size)
    return text[:total]

if total <= 0:
    return ""

For single-cell-width strings, negative slicing is therefore reached before the guard. Python's negative slicing causes part of the string to be returned.

For comparison, strings containing wide characters correctly return an empty string because they do not take the single-cell-width fast path.

The fix is to move the total <= 0 check before the _is_single_cell_widths() fast path.

I have also added regression tests covering negative total values.

Platform

• macOS
• Python 3.13.6

The issue is reproducible independently of terminal software.

I have already implemented the fix and added regression tests in my fork. I would be happy to submit the changes as a pull request if I can be granted contributor access, or I can follow whatever contribution process you prefer.

[Mynk11]

Independent confirmation of the diagnosis, plus one thing that isn't in the report: this reaches users through Text.truncate, not only the helper.

Text.truncate passes max_width - 1 straight into set_cell_size for ellipsis overflow, so a zero budget becomes -1:

>>> from rich.text import Text
>>> t = Text("hello"); t.truncate(0, overflow="ellipsis"); t.plain
'hell…'

Truncating to 0 cells returns 5 cells — wider than truncate(1) → '…' and truncate(2) → 'h…', and wider than the budget the caller asked for. So a table column or nested panel squeezed to zero width gets text back instead of nothing, which makes this a layout bug rather than an internal edge case.

I checked @DaerenKim's proposed fix (moving the total <= 0 guard above the fast path) against main at 9d8f9a3 and it holds up: set_cell_size returns '' for all negative totals, and truncate(0, overflow="ellipsis") drops from 'hell…' to '…'. No regressions — 948 tests pass both with and without the change. The 8 failures I see in test_syntax.py / test_markdown.py are the pygments 2.21 incompatibility from #4209 and are byte-identical either way.

One residue worth a decision: the ellipsis branch appends "…" unconditionally, so truncate(0) lands on '…' (1 cell) rather than 0. Reaching exactly 0 would need a max_width <= 0 guard in truncate itself — a separate behaviour change, so probably its own issue.

@DaerenKim already has the fix and regression tests ready in a fork, so this is supporting evidence rather than a competing patch.

Disclosure per AI_POLICY.md: this investigation was AI-assisted — Claude (Anthropic). The reproductions and test runs above were executed against a local checkout, not inferred.

[itzzdev09]

I have a fix for this ready, but per AI_POLICY.md a PR needs a maintainer-approved solution to link to first — so, @willmcgugan, would this approach be acceptable?

Proposed change — move the existing guard above the fast path in set_cell_size, so a non-positive total is handled before any slicing:

+    if total <= 0:
+        return ""
     if _is_single_cell_widths(text):
         size = len(text)
         if size < total:
             return text + " " * (total - size)
         return text[:total]
-    if total <= 0:
-        return ""

That's the whole change — no new branches, and the wide-character path is untouched since it already returned early for total <= 0.

On the Text.truncate angle raised above: the reachable case is max_width=0 rather than 1. truncate passes max_width - 1, so max_width=1 gives a 0 budget (already correct), and max_width=0 gives -1. Before the change, Text("abcdef").truncate(0, overflow="ellipsis") produced "abcde…" — six cells for a zero-width budget. After, it produces "…".

Verified locally:

• Negative totals return "" for both narrow and wide text; total=0 and all positive totals are unchanged (padding and cropping behave exactly as before, including the existing 😽😽 cases).
• Full suite: 975 passed, 9 failed both before and after — the 9 failures are all in test_syntax.py and are the pre-existing pygments 2.21.0 incompatibility from [BUG] Incompatibility with pygments 2.21.0 #4209, unrelated to this.
• The regression test I'd add fails without the change and passes with it.

Happy to open the PR with the test if you're on board. Disclosure per the policy: written with Claude Code (Claude Opus 5).