Improve display of continuation lines with multiline errors

[blueyed]

Fixes #717.
Follow-up to #1762.

[coveralls]

Coverage decreased (-0.0009%) to 92.324% when pulling bf1313a on blueyed:improve-multiline-error-format into 34925a3 on pytest-dev:master.

[nicoddemus]

Hey @blueyed. thanks!

Looks good to me, perhaps though we should add a CHANGELOG entry for that as well.

[nicoddemus]

Just noticed that we have this in py._code.code.py:

class FormattedExcinfo(object):
    """ presenting information about failing Functions and Generators. """
    # for traceback entries
    flow_marker = ">"
    fail_marker = "E"

Could please change the code use those constants instead?

[blueyed]

Done. Not sure though if that is really good like that.
After all it should be some more generic method probably for this kind of messages?

[tomviner]

LGTM 👍

[nicoddemus]

Thanks @blueyed and @tomviner!

[blueyed]

FWIW: #1762 should have been made against the features branch probably. There are huge conflicts now, since it was split in 8c49561.

[blueyed]

@nicoddemus
In case you don't know about rerere already: https://git-scm.com/blog/2010/03/08/rerere.html (outdated, better check the man page probably).

[nicoddemus]

Thanks for the heads up @blueyed!

[tomviner]

@blueyed said:

FWIW: #1762 should have been made against the features branch probably.

That's probably by bad, I was advising new contributors at the Europython sprint 😬

Looking again at #717 (which #1762 attempts to fix) it's more of a "bring into line" (with other traceback output), than strictly a "bugfix". So I guess default to features branch for these kind of tickets?

[nicoddemus]

@tomviner not sure, that's such a small change in output, I think it is OK for it to go to master. Others may have other opinions though. 😁

[The-Compiler]

I'm still wondering what crazy output parsing people do (like for IDEs) though, and how much we break even with small output changes.

[tomviner]

@The-Compiler I'm sure they do all sorts. But if we have faith in the longevity of pytest, perhaps being more consistent now will help future crazy output parsers ;-)

[The-Compiler]

@tomviner Sure, but I think that's a good reason to have any changes to the output in features 😉

[tomviner]

@The-Compiler see what you mean. So really, for patches that alter the pytest interface, only changes that were obviously broken before should be aimed at master.