bug#72778: 31.0.50; Calc: g f doesn't display gnuplot window after closing

bug#72778: 31.0.50; Calc: g f doesn't display gnuplot window after closing

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hello,

I'm using a graphical version of Gnuplot in Debian Gnu/Linux.

In Calc, whenever I have displayed a graph view using g f, and then have
been closing the Gnuplot X window, the next g f or g p will always not
display the Gnuplot view.  Hitting the keys again displays it, however.

When I don't close the Gnuplot window, the graph view is updated as
expected.


I found nothing obvious in the Calc code.  In the scenario where the
window doesn't pop up, the Gnuplot process is alive.  I edebugged
`calc-gnuplot-command' and the relevant line

  (process-send-string calc-gnuplot-process cmd)

seems to be the correct call.  When edebugging, simply executing this
very same call makes the Gnuplot window appear!  For some reason,
Gnuplot only displays the window for the second process-send-string
call.  Could be a Gnuplot bug, I dunno.

And...when I redefine `calc-gnuplot-alive' to always fail, the problem
is fixed, in a very inelegant way of course.  So there is something
wrong when talking with Gnuplot, or with Gnuplot itself.

I'm on Debian, I tried several different graphical Gnuplot versions, but
it's the same for all of them.

I'm thankful for all insights.


Michael.

bug#72778: 31.0.50; Calc: g f doesn't display gnuplot window after closing

[Eli Zaretskii]

> Date: Sat, 24 Aug 2024 07:49:53 +0200
> From:  Michael Heerdegen via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> In Calc, whenever I have displayed a graph view using g f, and then have
> been closing the Gnuplot X window, the next g f or g p will always not
> display the Gnuplot view.  Hitting the keys again displays it, however.
> 
> When I don't close the Gnuplot window, the graph view is updated as
> expected.
> 
> 
> I found nothing obvious in the Calc code.  In the scenario where the
> window doesn't pop up, the Gnuplot process is alive.  I edebugged
> `calc-gnuplot-command' and the relevant line
> 
>   (process-send-string calc-gnuplot-process cmd)
> 
> seems to be the correct call.  When edebugging, simply executing this
> very same call makes the Gnuplot window appear!  For some reason,
> Gnuplot only displays the window for the second process-send-string
> call.  Could be a Gnuplot bug, I dunno.
> 
> And...when I redefine `calc-gnuplot-alive' to always fail, the problem
> is fixed, in a very inelegant way of course.  So there is something
> wrong when talking with Gnuplot, or with Gnuplot itself.
> 
> I'm on Debian, I tried several different graphical Gnuplot versions, but
> it's the same for all of them.
> 
> I'm thankful for all insights.

Buffering issue?  Is gnuplot run via a pipe or a PTY?

bug#72778: 31.0.50; Calc: g f doesn't display gnuplot window after closing

[Visuwesh]

[சனி ஆகஸ்ட் 24, 2024] Michael Heerdegen via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

> Hello,
>
> I'm using a graphical version of Gnuplot in Debian Gnu/Linux.
>
> In Calc, whenever I have displayed a graph view using g f, and then have
> been closing the Gnuplot X window, the next g f or g p will always not
> display the Gnuplot view.  Hitting the keys again displays it, however.
>
> When I don't close the Gnuplot window, the graph view is updated as
> expected.
>
>
> I found nothing obvious in the Calc code.  In the scenario where the
> window doesn't pop up, the Gnuplot process is alive.  I edebugged
> `calc-gnuplot-command' and the relevant line
>
>   (process-send-string calc-gnuplot-process cmd)
>
> seems to be the correct call.  When edebugging, simply executing this
> very same call makes the Gnuplot window appear!  For some reason,
> Gnuplot only displays the window for the second process-send-string
> call.  Could be a Gnuplot bug, I dunno.
>
> And...when I redefine `calc-gnuplot-alive' to always fail, the problem
> is fixed, in a very inelegant way of course.  So there is something
> wrong when talking with Gnuplot, or with Gnuplot itself.

