# from Michael G Schwern # on Tuesday 31 March 2009 15:22: > want: foo bar > have: foo bar > display: | > want: foo\N{SPACE}bar > have: foo\N{KLINGON MOMENT OF SILENCE}bar > >But it's really more useful for more complicated formatting. > Something simple like making subtle whitespace differences visible > should be a feature of the TAP consumer.
My thoughts exactly. If the Test::* modules causing this itch are truly only doing formatting, structured diagnostics should be plenty of input for them. And this 'display:' key is actually a bit unsettling because now you've got preformatted (encoded) formatting coming from the test. But, I can see a case where not all is() are created equal -- so perhaps the producer would simply tag the result, allowing that to be dispatched to a formatter: want: foo bar have: foo*bar tag: utf-klingon Then you have some dispatcher on the harness (presumably a builtin or one plugin which itself has plugins) to read the 'tag:' and decide which code does the formatting -- TAP::Formatter::Dispatch or so. Aside: I'm assuming that the 'have: foo bar' in Schwern's example includes a unicode nbsp or something. --Eric -- The opinions expressed in this e-mail were randomly generated by the computer and do not necessarily reflect the views of its owner. --Management --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------