This is now in stable; presuming it works until evidence to the contrary emerges.

The "Cancel" button should mean "Delete" if...

Currently, the inline code partially conflates four separate content states:

When you "Quote" a comment, then cancel, the comment disappears from the UI.

When you are viewing a change under engine X, and comments made under engine Y are present, they are not handled specially.

A general concern with "batch processing" is that it's quite bad if one commit failing to import can stall the entire repository forever.

See also T13552, which modifies the above discussion. The "Update" steps now happen after the "Publish" step.

The bulk of this work is done and I think there's nothing unique and actionable left here. This is survived by T13642 and other issues.

Survived by T13534, etc.

When you are viewing a document with engine X, and comments originally made with engine Y are present, this should be indicated ("This comment was made while looking at this change as a Q document."). They should probably also be moved to the top/bottom of the file, at least by default, since "Jupyter line number 9 = raw source line number 9" is an exceptionally bad and confusing guess at how to map line numbers.

Some tag stuff ended up here; I moved it to T13645.

• Colors are now consistent.
• Icons no longer use only color to communicate information.
• Icons are (mostly) consistent with the Harbormaster icons that have similar meanings.
• See Config → Modules/Extensions → Constants: Differential.

The diff above no longer reproduces this, and I think an equivalent to D18302 landed in D21178. T13524 was almost certainly the same issue.

This is mooted because I've removed the "excuses" feature about a year ago -- on the balance, I think it generated more confusion and busywork than signal.

The modern differential.revision.search API returns the repository for the revision.

See also PHI1910.

I think the complexity of changing this probably isn't worth the benefit. The complexity is high because of how much client-side interaction there is around inlines, and even with more space for the inline, the example screenshot doesn't seem great for code review anyway since none of the code fits.

In D21435, inlines were clamped. Adjusting this code is necessary, but not sufficient, to correct this problem.

(Internally, see PHI2020.)

This is relatively ripe for implementation now that inline comments support suggested edits.

This is very old, fairly vague, and doesn't have any clear modern customer interest. I'm open to implementing it, but would like a more clear/modern customer request before pursuing it.