I don't use Calc's interface to gnuplot but I will note that I face a
similar issue with gnuplot package's comint interface to gnuplot as
well.  I need to send the same command twice sometimes to make gnuplot
actually interpret the command.  This might be a related issue.

> I'm on Debian, I tried several different graphical Gnuplot versions, but
> it's the same for all of them.
>
> I'm thankful for all insights.
>
>
> Michael.

bug#72778: 31.0.50; Calc: g f doesn't display gnuplot window after closing

[Eli Zaretskii]

> Cc: 72778@debbugs.gnu.org
> From: Visuwesh <visuweshm@gmail.com>
> Date: Sat, 24 Aug 2024 12:30:09 +0530
> 
> I don't use Calc's interface to gnuplot but I will note that I face a
> similar issue with gnuplot package's comint interface to gnuplot as
> well.  I need to send the same command twice sometimes to make gnuplot
> actually interpret the command.  This might be a related issue.

IME, gnuplot is notorious in changing its non-interactive behavior
from time to time, which might break the assumptions that Calc makes.
Suggest to look in the gnuplot's change log to see if they made some
change in the recent years, maybe this will give some ideas.

bug#72778: 31.0.50; Calc: g f doesn't display gnuplot window after closing

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> IME, gnuplot is notorious in changing its non-interactive behavior
> from time to time, which might break the assumptions that Calc makes.
> Suggest to look in the gnuplot's change log to see if they made some
> change in the recent years, maybe this will give some ideas.

I'm too ignorant to know what to look for.

Some more data points, though:

 - In *Gnuplot Trail* I see that gnuplot receives the command and emits
   a new prompt even when the command is ignored.

 - Executing (calc-gnuplot-command "set term wxt") (be sure that it is
   not ignored!) fixes the problem for me.  I guess we don't want to do
   that.

 - I can't reproduce the issue with a terminal emulator even when
   changing the gnuplot terminal to x11 (this is what Emacs uses for its
   gnuplot process).

I don't know much about process communication, excuse me if this is all
irrelevant.


Michael.

bug#72778: 31.0.50; Calc: g f doesn't display gnuplot window after closing

[Visuwesh]

[ஞாயிறு ஆகஸ்ட் 25, 2024] Michael Heerdegen wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> IME, gnuplot is notorious in changing its non-interactive behavior
>> from time to time, which might break the assumptions that Calc makes.
>> Suggest to look in the gnuplot's change log to see if they made some
>> change in the recent years, maybe this will give some ideas.
>
> I'm too ignorant to know what to look for.
>
> Some more data points, though:
>
>  - In *Gnuplot Trail* I see that gnuplot receives the command and emits
>    a new prompt even when the command is ignored.
>
>  - Executing (calc-gnuplot-command "set term wxt") (be sure that it is
>    not ignored!) fixes the problem for me.  I guess we don't want to do
>    that.
>
>  - I can't reproduce the issue with a terminal emulator even when
>    changing the gnuplot terminal to x11 (this is what Emacs uses for its
>    gnuplot process).
>
> I don't know much about process communication, excuse me if this is all
> irrelevant.

I am ignorant about process communication but I was able to reliably
make gnuplot open the terminal window every time by sending an extra
newline before the plot command.  Try

    M-: (process-send-string (get-buffer-process (current-buffer)) "\nplot sin(x)\n") RET

in the *Gnuplot Trail* buffer.  If you kill the gnuplot terminal window,
and reeval the same sexp, it opens again.  A naïve fix employing this
method would be

diff --git a/lisp/calc/calc-graph.el b/lisp/calc/calc-graph.el
index fb817b1bc3d..7b1ebc9f603 100644
--- a/lisp/calc/calc-graph.el
+++ b/lisp/calc/calc-graph.el
@@ -1417,7 +1417,7 @@ calc-gnuplot-command
   "Send ARGS to Gnuplot.
 Returns nil if Gnuplot signaled an error."
   (calc-graph-init)
