word-diff silently does nothing on long lines (maxLineLenForDiff = 500)

[denysshnurenko]

What happens

Pressing W on a paired -/+ block does nothing visible. The status bar shows ±, so the mode is on, but no words are highlighted — even though the pair is a plain edit where the + line keeps the entire - line and appends to it.

Why

app/ui/worddiff/worddiff.go:66 bails out before any tokenization:

if len(minusLine) > maxLineLenForDiff || len(plusLine) > maxLineLenForDiff {
	return nil, nil
}

with maxLineLenForDiff = 500 (worddiff.go:42). My pair is - 3602 bytes / + 5525 bytes, so it is dropped 7–11× over the cap and the similarity gate is never reached.

Why it bites

The file is a markdown document where one paragraph is one physical line — prose, docs, CLAUDE.md/AGENTS.md-style instruction files, wrapped-off config, generated JSON. That is exactly the content where word-diff earns its place: a 3.5 KB paragraph with ~20 words added reads as a fully rewritten block without it. revdiff already handles these files deliberately — --wrap and --wrap-indent exist for them.

In one 4965-line diff here, 604 removed lines are under the cap and 7 are over. Those 7 are the ones I actually needed help reading.

Two things that would help

Either one alone is useful:

1. Make the cap configurable — --word-diff-max-line / REVDIFF_WORD_DIFF_MAX_LINE, keeping 500 as the default — so someone reviewing prose can opt into the O(m·n) cost knowingly.
2. Signal that a pair was skipped for length. Today ± is on and nothing is highlighted, which is indistinguishable from "the feature is broken". I only found out which it was by reading the source.

Environment

revdiff v1.12.0-ad8c796-20260804T171719 (homebrew, umputun/apps/revdiff), macOS 15.6 (Darwin 24.6.0).

[umputun]

fixed in #328, on master now.

your diagnosis was right, and the cap was wrong in kind as well as in value. Byte length isn't what the LCS costs: 500 repeated letters tokenize to one token, 500 bytes of minified JSON to nearly 300. So the guard now budgets the DP table instead (maxDiffCells = 4_000_000, ~32MB and ~17ms per pair), and the byte cap stays only as a cheap pre-filter at 20000 bytes to keep minified lines out of the tokenizer. Your 3602/5525 pair is ~1.3M cells, well inside it.

didn't add the flag. The knob would be in bytes while the cost is quadratic in tokens, so there's no value you could pick sensibly, and with the ceiling where it is now the case for it mostly goes away. Same for the skipped-pair hint: it needs ComputeIntraRanges to report why it returned nil, which changes the interface, and there's much less left to signal.

if you hit a pair that still doesn't highlight, open a new one with the line sizes and I'll look at where the budget sits.