Minimal "live" output mode

[darrenburns]

Something like this would be a nice little addition to the set of available --test-output-styles:

That's an example of the default output from AVA, a JS testing framework. It's the default output mode in that framework, unless running on CI.

Rich provides functionality for this sort of thing using the Live class.

It'd need to still work with --progress-style bar. If --progress-style inline is supplied, I think displaying a % somewhere would be ideal.

[JoshKarpel]

It'd need to still work with --progress-style bar.

I played with this for an hour or so and this is the major sticking point. In fact, this might be really hard and require a total redesign of the output and progress system. Or it's late and I'm crazy and it's way easier than I think it is....

Right now, the progress bar for --progress-style bar gets set up outside the output_tests function. This is useful because a lot of work gets done to set it up that doesn't need to be exposed to any of the existing output styles. But Rich won't let you run two Progress at once - you have to make a Live, add both Progresses to it, then let the Live render them. So you can't make the Progress for the output style in the output style function, because it would need to control the renderable for the Live that has to live outside the output function, and then you're suddenly inverting control in both directions and everything gets incredibly confusing.

The core problem is that, unlike the hacky architecture I introduced in #205 , the output and progress styles need to coordinate with each other. I was desperately trying to make them not need to know about each other, but that was already a total flop because the bar progress style didn't work with any of the dots output styles. But of course, if they were all part of the same Live, we could just render the dots structure as part of the live instead of trying to print to the console!

I think that to move forward, the artificial distinction between "where" the progress and output styles are implemented needs to be broken down. I think the core of the new solution is that a TerminalResultsWriter (or whatever) needs two top-level rendering primitives: a rich.console that it can print to, and a renderable that will be handed to an internal Live (hooked up to the same console) that starts when the suite starts running.

I'm going to go exploring in this direction and see what I find....