Re: using gnuplot's "splot" and "every" commands on org-mode table data

[Paul Stansell <paulstansell@gmail.com>]

Hi Eric,

> Currently the :missing header argument for gnuplot code blocks does two
> things.  It adds the "set datafile missing..." line to the code block
> body *and* it binds `*org-babel-gnuplot-missing*' to the value of the
> :missing header argument when the datafile is written, so empty table
> cells are replaced with the value of the :missing header argument.

Thanks for the explanation.

> The reason you're not getting a blank line is because it is replaced
> with three "missing" values, in this case "? ? ?".
>
> Do you think this behavior should be changed or split between two header
> arguments?

I think the :missing header should not replace empty fields in an org
table by the missing character as blank lines have a special meaning
in gnuplot.  To fully use the versatility of gnuplot one needs blank
lines and missing values.  The "set datafile missing" command sets a
specific character string to be treated as a missing value.  The
character string can even be a number, eg. set datafile missing "-1".

It says under gnuplot's "help missing" that: "There is no default
character for `missing`, but in many cases any non-parsible string of
characters found where a numerical value is expected will be treated
as missing data."

My view is that for the purposes of exporting org tables for plotting
with gnuplot all blank entries in the org table (fields and whole
lines) should be exported as blanks, and all characters (letters or
numerical digits etc.) should be exported exactly as they appear in
the table (without any additional surrounding quotes being added).

Maybe I'm missing the point of the :missing header, but I find it
easier and clearer to include the datafile missing command in the
gnuplot code block.  I don't really see a need for the :missing
header.  Maybe the need stems from wanting to be able to use different
plotting packages to plot the same org table data, but it's not clear
to me.

Kind regards,

Paul