GNU bug report logs -
#72778
31.0.50; Calc: g f doesn't display gnuplot window after closing
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 72778 in the body.
You can then email your comments to 72778 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#72778
; Package
emacs
.
(Sat, 24 Aug 2024 05:51:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Michael Heerdegen <michael_heerdegen <at> web.de>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sat, 24 Aug 2024 05:51:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#72778
; Package
emacs
.
(Sat, 24 Aug 2024 06:27:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 72778 <at> debbugs.gnu.org (full text, mbox):
> 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 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#72778
; Package
emacs
.
(Sat, 24 Aug 2024 07:03:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 72778 <at> debbugs.gnu.org (full text, mbox):
[சனி ஆகஸ்ட் 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#72778
; Package
emacs
.
(Sat, 24 Aug 2024 07:33:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 72778 <at> debbugs.gnu.org (full text, mbox):
> Cc: 72778 <at> debbugs.gnu.org
> From: Visuwesh <visuweshm <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#72778
; Package
emacs
.
(Sun, 25 Aug 2024 05:52:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 72778 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#72778
; Package
emacs
.
(Mon, 26 Aug 2024 06:05:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 72778 <at> debbugs.gnu.org (full text, mbox):
[ஞாயிறு ஆகஸ்ட் 25, 2024] Michael Heerdegen wrote:
> Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#72778
; Package
emacs
.
(Mon, 26 Aug 2024 19:34:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 72778 <at> debbugs.gnu.org (full text, mbox):
"Michael Heerdegen via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <bug-gnu-emacs <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#72778
; Package
emacs
.
(Wed, 28 Aug 2024 09:03:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 72778 <at> debbugs.gnu.org (full text, mbox):
Pip Cet <pipcet <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#72778
; Package
emacs
.
(Wed, 28 Aug 2024 12:41:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 72778 <at> debbugs.gnu.org (full text, mbox):
> Cc: 72778 <at> 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 <at> gnu.org>
>
> Pip Cet <pipcet <at> 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.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Sat, 31 Aug 2024 10:02:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Michael Heerdegen <michael_heerdegen <at> web.de>
:
bug acknowledged by developer.
(Sat, 31 Aug 2024 10:02:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 72778-done <at> debbugs.gnu.org (full text, mbox):
> Cc: pipcet <at> protonmail.com, 72778 <at> debbugs.gnu.org
> Date: Wed, 28 Aug 2024 15:39:21 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > Cc: 72778 <at> 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 <at> gnu.org>
> >
> > Pip Cet <pipcet <at> 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.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 28 Sep 2024 11:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 320 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.