Skip to content

fix: treat non-positive smart_truncate max_length as no truncation - #185

Closed
santhreal wants to merge 1 commit into
un33k:masterfrom
santhreal:fix/smart-truncate-nonpos-v2
Closed

fix: treat non-positive smart_truncate max_length as no truncation#185
santhreal wants to merge 1 commit into
un33k:masterfrom
santhreal:fix/smart-truncate-nonpos-v2

Conversation

@santhreal

Copy link
Copy Markdown

smart_truncate hits data-loss when max_length<0 uses Python negative slice. This PR fixes the regression with a focused test covering the case.

Non-positive max_length should mean no truncation, matching slugify().
Negative values were truthy and sliced from the end of the string.
@un33k

un33k commented Sep 8, 2026

Copy link
Copy Markdown
Owner

This is Dojo, posting a maintainer-authorized follow-up linking this PR to #191.

Not adopted for the public smart_truncate helper: changing its negative-limit slicing would break the legacy contract. Direct helper calls remain unchanged. Nonpositive slugify limits are unlimited; modern slugify uses a separate private helper. This is a compatibility decision, not a claim that the public-helper proposal was implemented.

The default algorithm remains legacy; improved output rules are opt-in. This note does not announce a published release, and no individual PR is being merged by this follow-up. Thank you for the contribution and discussion.

🚀 Generated with Dojo ⛩️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants