Hans, great! I love the design (including the fact that one graphic
can be reused with multiple "terminals").

Just a few comments:

replace
      \immediate\write\scratchwrite{set terminal "\@@GNUPLOTmethod"}%
with
      \immediate\write\scratchwrite{set terminal \@@GNUPLOToutput}%
(No quotes and ps should be postscript.)

{\executesystemcommand{start gnuplot #1.gpd}}

Here both "guplot filename" and "start gnuplot filename" work equally
well (but even if "start" is left there, I would rename "pgnuplot"
into "gnuplot").
Something is terribly wrong with the windows machine I'm currently
working on, but on linux it worked OK (except for problems with text
in the metapost sample, but I have to figure out what went wrong
first).

When executing these lines on MikTeX:

 {\doifelse\operatingsystem{mswin}
     {\executesystemcommand{start gnuplot
\GNUPLOTfile.gpd}\message{[win]}}     {\executesystemcommand{gnuplot
\GNUPLOTfile.gpd}\message{[lin]}}}

I got [lin] a couple of times and no traces of any gnuplot work
(though gnuplot compiled the two remaining files ok when called
separately). But this has nothing to do with the module itself. Most
probably problem with permissions. write18 was enabled.

On 1/5/06, Hans Hagen wrote:
> Mojca Miklavec wrote:
>
> did \def\par{;} work out ok?

No, it didn't. Neither under linux nor under windows. So this remains
the only serious thing to fix.

The example you sent worked (almost) OK, but since it had only one
line in the \startGNUPLOTinclusions. As soon as I add
set terminal mp color
(which only overrides the already defined "set terminal mp" on the
proper place, so it's OK)

I get:

set terminal mp
^M set title trigonometry^Mset terminal mp color^M
set output "m-gnuplot-gnuplot-1-mp"
^Mplot sin(x)^M
quit

gnuplot didn't complain about ^M, but it can't have more than one line
compressed in one.

> >The problem is not in \def\par{} I guess. It doesn't have any
> >influence on the way how input lines appear in the file. Even if I
> >redefined the \par and put strange chars in there, it didn't have any
> >influence.
> >
> >
> strange, maybe i have a better tex binary

;)

It's 1.30.0 on linux (from your distribution) and 1.21a under MikTeX.

> ok, quit then
>
> >2. The default file extension is .plt (instead of gpd; the ending
> >really doesn't matter, but this one is recognized by default when you
> >"open file" from gnuplot)
> >
> hm, we don't want to overwrite files, do we?

Does the ending matter in (not)overwriting files?

I would only change
\immediate\openout\scratchwrite=\GNUPLOTfile.gpd
into
\immediate\openout\scratchwrite=\GNUPLOTfile.plt
(or even \scratchwrite=\GNUPLOTfile-\@@GNUPLOTsuffix.plt, so that the
files don't overwrite each other)

and
gnuplot \GNUPLOTfile.gpd
into
gnuplot \GNUPLOTfile.plt

but that's only cosmetics, doesn't really change the functionality.

> that's a big list ... why isn't there a context mode?

Perhaps because nobody (including me) knew that there's a module to
support gnuplot inside ConTeXt source :).

Well ... after I spent approximately 2 or 3 hours to figure out how to
compile it I started writing the code. It's true that it's tempting to
do just anything else except learning during the period of exams, but
it will nevertheless take me some time to finish, so please don't
expect anything that soon.

Besides that: PDF support has been written 5 years ago and it is still
not present in standard binaries. I have no idea how much time is
needed once the support is written so that:
- a new version appears
- it's included in distributions
- people/admins upgrade the software

> >PS: Does this module really mean that I have no more excuses for not
> >finishing my report(s) for physics in time? ;)
> >
> no, worse, you now can finish it faster
>
> see attached file (bottom of file); should be enough to get your reports
> done

So ... I have to get back to work then ;)

Thanks again,
    Mojca