Overview

[mzuenni]

See #195

[RagnarGrootKoerkamp]

I'm wondering if we can/should combine the two tables into one:
existing: Running <submission> <time> <submission verdict> <slowest case>
new: <submission> <testcases verdicts>
could be merged to
<submission> <testcase verdicts> <time> <submission verdict> <slowest case>

Only when there are >>100 cases that would become problematic.

Basically your version is pretty similar to the old one but with a prettier progress bar.

I'm also not sure yet whether or not to show all not-yet-started submissions already from the start. I suppose the main benefit is that the table has a constant size and it prevents some jumping around.

I do have some flickering still. Would have to look in to this more but I suppose it all comes down to buffering and then flushing at the right times.

[RagnarGrootKoerkamp]

Screenshot for context

[RagnarGrootKoerkamp]

Maybe stderr buffer size can be increased more using something like https://stackoverflow.com/a/65035026/2716069.
That should reduce flickering for large tables. On my screen the flickering typically happens in the same position each time, which seems to suggest that even without line buffering the stderr is flushed regularly

[RagnarGrootKoerkamp]

Oh, we should either test or disable this for windows

[RagnarGrootKoerkamp]

I'm leaning towards enabling this by default. Now that it (seems to) work well I don't really see a reason not to. On terminals without overwriting you already needed --no-bar anyway so that doesn't change. Will have to test --no-bar, -v, and --table a bit more later

[mpsijm]

You can query terminal width

Yes, this is possible, same for the height

and wrap lines manually?

The lines are already wrapped manually, see my screenshot: they're cut off at multiples of 10. Besides, this doesn't really affect the usability, because the problem is mostly that there are too many lines, so that scrolling becomes impossible.

One addition would be to only display if a flag is given and then either print "sorry terminal too small for table" or print the table if it fits

I think that would be my preference 🙂 We could even add an extra flag that always forces the display of this table, even when the terminal is too small.

The calculation for whether the terminal is too small will probably somewhat arbitrary, though. My suggestion:

• First, detect the number of lines needed per submission in the table. For problems with few test cases, this will simply be 1, but for Lateral Damage, this will be 2, as seen in my screenshot.
• Calculate the total number of lines needed to fit all submissions on screen.
• If the total number of lines needed for the table is larger than half* the terminal height minus 5, do not show the table.

*) "half" is somewhat arbitrary, I chose this so that the "regular" output of bt run will still be visible. I guess something like ⅔ or ¾ could also work, because then at least it's visible that something is happening above the table.

[mpsijm]

I think the only thing still missing right now, is a mention in the documentation? Other than that, I think this is ready for merging 😄

[RagnarGrootKoerkamp]

I won't have time to review. Feel free to merge