Can't send buffer to gnuplot under Windows

[rhstanton]

I just installed gnuplot 4.6 in Windows Vista, and then installed gnuplot-mode. Unfortunately, when I try to send the buffer to gnuplot, only the first line of the buffer seems to get sent (looking at the gnuplot window). I'm using pgnuplot.exe as my executable, but I've also tried gnuplot.exe and this doesn't help.

Note: If I use the latest version of gnuplot-mode.el by Mike McCourt, with the same gnuplot setup, it sends the whole buffer to gnuplot just fine, so the gnuplot setup does work (in theory).

Thanks.

[joddie]

Which version of gnuplot-mode are you using, and how did you install it (e.g., from MELPA or elsewhere?) Does the same problem happen if you send lines (e.g. by C-c C-v) or regions to gnuplot?

[rhstanton]

From: joddie notifications@github.com<mailto:notifications@github.com> Reply-To: bruceravel/gnuplot-mode reply@reply.github.com<mailto:reply@reply.github.com> Date: Tuesday, December 18, 2012 3:28 PM To: bruceravel/gnuplot-mode gnuplot-mode@noreply.github.com<mailto:gnuplot-mode@noreply.github.com> Cc: Richard Stanton stanton@haas.berkeley.edu<mailto:stanton@haas.berkeley.edu> Subject: Re: [gnuplot-mode] Can't send buffer to gnuplot under Windows (#15)

Which version of gnuplot-mode are you using, and how did you install it (e.g., from MELPA or elsewhere?) Does the same problem happen if you send lines (e.g. by C-c C-v) or regions to gnuplot?

— Reply to this email directly or view it on GitHubhttps://github.com/bruceravel/gnuplot-mode/issues/15#issuecomment-11510582.

I've installed gnuplot 20121127.1316 using package-list-packages and selecting gnuplot. When I open a gnuplot script file, it announces itself as

Gnuplot-mode 0.6.1 (gnuplot 3.7)

Send region has the same problem – only the first line appears in the gnuplot window, and Emacs hangs until I press C-g

Send line using C-v works in part – the line does appear after the prompt in the gnu plot window, but again Emacs then hangs with a spinning circle cursor until I press C-g.

It looks like the problem might have something to do with not getting proper confirmation that the first line was sent properly.

[joddie]

Hmm. I don't have access to a Windows machine right now to debug this, unfortunately. As far as I know gnuplot.el doesn't do anything special to check whether a line has been received.

What do you get as a backtrace if you do toggle-debug-on-quit, try to send something and then hit C-g?

[rhstanton]

Hmm. I don't have access to a Windows machine right now to debug this, unfortunately. As far as I know gnuplot.el doesn't do anything special to check whether a line has been received. What do you get as a backtrace if you do toggle-debug-on-quit, try to send something and then hit C-g?

Here's what I get when I try to send a few lines using C-c C-r:

