See also T5701 for bonus complexity.

I think this isn't really too bad. The major issue is that we can't use stylesheets in email because Gmail doesn't support them, so we need to emit markup with inline style attributes.

pygmentize (and other first-party highlighters) spits out tags and I think that's going to have to be our input, but the input should be correctly formed and the stakes for mis-parsing it are low (you can't normally XSS users in email).

All the pygmentize rules are single-class CSS rules (e.g., always .syntax .thing, never .syntax .context .thing) so we don't need to parse it in some proper stack-based way. In fact, we can probably use a regular expression.

We do need a runtime-accessible mapping from CSS classes to color rules, and making these maps swappable enables T5701. I'm probably going to vaguely prepare for that but not specifically try to tackle it yet, although maybe I'll try to swap to a single definition and generate syntax.css from it since I don't really want to have two copies of the color rules.

So we're probably looking at:

• write a parser for Pygmentize markup;
• extract all the color rules from syntax.css and write something that regenerates it from the authority;
• use the color map + Pygmentize parser to highlight code for email.

That seems to be doing something fairly reasonable in my client, yell if it looks funky somewhere else:

This doesn't extend to inline diffs yet, just code blocks inside existing rendered remarkup blocks.