Skip to content

Sort a base name before its numbered siblings [patch] - #70

Merged
matt-edmondson merged 1 commit into
mainfrom
fix/61-text-chunk-prefix
Oct 13, 2026
Merged

matt-edmondson merged 1 commit into
mainfrom
fix/61-text-chunk-prefix

Conversation

@matt-edmondson

Copy link
Copy Markdown
Contributor

Fixes #61

What changed

When one text chunk was a strict prefix of the other, CompareTextChunks put the shorter chunk first without looking at what came after it. Comparing "file.txt" with "file" + 1 + ".txt" never compared the . against the 1, so report.pdf sorted after report2.pdf.

Now, when the shared prefix matches and the lengths differ:

  • if the shorter chunk's string ends there, it comes first, as before;
  • otherwise a number follows the shorter chunk, so the comparison uses the longer chunk's next character against that number's first digit, rewritten as ASCII.

This is the order the class remarks promise: "a number compared with text orders exactly as the equivalent ASCII digits would". It also matches the existing mixed text/number branch in Compare. A text chunk never contains a digit, so the two characters always differ. The comparer still allocates nothing.

Tests

  • Compare_TextThatExtendsTheOtherSidesText_ComparesItsNextCharacterWithTheNumber covers the acceptance cases (file.txt/file1.txt, file-1/file1, file 2/file10), plus a! against ASCII and Arabic-Indic five, plus guards showing that filea still sorts after file1 and that file still comes before file.txt.
  • Sort_PutsABaseNameBeforeItsNumberedSiblings checks that report.pdf sorts before report1/2/10.pdf.
  • Compare_IsTransitiveOverMixedScriptDigitsAndText (NaturalStringComparer is intransitive for non-ASCII digits (٥ < 10 < z < ٥), so sort output depends on input order #55) now also includes prefix-shaped values (a!, a.b, a.5, a٥.b, a~, az, a 2, a-1) and stays antisymmetric and transitive.

The two new tests fail on main and pass with the fix. The full suite passes: 27/27.

🤖 Generated with Claude Code

https://claude.ai/code/session_011XTgJFveY9S4CJX3Bzeyej


Generated by Claude Code

When one text chunk was a strict prefix of the other, CompareTextChunks put
the shorter first without looking at what followed it. "file.txt" against
"file" + "1" + ".txt" never compared the '.' with the '1', so "report.pdf"
sorted after "report2.pdf". Compare the longer chunk's next character with
the first digit (as ASCII) of the number that follows the shorter one, which
is the order the class remarks promise.

Fixes #61

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011XTgJFveY9S4CJX3Bzeyej
@sonarqubecloud

Copy link
Copy Markdown

@matt-edmondson
matt-edmondson merged commit 4b6236b into main Oct 13, 2026
14 checks passed
@matt-edmondson
matt-edmondson deleted the fix/61-text-chunk-prefix branch October 13, 2026 08:16
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.

NaturalStringComparer sorts "file.txt" after "file1.txt" … "file999.txt": a text chunk that extends the other side's text chunk always loses

2 participants