fix(diffviewer): wrap long lines through delta in side-by-side, mark clipped lines in unified (closes #99)

[Booyaka101]

Summary

Closes #99.

diffFile and diffDir invoke delta with --max-line-length=<width>, which is the truncation flag — not a wrap hint. Combined with delta's default --wrap-max-lines=2, any source line longer than roughly two viewport widths got silently dropped in side-by-side mode. In unified mode (where delta does not wrap at all) the long line then hit the post-processing truncation in the diffContentMsg handler, which used an empty tail ("") and clipped without any visible signal.

The reporter pointed at both spots in the original issue — both the delta args and the post-processing pass.

Fix

Two changes in pkg/ui/panes/diffviewer/diffviewer.go, plus horizontal scrolling added per review feedback:

1. diffFile and diffDir — replace --max-line-length=<width> with --max-line-length=0 (disable truncation) and add --wrap-max-lines=unlimited. Side-by-side mode now wraps long lines all the way through instead of stopping at the second wrap.

2. diffContentMsg handler — store the raw delta output, render the visible window on every change. The cache now holds raw text, so cache hits re-render through the same path.

3. Horizontal scrolling (added in response to fix(diffviewer): wrap long lines through delta in side-by-side, mark clipped lines in unified (closes #99) #133 (comment)):

   • Left / right arrow keys scroll the diff viewport horizontally at half-viewport step. h/l are taken by file-tree expand/collapse, so arrows are the only sensible binding.
   • xOffset resets to 0 whenever a new file or dir is loaded.
   • The … markers are conditional: right when lineWidth > xOffset + viewportWidth, left when xOffset > 0 && lineWidth > xOffset. A line shorter than the viewport never shows either marker.

Verification

Local repro with the canonical "very long line" diff at -w=80:

Mode	Pre-fix	Post-fix
Side-by-side	clipped at "what flags delta is invoked with" (≈2 wraps)	reaches "to see what happens here" (full content)
Unified	line silently cut at viewport width with no marker	line cut with … tail; right-arrow scrolls to reveal the rest, … appears on the left once scrolled

Verified delta args directly:

$ delta --paging=never -w=80 --max-line-length=0 --wrap-max-lines=unlimited --side-by-side < long.diff
…
│    │                                  │  2 │const Long = "this is a very long↵
│    │                                  │    │ line that should be wrapped or t↵
│    │                                  │    │runcated depending on what flags ↵
│    │                                  │    │delta is invoked with and we want↵
│    │                                  │    │ to see what happens here"
…

Existing pkg/ui/panes/diffviewer test suite passes:

ok  	github.com/dlvhdr/diffnav/pkg/ui/panes/diffviewer	0.366s

The pre-existing TestSearchResultsRenderWhenFileTreeIsHidden, TestBuildFullFileTree, and TestCollapseTree failures on main are unrelated lipgloss-styling drift and are not touched by this PR.

AI usage disclosure (per AI_POLICY.md)

Tool: Claude Code (Opus 4.7).
Extent: pattern analysis (delta flag semantics, charmbracelet ansi.Cut usage), code drafting for the offset / render-window logic, and commit-message wording. I reviewed every change manually, ran go build, go vet, go test ./pkg/ui/panes/diffviewer/..., and confirmed the long-line repro behaviour locally before pushing. Happy to walk through any line on request.

Credit to @fgrehm for the report and the precise line references in the issue.

[dlvhdr]

I would like to support horizontal scrolling. I think the ... is a nice addition to indicate you can scroll right but I would like to extend it in 2 ways:

1. Only show it on the right when the line's visible length is greater than the viewport's width
2. Do the same behavior for the left side

[Booyaka101]

Sounds good. Plan: add an xOffset to the diff viewport, bind left/right arrows at half-viewport step, and gate the … markers on actual content past each edge (right when lineWidth > xOffset + viewportWidth, left when xOffset > 0). Will note AI assistance in the PR description per AI_POLICY.

[dlvhdr]

@Booyaka101 charm.land/bubbles/v2/viewport already implements a ScrollRight and ScrollLeft methods so let's use those. I'm not sure if it supports showing overflow characters like you did with the ....

There's also a library I intended to check out github.com/robinovitch61/viewport.
It could be better to just use it but I haven't fully researched it.

[dlvhdr]

I think these should scroll just 1 column at a time, like how j and k work.

[Booyaka101]

Step is one column per keypress now, matching how j / k step one line. The diffviewer's ScrollLeft / ScrollRight delegate straight to m.vp.ScrollLeft(1) / m.vp.ScrollRight(1).

[Booyaka101]

Done in d1bb830. ScrollLeft / ScrollRight on the diffviewer are now thin wrappers around m.vp.ScrollLeft(1) / m.vp.ScrollRight(1) — the local xOffset field and the renderViewport pass are gone (they were duplicating what the viewport already manages).

The conditional … markers came off with that — bubbles' viewport handles horizontal scroll by shifting the visible window and doesn't expose a per-visible-line render hook, so keeping the markers would mean reimplementing the slice path you asked to drop. Happy to add them back in a follow-up via a View() wrapper, or to look at github.com/robinovitch61/viewport if you want to switch the underlying viewport implementation entirely. Let me know which way you'd prefer.