Re: babel results handling

[Achim Gratz <Stromeko@nexgo.de>]

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