[kokokoXUY]

Description

Related to #4052 and #4033. When unchanged lines have identical text on both sides of a selected range, SequenceMatcher can align those lines at the wrong positions. Formatting lines 2–3 in a five-line example then formats line 5 as well. This anchors identical prefix and suffix lines before diffing the middle, so the second pass keeps the selected range at its original position. The existing regression fixture now expects only the selected lines to change. For disjoint ranges, when the first pass preserves line count and every unselected line is byte-for-byte unchanged, the original ranges can be reused without an ambiguous text diff.

The new regression also covers disjoint ranges selecting lines 1 and 3 of three identical unformatted lines; line 2 now stays untouched. The --line-ranges stability check remains disabled, and this is not a complete replacement for #4052's diff algorithm, so the existing documentation warning remains in place.

Tests: 45 focused tests passed; Black formatting and all pre-commit hooks for changed files passed. The initial full Windows tox -e py313 -- -n 0 run had 505 passes and three failures: two color-diff tests also fail on the unmodified base in this environment, and the third was the old fixture expectation updated in this PR. After that update, the non-Jupyter suite passed 507 selected tests with one skip; two baseline-failing color tests were excluded, and one color-control test excluded by the name filter passed separately. The optional Jupyter stage passed 75 tests. This change was prepared with Codex assistance; the diff and test results were checked before submission.

Checklist - did you ...

• Follow the stability policy? This changes line selection, not Black's formatting style.
• Add an entry in CHANGES.md? Added under Unreleased in commit 805d74c.
• Add / update tests?
• Add new / update outdated documentation?

Disclosure: this change was prepared with an AI coding assistant (DeepSeek) under my direction; I reviewed the diff and the commands above before pushing.

[cobaltt7]

Could you address/respond to my comment #4052 (comment) as well? I'm not sure I fully understand this function.

[github-actions]

diff-shades results comparing this PR (6286b15) to main (77c0cae):

--preview style: no changes

--stable style: no changes

---

What is this? | Workflow run | diff-shades documentation

[kokokoXUY]

Re #4052 (comment) - I measured the three examples end to end with the CLI on main (1ed66a8), on this branch rebased onto it, and on #5484, and replied in full on the issue: #4052 (comment)

Short version, since they turn out to be two defects in _calculate_lines_mappings:

• Issue example 1 (3-line signature, --line-ranges=1-3): not fixed here - on main and on this branch both unselected print calls get formatted as well. The region before the first matching block was recorded as an unchanged block, so the range was shifted by offset instead of expanded to the changed block, and the diff compared lines verbatim, so the re-indentation done by the first pass made every line look modified. Fix line-range mapping for a changed start of file #5484 addresses that: the mapping becomes [(1, 1)] and only the signature is joined.
• Issue example 2 (five identical print ( "format me" ) lines, --line-ranges=2-3): fixed by this PR - main also formats line 5, here only lines 2-3 change.
• Issue example 3 (def my_func, --line-ranges=2-2): the internal mapping changes with Fix line-range mapping for a changed start of file #5484 ([(2, 2)] -> [(1, 5)]) but the formatted output is byte-identical on main, this branch and Fix line-range mapping for a changed start of file #5484, so there is no user-visible difference to fix.

Two process notes: I rebased this branch onto the current main and force-pushed, so the PR should no longer report as dirty and the workflow runs need a re-run. And neither this PR nor #5484 re-enables the --safe stability check that #4034 disabled - they only keep the second pass inside the requested range.

[cobaltt7]

Thanks!