Re: Should heredocs be included in "save"?

[Philipp K. J. <ja...@ie...>]

[snip]

> It seems to me you're missing entirely the business of creating 
> gnuplot files by programmatic means (whether C programs, perl or 
> python scripts or whatever). In that context you can now output a 
> gnuplot file with the data inline, so that the data and commands 
> will not come "unstuck". The generating program will simply print 
> the data into a "heredoc" field, with no "load" required.

You are absolutely right - this application never
occurred to me.

The way I saw gnuplot heredocs is that they are
a session variables (which they are!), which hold
a complex data set.

The use case that you and Ethan describe is more
akin to Perl's __DATA__ blocks (as opposed to 
heredocs): a block in a command file that does 
not contain further commands, but static data, 
that can be accessed from the commands (but, I 
would add, not outside of this command file!).

(One could even imagine extending the existing
"index" feature to such data blocks, and in this
way allow for multiple data sets to reside in one
file.)

My point is not that I don't understand the 
INTENDED use case - my point is that heredocs,
as currently designed, are not restricted in
any way to that use case. Moreover (as my
reaction proves), they suggest very different
uses for themselves, and will invariably morph
in that direction.

> 
> I find it difficult to imagine much use for "heredoc" data blocks 
> composed interactively, other than perhaps in trivial cases: would 
> you really trust yourself to type large amounts of data in that way? 
> Surely you'd compose the script in your favorite editor, then run it 
> and revise it as needed.

I couldn't either - hence my question on gnuplot-info
the other day.