Improve pytest's Full diff by coloring it's output

[BenjaminSchubert]

What's the problem this feature will solve?

The Full diff that pytest shows in -vv mode is very red and hard to read. Missing, common and extra entries all have the same color!

For reference, this is what it looks like:

Describe the solution you'd like

This diff is the same kind of diff that people might already be familiar with, typically running git diff. Those are often colored already. There is a pygments lexer for parsing such diffs.

As such, I would propose to enhance the coloring of those diffs when pygments is install, which would give something like:

Which I believe is much easier to read and spot differences.

I'd be happy to implement the solution if you would be willing to accept such a change.

This might require passing the terminal writer into the tooling that provides the diff to check whether colors should be enabled however.

[The-Compiler]

I think this would be a good thing to have, I'm for more colors and less red in general. IMHO, we also should highlight all the Python data structures in that output as Python code.

[BenjaminSchubert]

@The-Compiler thanks for the prompt answer!

Would that be a somewhat accurate description of what you are thinking? (Except the 'glitch' around the starting { that's red)

If so, I can try to have a go at it. It might require a few refactors on how the pygments stuff works, but I think it's definitely doable, and can go beyond just dicts

[BenjaminSchubert]

Technically, we could go even further with

However, I think that might be too much and actually less readable?

[The-Compiler]

Honestly personally I'm in the "the more colors, the better" camp, but I know there are people with differing opinions.

I agree your last example might be a tad less readable than the previous one, but I feel like that's just because of some missing visual separation. Some additional blank lines before each "section" would help that, IMHO.

[RonnyPfannschmidt]

For error printing,the linked article doesn't strictly apply as it's not code one would write

[BenjaminSchubert]

#11530 is the first step around the diff, I will look at adding more colors in other places afterwards, since it would rely on the same constructs as are introduced by this PR, to avoid refactoring too many times.

[BenjaminSchubert]

With the addition of #11659 and #11661, I believe all the discussions raised in this issue and the linked pull requests have been addressed.

I have made all the changes I thought were important. Is there anything else concerning the readability of the error output we'd like to change too while we are at it? I'm happy to continue improving it if there are other areas of improvement.

[BenjaminSchubert]

@bluetech I believe all the various points raised here and on the linked PRs are now handled. Should we close this issue or is it worth keeping open a bit longer?

[bluetech]

I'll close, thanks again!