See T2495. Although we aren't quite ready to write tabstop rules, much of this groundwork can be put in place.

See T784. This should be updated with modern plans.

See PHI756. This requests a warning when interdiffing diffs with different base commits. A related warning is when the diffs have different repositories. I'd also like to add both events (repository change, base commit change) to the diff table itself so there's a visual warning before you start interdiffing. See also PHI757 and T10500.

See PHI757 and PHI879 and PHI1169. Leaving inline comments on the right hand side of files not touched by diff B in an interdiff between A and B raises an error.

See PHI985. When we link to an inline comment, we currently scroll the browser to just above the comment. It would be better to scroll slightly above the comment, especially if the comment spans multiple lines (so you don't need to scroll up to see the context) and probably to highlight the context block.

See D20462:

• When a blank line is surrounded above and below by lines with an indentation level change, we could reasonably show an indentation level change on the blank line to keep the left margin smooth.
• When a significant number of consecutive lines (say, 11+) are affected only by the same indentation level change, we could show the first few, fold the middle section, then show the last few.

Via email. Inline suggestions use the same highlighting scheme that normal code changes do, attempting to strike a balance between readability and obviousness-of-diffs. This can make typo corrections (which are likely a common type of inline suggestion) difficult to spot at a glance. Instead, the red/green colors here could reasonably be higher-contrast to make the adjustments more obvious -- general readability is almost certainly less important for suggested edits.

Move / Copy

See T7878. This appears to be a bug in "moved/copied code" detection.

See PHI379. This is another bug in "moved/copied code" detection.

See PHI985. It would be nice to link the "copy/move" markers to the original block of text. This is tricky in the general case, but maybe support in the common cases is reasonable.

---

Resolved

See T11142. This should probably just be wontfixed since I'm not sure there's a pathway forward.

See T6791. This should probably just be wontfixed since it's obsoleted by prose diffs and not actionable?

See PHI701. This behavior is not ideal:

A better behavior would be for line 71 should be fully bright on both sides: there is no meaningful intraline diff there.

See PHI723. Review Board handles indentation level changes like this:

This is basically superior to our approach, and I'd like to implement something very similar and remove differential.whitespace-matters.

Adjacently, changes like the one in PHI212 should be visually marked somehow and cause the change to unfold, even in "Ignore All" mode (if that mode even makes sense to retain). It's possible we can simply remove "Show All" and "Ignore All" if indentation level changes are shown in "Ignore Most".

If we do retain whitespace modes, they should likely move to "View Options" per-file (see some rationale in PHI723).

Optionally, default whitespace modes could become a changeset attribute (see T784).

See PHI504; this is T5032 (now T12822): use a bunch of JS magic to make both sides of the diff independently selectable/copyable.

See PHI878, which reports a related copy/select issue in inline comments in the unified diff view.

See PHI985. When a changeset in unified mode renders a yellow "copied/moved" gutter on the right, lines shaded with green get extra green on the left in place of the gutter. This can make it look like whitespace was added to the beginning of the file. Just blanking the gutter would probably look bizarre; perhaps the "copied/moved" gutter can be shifted left inside the "line number" column instead.