gnuplot vs. emacs' compile command

[Hans-Bernhard Broeker]

Hello to bug-emacs and the gnuplot developers,

as reportedly requested by RMS, here's some more background
information about the problem found by a gnuplot user, Dan Jacobson,
in interacting with emacs.

In the essence, M-x compile apparently has problems coping with the
way gnuplot generates X11 graphs that survive the termination of the
main program (gnuplot -persist).  I'm not quite sure that's even
something the user should have been trying to do, but let's set that
aside for the moment.

The simplest way found so far to reproduce the problem is to have a
shell script file:

--- gpaction ---
gnuplot -persist <<EOS
 plot x
EOS
---- end ---

This creates a minimalistic plot in an X11 output window.  Now,
gnuplot's X11 output is managed by a separate driver program,
gnuplot_x11, which gives us the opportunity of the "-persist" option.
If set, the gnuplot main process will terminate itself, but the child
process executing gnuplot_x11 will keep running and maintain the
window content.

Different ways of invoking this script yield rather different results:

sh gpaction                                 # does the plot and returns
emacs -eval '(compile "sh gpaction")'       # doesn't plot, but returns
emacs -eval '(shell-command "sh gpaction")' # plots, but then hangs

'emacs' was GNU emacs-20.4.1 --- but the problem seems to happen with
other versions, too.  The middle case, using "compile", is what
originally triggered this investigation.  "Returns" here means that
the compilation buffer reports the compile as "finished with exit[0]".

In the latter case, "hangs" means that emacs is unresponsive --- no
reaction to mouse klicks to the menu, nor to key presses into the
*scratch* buffer that opens.  You can't show the buffer menu or
anything.  It's apparently waiting for something to happen, which
doesn't.  Only after you terminate the gnuplot graph window (type 'q'
into it), or press Ctrl-G in emacs to forcibly break out of the wait
loop, it will continue.

During that pause, a look at the output from 'ps jx' shows that
gnuplot_x11 is an orphan --- i.e. it's the only surviving process in
its process group.  In "shell-command", emacs apparently doesn't kill
this orphan until you explicitly tell it to.  In "compile", it seems
to manage killing it quite fine --- so successfully in fact, that it
kills gnuplot_x11 before it ever gets a chance to display its window.

Now, part of this may be pilot error, but at least the completely
unresponsive emacs session in the case of shell-command is something
I'm worried about, too.  Whether it qualifies as a bug, I'm not fully
sure --- you decide.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.