Debugger entered--Lisp error: (quit) accept-process-output(#) comint-send-input() gnuplot-send-string-to-gnuplot("set xlabel \"Stock price\"\nset ylabel \"Payoff\"\nset key off\n" region) gnuplot-send-region-to-gnuplot(115 172) call-interactively(gnuplot-send-region-to-gnuplot nil nil)

[rhstanton]

From: Richard Stanton Sent: Tuesday, December 18, 2012 3:40 PM To: bruceravel/gnuplot-mode Subject: Re: [gnuplot-mode] Can't send buffer to gnuplot under Windows (#15)

I've installed gnuplot 20121127.1316 using package-list-packages and selecting gnuplot. When I open a gnuplot script file, it announces itself as  

Gnuplot-mode 0.6.1 (gnuplot 3.7)

---

That's odd all by itself. The version of gnuplot actually installed is 4.6. On my Mac, the gnuplot version is reported correctly.

[joddie]

That is interesting. Gnuplot-mode tries to call gnuplot when first loaded to find the version information, and defaults to guessing version 3.7 if it can't do this.

If you don't mind a bit more debugging, could you try inserting the following in a scratch buffer and evaluating it? It should pop up a buffer with Gnuplot's splash message.

(with-current-buffer (get-buffer-create "*gnuplot test*")
  (erase-buffer)
  (insert "show version")
  (call-process-region (point-min) (point-max) gnuplot-program t (current-buffer))
  (pop-to-buffer (current-buffer)))

There must be something funny going on with the way Emacs communicates with gnuplot, but I don't know what it could be. Maybe I should look at the other gnuplot mode and see how they do it...

[rhstanton]

I get a blank buffer when I try what you suggest… I agree it’s something to do with the way Emacs talks to gnuplot, but I don‘t know what. I’ve tried both the pgnuplot.exe and gnuplot.exe executables that come with the Windows version of gnuplot 4.6, and neither works.

From: joddie [mailto:notifications@github.com] Sent: Tuesday, December 18, 2012 4:38 PM To: bruceravel/gnuplot-mode Cc: Richard Stanton Subject: Re: [gnuplot-mode] Can't send buffer to gnuplot under Windows (#15)

That is interesting. Gnuplot-mode tries to call gnuplot when first loaded to find the version information, and defaults to guessing version 3.7 if it can't do this.

If you don't mind a bit more debugging, could you try inserting the following in a scratch buffer and evaluating it? It should pop up a buffer with Gnuplot's splash message.

(with-current-buffer (get-buffer-create "gnuplot test")

(erase-buffer)

(insert "show version")

(call-process-region (point-min) (point-max) gnuplot-program t (current-buffer))

(pop-to-buffer (current-buffer)))

There must be something funny going on with the way Emacs communicates with gnuplot, but I don't know what it could be. Maybe I should look at the other gnuplot mode and see how they do it...

— Reply to this email directly or view it on GitHubhttps://github.com/bruceravel/gnuplot-mode/issues/15#issuecomment-11512530.

[joddie]

Thanks for the bug report and for trying the suggestion. For now I'm not sure what the problem is, sorry. I'll try to debug a bit more when I have access to a Windows machine again (not until the new year, unfortunately).

[joddie]

I had a glance at Mike McCourt's gnuplot-mode, and I see that it doesn't run gnuplot as an interactive process, but starts a new process from scratch each time you send it a file as input. So that probably explains why it doesn't suffer from this problem.

If you don't mind running one more test, what happens when you evaluate the following in a scratch buffer? It should give you an Emacs window with an interactive gnuplot inside it. If that doesn't work, then I'm really not sure how to fix this.

(pop-to-buffer
 (make-comint-in-buffer
  "gnuplot"
  (get-buffer-create "*gnuplot shell*")
  gnuplot-program))

One more question. What is the difference between gnuplot.exe and pgnuplot.exe in current Windows distributions? I gather from the discussion at http://gnuplot.10905.n7.nabble.com/names-of-gnuplot-Win32-binaries-td11759.html that there are some differences in how they deal with the console, so this problem probably relates to that in some way.

[rhstanton]

No rush – I can always use my Mac. I’m very happy to help in any way with debugging/testing.

From: joddie [mailto:notifications@github.com] Sent: Thursday, December 20, 2012 10:28 AM To: bruceravel/gnuplot-mode Cc: Richard Stanton Subject: Re: [gnuplot-mode] Can't send buffer to gnuplot under Windows (#15)

Thanks for the bug report and for trying the suggestion. For now I'm not sure what the problem is, sorry. I'll try to debug a bit more when I have access to a Windows machine again (not until the new year, unfortunately).

— Reply to this email directly or view it on GitHubhttps://github.com/bruceravel/gnuplot-mode/issues/15#issuecomment-11584809.

[rhstanton]

If you don't mind running one more test, what happens when you evaluate the following in a scratch buffer? It should give you an Emacs window with an interactive gnuplot inside it. If that doesn't work, then I'm really not sure how to fix this. (pop-to-buffer (make-comint-in-buffer "gnuplot" (get-buffer-create "gnuplot shell") gnuplot-program))

---

I tried this three times. The first two, the gnuplot shell buffer displayed the message

Timeout: gnuplot is not ready

Process gnuplot exited abnormally with code 1

The third time, the buffer displayed nothing at all. In each case, however, a (separate, GUI, non-Emacs) gnuplot window opened outside Emacs.

After the third time, I tried typing in the gnuplot shell window. When I entered a line and typed return, the command was successfully executed by (and appeared in) one of the (non-Emacs) gnuplot windows, but besides my own typing, no text ever appeared in the gnuplot shell buffer.

Is the code by any chance waiting for some sort of prompt to appear in the buffer?

---

One more question. What is the difference between gnuplot.exe and pgnuplot.exe in current Windows distributions? I gather from the discussion at http://gnuplot.10905.n7.nabble.com/names-of-gnuplot-Win32-binaries-td11759.html that there are some differences in how they deal with the console, so this problem probably relates to that in some way.

---

I'm not sure about this either. The experiment above was using pgnuplot.exe Using gnuplot.exe instead, although a gnuplot.exe process is visible in the task manager, nothing appears in the Emacs buffer (again), unlike pgnuplot, no separate Windows window appears, and again unlike pgnuplot, nothing at first (seemed to) happen when I typed "plot sin(x)". However, then I tried

set term windows plot sin(x)

and this time it worked.

So it appears that both pgnuplot.exe and gnuplot.exe could, in principle, be made to work, as long as you don't mind none of the output ever appearing in the Emacs buffer.

[dbc60]

This is an interesting topic. I ran into the same problem. I hope you can look at it soon.

Regards, Doug Cuthbertson

[Harry79]

I have the same issue. I tried what you suggested: (pop-to-buffer (make-comint-in-buffer "gnuplot" (get-buffer-create "gnuplot shell") gnuplot-program))

The gnuplot shell opens and I can type in commands: e.g. plot sin(x). As soon as I hit enter emacs hangs and I can only recover by C-g.

[Harry79]

Btw. this is the call stack I get:

Debugger entered--Lisp error: (quit) accept-process-output(# process gnuplot) comint-send-input() call-interactively(comint-send-input nil nil)

the # (smaller sign) process gnuplot (bigger sign) seems to me a bit strange, should this be a pid?

[Harry79]

I solved the problem, at least partially. By setting: '(gnuplot-program "pgnuplot") see http://lists.gnu.org/archive/html/help-emacs-windows/2010-09/msg00003.html A window opens and displays the plot result, however the accept-process-output call still blocks and I need to press C-g to continue working with emacs.

[joddie]

That backtrace looks normal. Emacs subprocesses are identified with an arbitrary name and their printed representation looks like #<process NAME>. The backtrace is just telling you that you quit while Emacs was waiting for input from the pgnuplot process.

Unfortunately, I suspect this is due to how gnuplot on windows handles its input and output, not with Emacs or gnuplot-mode (the code snippet above relies only on the generic comint subprocess-in-a-buffer library, not on gnuplot-mode). I don't know the details but I vaguely remember reading that Windows gnuplot exists as two different executables, gnuplot and pgnuplot, for this reason. I think plain gnuplot pops up its own terminal-like window, while pgnuplot uses standard input -- but I guess it doesn't emulate enough of the interactive prompt session to make running as a shell program under Emacs viable. I would guess that it doesn't also pipe stdout, so comint-mode never sees the prompt it expects -- that would cause the hang observed. I don't know Windows well at all, but do you get a prompt and other output if you run gnuplot or pgnuplot from a command prompt?

I vaguely remember some talk on the gnuplot mailing list about changing this behaviour so that Win32 gnuplot behaves more like its unix-y version, but I don't know if anything came of that. Alternatively, there is a simpler alternative gnuplot-mode to this one (linked elsewhere on github and also on MELPA) which doesn't rely on running gnuplot as a subprocess, so you could try that. Sorry, that's all I've got!

[joddie]

The discussion here might be slightly relevant: http://gnuplot.10905.n7.nabble.com/pgnuplot-exe-flow-control-td11194.html

Are there still three different executables, wgnuplot, wgnuplot_pipes, and gnuplot or is that out of date? If you start a normal inferior shell under Emacs, is there one of these executables which you can start from the *shell* buffer and type commands to from within it?

[Harry79]

With gnuplot started from cmd: I get a gnuplot shell in the same command window, it is a "console application". However, Emacs does not work with gnuplot but works with pgnuplot. The wgnuplot and pgnuplot are "windows applications", they return immediately and open a GUI.

I managed to get rid of the blocking: in gnuplot-send-string-to-gnuplot (gnuplot.el) I changed (comint-send-input) to (comint-send-input nil 1).

The next thing I want to try is to get gnuplot work together with org-mode's html-output.

[joddie]

Huh, I stand corrected. Thank you for investigating further. It's still not clear to me what happens if you start gnuplot or pgnuplot from a command shell within Emacs (does M-x shell start a Windows command interpreter?)

The discussion at http://www.gnu.org/software/emacs/windows/Sub_002dprocesses.html#Sub_002dprocesses might also be useful.

A patch would be great if you get it working reliably!

[Harry79]

In the mean time I managed to run org-plot/gnuplot on a table and see the plot in a gnuplot window. I also managed to generate proper html output by following this description: http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-gnuplot.html

I just tried to run gnuplot and pgnuplot in an Emacs shell, both hang in: (comint-send-input nil nil).

Seems like different gnuplot executable would be required which sends something back to comint-send-input. This way an interactive gnuplot shell within Emacs would work. However, for my purpose the workaround described above is just enough.

[johanborg]

Hi, I realize this thread is over a year old, but as I am still fighting this problem...

Harry79, did you get org-plot/gnuplot working with pgnuplot.exe? I made the same changes you mentioned above

;; set gnuplot-program variable
(setq gnuplot-program "C:/Program Files (x86)/gnuplot/bin/pgnuplot.exe")

;; active Babel languages
(org-babel-do-load-languages
    'org-babel-load-languages
     '((gnuplot . t)))

;;Modify gnuplot.el
(comint-send-input) to (comint-send-input nil 1)

And got so far as running org-plot/gnuplot on a buffer with a org-plot table, which will open a new GnuPlot window, but will not show any plot, only

Terminal type set to 'wxt'
gnuplot> reset
gnuplot> 

Did you make any additional changes to get it working? Any hints would be much appreciated.

Best regards, Johan

[Harry79]

I have it working together with org-mode, have not tried to use another method of invoking it.

;;I have gnuplot in my PATH so I do not use the full path:
(custom-set-variables
...
 '(gnuplot-process-name "pgnuplot")
 '(gnuplot-program "pgnuplot")
 '(org-confirm-babel-evaluate (quote my-org-confirm-babel-evaluate))
...
)

;;Here is gnuplot mode:
(add-to-list 'load-path "H:/share/emacs-gnuplotmode/")
(setq exec-path (append exec-path '("C:/Program Files (x86)/gnuplot/bin/pgnuplot.exe")))
(autoload 'gnuplot-mode "gnuplot" "gnuplot major mode" t)
(setq auto-mode-alist
      (append '(("\\.gp$" . gnuplot-mode))
              auto-mode-alist))
(setq calc-gnuplot-name "C:/Program Files (x86)/gnuplot/bin/pgnuplot.exe")

;;org-mode stuff:
(defun my-org-confirm-babel-evaluate (lang body)
  (and (not (string= lang "dot"))
       (not (string= lang "org"))
       (not (string= lang "R"))
       (not (string= lang "gnuplot"))
       (not (string= lang "ditaa"))
       (not (string= lang "plantuml"))))  ; don't ask for ditaa

(org-babel-do-load-languages
 'org-babel-load-languages
 '(;; other Babel languages
   (dot . t)
   (plantuml . t)
   (R . t)
   (org . t)
   (gnuplot . t)
   (ditaa . t)))

Howto use it with org-mode: store this to gnuplot.org

** Org-plot
#+PLOT: title:"example table" ind:1 type:2d with:lines
#+tblname: data-plot
| independent var | first dependent var | second dependent var |
|-----------------+---------------------+----------------------|
|             0.1 |               0.425 |                0.375 |
|             0.2 |              0.3125 |               0.3375 |
|             0.3 |          0.24999993 |           0.28333338 |
|             0.4 |               0.275 |              0.28125 |
|             0.5 |                0.26 |                 0.27 |
|             0.6 |          0.25833338 |           0.24999993 |
|             0.7 |          0.24642845 |           0.23928553 |
|             0.8 |             0.23125 |               0.2375 |
|             0.9 |          0.23333323 |            0.2333332 |
|               1 |              0.2225 |                 0.22 |
|             1.1 |          0.20909075 |           0.22272708 |
|             1.2 |          0.19999998 |           0.21458333 |
|             1.3 |          0.19615368 |           0.21730748 |
|             1.4 |          0.18571433 |           0.21071435 |
|             1.5 |          0.19000008 |            0.2150001 |
|             1.6 |           0.1828125 |            0.2046875 |
|             1.7 |          0.18088253 |            0.1985296 |
|             1.8 |          0.17916675 |           0.18888898 |
|             1.9 |          0.19342103 |           0.21315783 |
|               2 |                0.19 |              0.21625 |
|             2.1 |          0.18214268 |           0.20714265 |
|             2.2 |          0.17727275 |            0.2022727 |
|             2.3 |           0.1739131 |            0.1989131 |
|             2.4 |          0.16770833 |            0.1916667 |
|             2.5 |               0.164 |                0.188 |
|             2.6 |          0.15769238 |           0.18076923 |
|             2.7 |           0.1592591 |            0.1888887 |
|             2.8 |           0.1598214 |           0.18928565 |
|             2.9 |          0.15603453 |            0.1844828 |

#+begin_src gnuplot :var data=data-plot :exports both :file data-plot.svg
reset
set title "example table"
set xlabel "X"
set ylabel "Y"

plot data u 1:2 w l lw 1 title 'first dependent var', \
     data u 1:3 w l lw 1 title 'second dependent var'
#+end_src

Move your cursor to the src block and press C-c C-c.

Hope this helps.

[johanborg]

Thanks Harry!

Now it seems to send the data to GnuPlot at least:

Terminal type set to 'wxt'
gnuplot> data = "c:/Users/johan/AppData/Local/Temp/babel-60962rl/gnuplot-6096NtJ"

But it doesn't seem to send the script to GnuPlot. Running the script manually in GnuPlot worked fine and it showed the demo graph.

Could it be me using the MELPA version of gnuplot-mode, you seem to load it manually?

[joddie]

As noted upthread, I think this has to do with how Gnuplot handles its interactive terminal input and output under windows. The simplest test is to evaluate the following, for some value of gnuplot-program:

(pop-to-buffer
 (make-comint-in-buffer
  "gnuplot"
  (get-buffer-create "*gnuplot shell*")
  gnuplot-program))

That should create a bare-bones Comint buffer in Emacs, containing a running Gnuplot shell which will accept commands. If that works, it should be possible to get the rest of the mode working.

The other gnuplot package in MELPA (which is simpler than this one) does not try to run Gnuplot as an interactive shell under Emacs, and it seems to work better on Windows for this reason.

[Harry79]

@johanborg, you almost have it. I removed my change to gnuplot.el and have exactly the same behavior you reported.

In (defun gnuplot-send-string-to-gnuplot (string text)... replace (comint-send-input) by (comint-send-input nil 1)

By the way I am using gnuplot-mode, version 0.7.

[johanborg]

Thanks a lot, now it works!

I actually already made the change in gnuplot.el, but forgot i had it compiled, which took precedent. Recompiling fixed everything. :)

Edit: Also fixed org-plot/gnuplut for other org tables.

[osktyn]

Following the instructions supplied I have also managed to get this to work (my problem was much like johanborg's). I'd like to thank all of you for your persistance in supplying a solution! This has bugged me for years and been a time-sink equally long.

[Arjay-El]

Gnuplot V5 no longer includes pgnuplot.exe. I am now back to C-g to end the attempted plot session with no output. Tried a straightforward sub with wgnuplot but that just opened the console and I could not have a plot returned to my org doc. Is there a workaround for this with the disappearance of pgnuplot?

[bruceravel]

I don't normally do my gnuplotting on windows, but ... Does the gnuplot.exe executable not work?

[Arjay-El]

Gnuplot 5.x works fine standalone on Windows 10-64b, its a great program. I am just try to create plots inline in Emacs 25.1. I have enabled it with org-babel and am following the method listed above. I tried using gnuplot as is to replace pgnuplot. That provides a message saying the plot is complete but Emacs does not respond until you C-g out and no plot is created. I substituted wgnuplot in place of pgnuplot and it opens a console window. I can run the script in that window but it does not return the plot to Emacs. I have to work in windows so linux is not an option. I posted the message to see if anyone had an updated advice/workarounds. Thanks for your reply, appreciated. (PS: I am not a programmer, just an end user using Emacs for research papers which is why I'd love to have gnuplot work inline on Emacs/Windows.).

[zzg20082009]

Emacs run gnuplot.exe as a sub process, But in that sub process CACHES the input and output, So the input or output weren't reach at the final destination. I don't think that can be solved. :( https://www.gnu.org/software/emacs/manual/html_node/efaq-w32/Subprocess-hang.html

[no-identd]

@zzg20082009:

I don't think that can be solved

Why not?

[theldoria]

Is there any progress in work?

Btw, installing gnuplot-mode from MELPA (as suggested by @joddie) and changing (comint-send-input) to (comint-send-input nil 1) (as suggested by @Harry79) solved my org-mode export issues.

[conao3]

Windows is not supported for now. please ref #33