@epriestly I'd lost that connection, so reachability, it might appear.

@kfsone Are you aware of arc diff --only (briefly mentioned above -- "just generate a diff to look at in the web UI, without other slow/complicated steps")? How do you picture arc selfreview differing from arc diff --only?

@epriestley I think you under-estimate the potential and value of your own product.

This is now formally prioritized (see PHI14).

Thanks! We've deployed this and are soliciting select feedback. Will get back to you shortly.

This has landed for anyone who wants to provide feedback on the v0 version.

Alrighty, I'll take a look at it. 💯

Mock above rebased on master and apparently working:

Let me see if I can dig up my hack-branch above and hand you a skeleton for it.

Yeah, this is relatively simple if it's on a separate page, and can be built in 20 minutes if there's no sorting or "Hide Done".

To step back slightly, one problem we know users have, which is motivating at least some of this request, is "90 spelling corrections". T8909 has a specific example of that, and T8909#224085 alludes to a flavor of this ("90 style corrections") elsewhere. I don't think this is a problem that users "should" have, but I suspect it's responsible for between, like, 50% and 85% of this request (maybe I'm way off, but I'd bet dollars to donuts that it's more than 2%), since it's the case where managing inlines is most overwhelming. And human reviewers are somehow often unable to resist making 90 inlines about style/spelling corrections, even when everyone is worse off for it.

I do think this is something I would have used in the past when faced with ensuring I've addressed all feedback for multiple designers. So in some part, I feel I understand the core problem users are looking for. I don't think we can fix abuses like the 90 comments on spelling errors, so that's not something I feel I need to consider in this design. I just want to make sure I haven't missed anything as an author, or that as a reviewer, all my comments have been satisfactorily addressed. There could be something to explore in that second directive, but we haven't seen a lot of issues in that area, so I'm not really concerned if this is the best solution for that. Wanting a view of only inline comments and the ability to reply isn't something I want, as I feel Differential already does that.

I suspect that isn't what very many users want (I'd guess like ~10%, not ~98%?) -- or, at least, doesn't really solve whatever problems they're running into. For example, I think the "90 spelling corrections" diff in T8909 wouldn't benefit much from this (it doesn't help you go through 90 spelling corrections or 90 lint style fixes), and it's the opposite of the request in T5654, which sounds very similar to this to me. But maybe T5654 is really just "our users like GitHub, so make it look similar to GitHub so it's more familiar", I'm not really sure.

Alrighty, took at pass at this I think isn't too much work, and is probably 98% of what people want. Specifically tried to look at the following scenarios:

For me it would be a great enhancement if there would be a shortcut which temporarily toggles this option:
Settings → Personal Settings → APPLICATIONS → Diff Preferences → Show Older Inlines

If a linter could theoretically catch it (conventions, space, formatting, etc.), I think a linter should (in a perfect world) be catching it.

Do you bucket style guide violations with lint issues? While I obviously can't post internal reviews, I can give you a hand-waving indication that a non-zero percentage of comments are style-related things that aren't caught by linters.

Broadly, the technical stuff here is in fairly good shape now but I still don't truly understand what problem we're solving. From earlier, I dug this up:

I'm just going to merge this into T8250. I'm still unsure what's to become of this, but I think however that resolves will cover this.

oh dear, what did I get myself into.

derp this is done.

Yeah, that directly helps with this. I think I have a pretty good plan for the actual mail part that isn't too crazy complicated, but the cutover/migration bit will be much simpler/smoother if we get things swapped over -- at least, most of the way -- ahead of this.

Just to clarify, it is good to be moving all the apps to modular transactions? This task is my primary motivator to cleaning that up.

I have a rough cut of this one.

From above, I think there are really three use cases here:

One spanner in the works here is that not all applications with mail preferences are on Modular Transactions yet. I think these are missing:

How about this:

A SAAS install is hitting the "move + rename binary" case.