Some discussion of current context in T10448#186240.

Differential also currently does not substitute a diagnostic message when declining to inline a patch: it should. ("Patch is too big to inline because limit X is set to Y." or similar.)

An additional inconsistency is that the diffusion.byte-limit applies to attached patches, but the differential.byte-limit does not. There's some vague argument for this behavior (you "shouldn't" be reviewing patches which are so enormous that they can not be emailed) but consistent behavior is probably better.

The code is a little better factored now and it's possible that the patch to DifferentialInlineCommentMailView is a pretty small one (and it may work in both text and HTML modes, as a possible benefit, although I suspect your install's use of HTML mail is much lower than most).

@epriestley - makes sense; I've been approached by some folks about our setup because they wanted kernel devs to get an actual code review system, who apparently have a similar mindset to compiler developers, but that's probably a long shot anyway :)

@klimek Your install is the only install we're aware of that is interested in a rendering mode like that (feedback about the old rendering was generally negative; feedback about the new rendering has been generally positive). Unless we become aware of much wider interest in such a rendering mode, I don't plan to reintroduce it upstream.

Note that this feature (text mode unified diff) is crucial for our deployment (requirement for text-only mails to contain reasonable diff snippets).

I probably caused this now that I think about it

I think this didn't actually get handled in T10262, but should be doable now.

Did this ever actually work? it looks like we're still embedding links:

Thanks; that does help (and also disappoint).

@jonah214 If it helps, unlikely to happen in the next 6 months given current prioritization queue. We are actively looking to hire though to widen our engineering throughput.

Sorry, we never have any idea. See Planning for discussion.

Is there any sense of when this might be worked on? We end up getting "Error Processing Mail (No Receivers)" due to Phabricator being in the CC a few times a week, and it's really annoying.

çok güzel olmuş moruk ya halal olsun

I don't think we're really making any headway here. Here are some more actionable followups:

I don't want to continue expanding the existing "mail tags" system in Settings → Email Preferences. See some discussion in T11337.

We've just been inching our way through this bit-by-bit to address specific use cases and improvements. That approach seems to be working pretty well and we have no plans to turn the whole mail into some fancy graphic thing, so I don't anticipate doing a specific whole-mail HTML redesign. We'll continue making improvements to specific sections.