Summary
Add an optional structural, syntax-aware diff mode (à la difftastic) that diffs parsed code structure rather than raw lines, so reformatting / whitespace-only / pure-move changes are suppressed and the reader sees the logical change.
Motivation
This is the feature that would make DiffViewer distinctive rather than merely complete. Every line-based competitor (Sublime Merge, WinMerge, Meld, the GitHub web view) shows reformatting noise; difftastic is the standout that doesn't, and there is active demand for this style of diff. It is strongly on-mission — "a better diff" is the whole product thesis.
Competitive context
From a competitive review across Beyond Compare, WinMerge, Meld, Sublime Merge, VS Code, GitHub/GitLab, git-delta, and difftastic. Triaged as a good-fit differentiator — high value, but heavier than the quick wins, so it should start as a spike, not a default.
Risks / open questions (why this is a spike first)
- Self-contained single-file exe constraint. difftastic uses Tree-sitter; integrating native Tree-sitter grammars into the LibGit2Sharp-style single-file WPF publish needs validation (native lib bundling, size budget — README already calls out the ~145 MB footprint).
- Per-language grammars. Structural diff is language-specific; we'd need a strategy for which languages ship and graceful fallback to the existing line diff for everything else.
- Default vs opt-in. Should be an optional mode (toggle), not a replacement for the line diff. The existing intra-line word diff and ignore-whitespace toggles already cover the lightweight cases.
- Alternative: shell out to a bundled
difftastic binary vs. a managed Tree-sitter binding — evaluate both in the spike.
Suggested first step
A throwaway spike: prove one language end-to-end (parse → structural diff → render in the existing diff pane), measure exe-size and startup impact, then decide on scope.
Out of scope (for the spike)
- Making it the default mode.
- Broad language coverage — pick one representative language to prove the pipeline.
Filed from a competitive-research session; spike + plan to follow before any production work.
Summary
Add an optional structural, syntax-aware diff mode (à la difftastic) that diffs parsed code structure rather than raw lines, so reformatting / whitespace-only / pure-move changes are suppressed and the reader sees the logical change.
Motivation
This is the feature that would make DiffViewer distinctive rather than merely complete. Every line-based competitor (Sublime Merge, WinMerge, Meld, the GitHub web view) shows reformatting noise; difftastic is the standout that doesn't, and there is active demand for this style of diff. It is strongly on-mission — "a better diff" is the whole product thesis.
Competitive context
From a competitive review across Beyond Compare, WinMerge, Meld, Sublime Merge, VS Code, GitHub/GitLab, git-delta, and difftastic. Triaged as a good-fit differentiator — high value, but heavier than the quick wins, so it should start as a spike, not a default.
Risks / open questions (why this is a spike first)
difftasticbinary vs. a managed Tree-sitter binding — evaluate both in the spike.Suggested first step
A throwaway spike: prove one language end-to-end (parse → structural diff → render in the existing diff pane), measure exe-size and startup impact, then decide on scope.
Out of scope (for the spike)
Filed from a competitive-research session; spike + plan to follow before any production work.