A conventional line diff is valuable because it is literal. It is also easy to overwhelm with formatter churn, wrapped expressions, and code reflow. For Diff Anything 1.5, I treated those as two different review questions instead of making one algorithm answer both.
One comparison, two views
Smart Diff aligns language-aware tokens and uses conservative language-family rules for whitespace, indentation, statement boundaries, strings, and comments. Line Diff remains available in the same toolbar for the exact patch. Both views operate on the same source pair and retain syntax highlighting, editing, and apply controls.
The difficult boundary was avoiding an inflated claim: this is not an AST diff and it does not claim compiler-level semantic equivalence. That constraint made it practical to support all 117 non-plain-text editor languages consistently, including 18 newly maintained definitions.
Test the packaged application, not only the engine
I built a release fixture matrix for code, text, structured data, spreadsheets, images, PDFs, archives, folders, merge, transforms, save, export, and recovery. Running it through the packaged macOS app caught a malformed-YAML footer issue and a one-way apply dirty-state bug before release.
The same release also tightens large-comparison performance, cancellation, virtualization, interaction feedback, accessibility, and recovery.
The full release write-up includes the language list, exact product boundaries, and a screenshot from the actual app:
Top comments (1)
Keeping both views avoids forcing one representation to serve incompatible review jobs. The explicit non-AST boundary is good product discipline too: it tells reviewers which conclusions the smart view supports and when they must return to the literal patch. Testing the packaged app catches exactly the integration failures an engine-only suite cannot see.