-  (let ((cmd (concat (mapconcat 'identity args " ") "\n")))
+  (let ((cmd (concat "\n" (mapconcat 'identity args " ") "\n")))
     (or (calc-graph-w32-p)
 	(accept-process-output))
     (with-current-buffer calc-gnuplot-buffer

But it would be better if someone can explain why we require this
newline before CMD too.

bug#72778: 31.0.50; Calc: g f doesn't display gnuplot window after closing

[Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors]

"Michael Heerdegen via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <bug-gnu-emacs@gnu.org> writes:
> In Calc, whenever I have displayed a graph view using g f, and then have
> been closing the Gnuplot X window, the next g f or g p will always not
> display the Gnuplot view.  Hitting the keys again displays it, however.

I've investigated this.  This is a gnuplot bug that shows up only under
these conditions:

- qtterm is in use
- the BSD (not GNU) readline library is used (this is true in Debian)
- a window is closed at the wrong time
- a specific call to select() is NOT interrupted by a signal (GDB,
  unfortunately, causes an interrupt at the wrong moment, turning this
  into a Heisenbug)
- gnuplot talks to Emacs using a pty (and, I think, TERM=dumb is also
  required)

I've submitted a patch to gnuplot to fix these issues, but a workaround
is required for, at least, existing gnuplot versions.  Sending an extra
newline character preceding each gnuplot command, as Visuwesh's patch
does, should be both safe and effective, even in the case of several
windows being closed prior to the command that would otherwise be
swallowed.

HTH
Pip

bug#72778: 31.0.50; Calc: g f doesn't display gnuplot window after closing

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Pip Cet <pipcet@protonmail.com> writes:

> [...]
> I've submitted a patch to gnuplot to fix these issues, but a workaround
> is required for, at least, existing gnuplot versions.  Sending an extra
> newline character preceding each gnuplot command, as Visuwesh's patch
> does, should be both safe and effective, even in the case of several
> windows being closed prior to the command that would otherwise be
> swallowed.

Ok - thank you both, Pip and Visuwesh for investigating.

Eli, should we install that patch (rather master I guess)?  It fixes the
problem for me.

Michael.

bug#72778: 31.0.50; Calc: g f doesn't display gnuplot window after closing

[Eli Zaretskii]

> Cc: 72778@debbugs.gnu.org
> Date: Wed, 28 Aug 2024 11:01:48 +0200
> From:  Michael Heerdegen via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Pip Cet <pipcet@protonmail.com> writes:
> 
> > [...]
> > I've submitted a patch to gnuplot to fix these issues, but a workaround
> > is required for, at least, existing gnuplot versions.  Sending an extra
> > newline character preceding each gnuplot command, as Visuwesh's patch
> > does, should be both safe and effective, even in the case of several
> > windows being closed prior to the command that would otherwise be
> > swallowed.
> 
> Ok - thank you both, Pip and Visuwesh for investigating.
> 
> Eli, should we install that patch (rather master I guess)?  It fixes the
> problem for me.

I think we should install on emacs-30, unless someone can thing of any
potential problem with it.

bug#72778: 31.0.50; Calc: g f doesn't display gnuplot window after closing

[Eli Zaretskii]

> Cc: pipcet@protonmail.com, 72778@debbugs.gnu.org
> Date: Wed, 28 Aug 2024 15:39:21 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Cc: 72778@debbugs.gnu.org
> > Date: Wed, 28 Aug 2024 11:01:48 +0200
> > From:  Michael Heerdegen via "Bug reports for GNU Emacs,
> >  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> > 
> > Pip Cet <pipcet@protonmail.com> writes:
> > 
> > > [...]
> > > I've submitted a patch to gnuplot to fix these issues, but a workaround
> > > is required for, at least, existing gnuplot versions.  Sending an extra
> > > newline character preceding each gnuplot command, as Visuwesh's patch
> > > does, should be both safe and effective, even in the case of several
> > > windows being closed prior to the command that would otherwise be
> > > swallowed.
> > 
> > Ok - thank you both, Pip and Visuwesh for investigating.
> > 
> > Eli, should we install that patch (rather master I guess)?  It fixes the
> > problem for me.
> 
> I think we should install on emacs-30, unless someone can thing of any
> potential problem with it.

No objections, so I've now installed the workaround on the emacs-30
branch, and I'm therefore closing this bug.