Repository navigation
fix(semdiff): keep an edit at the end of the file in one replace hunk - #9
Merged
Merged
Conversation
When the LCS walk exhausted one side mid-hunk (e.g. editing the last line of a template with no trailing newline), changes() closed the hunk early and emitted the remainder as a separate trailing hunk: a delete plus an insert, each with an empty side and point delta 1. Extend the hunk to the end of both sides when either runs out, since nothing left can match. Fixes #5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What was wrong
In
changes(), the inner hunk loop stops when either side runs out. When that happened mid-hunk (editing the last line of a template with no trailing newline, or replacing the last N lines with M lines), the hunk was closed at that point, and the rest of the other side became a separate trailing hunk. One replace came out as adeleteplus aninsert, each with an empty side, so both had point delta 1.Before, with the real
Analyzeon a 3-line prompt whose last line changed from "Always answer in English." to "Always answer in French.":After:
The fix
After the inner loop, if either side is exhausted, extend the hunk to the end of both sides (
i, j = n, m). Nothing left can match, so the remainder belongs to the same contiguous hunk. The existing trailing check still covers hunks that start after the last matched line.Note: a single replace at the very end of a file can still be classified
structural. The down window hits the file edge at radius 2 with delta equal to the point delta, so the classifier counts it as persisting to the boundary. That is existing classifier behavior for edge-of-file edits and is not changed here. This PR only fixes the hunk split.Tests
New
TestEditAtEndIsOneReplacecovers editing the last line, the only line, last line -> two lines, and last two lines -> one line.Before the fix (all 4 fail):
After:
Fixes #5
🤖 Generated with Claude Code