Jakob Schöttl

> I see what you mean, currently we don't model shared inputs in the type. If you want, that can be postponed for a future PR. Yup, I think that's...

I re-implemented the `--actual` options based on the `--print` already merged PR. This feature requires `--print` option and prints an error if used without `--print`. I'm open to changes about...

The concept of this addition to `--print` is this: Either non-matching-result matching-result where result can be stdin/stdout/exit status. From that and depending on the `--actual[=spec]`, the `Matcher` is computed so...

I will rebase when PR for #26 is merged.

The comments at begin of file are still not parsed. Thats because `formatXtestgroup` does `skipMany whitespaceorcommentline` before it parses `many $ try (formatXtest i)`. I don't quite understand this part...

@simonmichael thanks for the quick response. I'm looking into it right now. > I don't know if the input format is currently stored anywhere. I suspect the first thing to...

Current CLI proposal: ``` Print test file: --print[=FORMAT] Print test files in specified format (default: v3). --actual[=MODE] Combined with --print, print test files with actual results (stdout, stderr, exit status)....

> This is sounding good. I'd be inclined to call --actual --print-with or something, to indicate that it's a modifier for --print and not usable by itself. OK, what do...

> Do we want to support printing v1 and v2 ? Already implemented, I think. Especially v1 is easy to generate because it does not support shared input. > Any...

Another reason to support v1/v2: If it comes to generating/updating results, we should not force the user to migrate to v3, if they want to use their current format for...