Eric Schulte writes: > Would it be difficult to add another set of code blocks which > automatically compare the output of these automatically generated code > blocks, indicating when there are differences.
I'd lobby for integration into the test framework. >> I still think that the scalar pipe-delimited processing from shell and >> perl is wrong in that pipe-delimited data ends up w/ an extra column >> if each line starts w/ a pipe, but not if the pipe is used like a >> csv separator (between columns but not at the beginning or end of the >> line). >> > > If you want to use pipes to delimit data, then I'd suggest *not* > interpreting the data as a value, but rather doing something like > ":results verbatim drawer". Generally pipes aren't considered to be > table column delimiters, I'd try tabs or spaces instead. Yes they are (by accident mostly as a side effect of how the table gets imported), but only for Babel languages (except elisp) that can return tables as values. I only recently implemented the necessary processing for Perl. The returned string gets interpreted as a table if it is multiline and/or has pipe symbol in it. Normally the separator should be a TAB character, but pipes work just the same (the actual interpretation is done by org-table-convert-region, which also inserts the leading "| " that Rick is complaining about). If you want to have Org interpret the table the way Rick seems to want, then the string must be a valid Org table that should be cycled after insertion (type "org" or "wrap"). I think the only thing still missing is interpreting "^[ \t]*|-" as hline. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds