Values in input lines *must* be space-delimited?

[krisalyssa]

gnuplot has support for changing the data separator (see set datafile separator, p. 160 of http://www.gnuplot.info/docs_6.0/Gnuplot_6.pdf), but as far as I can tell feedgnuplot doesn't.

Passing --set 'datafile separator comma' does no good, because as far as I can tell feedgnuplot parses the input lines before sending them to gnuplot.

I have data in CSV files that I'd like to plot, and it looks like my options currently are

• preprocess the data to convert separators from commas to whitespace
• learn how to use gnuplot directly instead of fronting it with feedgnuplot

At the very least, the documentation should state that values need to be space-delimited. Currently README.md uses the phrase "Input parsing is flexible", which I think is misleading with respect to the input data format.

[dkogan]

It's possible to add this support to feedgnuplot, but I'm not convinced that it's worth the effort. feedgnuplot is very powerful in conjuction with the vnlog tools (https://github.com/dkogan/vnlog), so to make this truly effective, this support would need to be added to the various vnlog tooling as well. It would be effortful to add this support to the whole set of tools.

Alternately, I would do what you already thought about:

• preprocess the data to convert separators from commas to whitespace

< file.csv | sed 's/,/ /g' | feedgnuplot ....

This is trivial. It doesn't handle escapes and quoting, obviously, but I will claim that's more effort than it's worth also.

To make something that mostly works is pretty easy probably. But if quite literally we're trying to replace the user having to type

sed 's/,/ /g'

with them typing

--separator ,

is that really worth doing?

I'm open to suggestions. Does your envisioned use case need escapes (i.e. do you have spaces or escaped commas in your data)?

At the very least, the documentation should state that values need to be space-delimited. Currently README.md uses the phrase "Input parsing is flexible", which I think is misleading with respect to the input data format.

I thought this was clear from the numerous examples in the docs, but I can certainly make it more explicit. Thanks for the suggestion.