Re: [PATCH] ob-R output file with graphics parameter
Hi Jeremie, Jeremie Juste writes: > The patch is redundant in its present state. In it's present state, > ob-R is better without it. Thanks! I'm marking it as "canceled" then. -- Bastien
Re: [PATCH] ob-R output file with graphics parameter
Hello Bastien, On Sunday, 26 Sep 2021 at 10:48, Bastien wrote: > What is the status of this patch? Should it be more tested? If it is > ready, feel free to apply it in the main branch. The patch is redundant in its present state. In it's present state, ob-R is better without it. Thanks, Jeremie
Re: [PATCH] ob-R output file with graphics parameter
Hi Jeremie, Jeremie Juste writes: > With the following patch the link to graphics output is finally back on > with R source code. What is the status of this patch? Should it be more tested? If it is ready, feel free to apply it in the main branch. Thanks! -- Bastien
Re: [PATCH] ob-R output file with graphics parameter
Jack, I will be going offline for a week or so, so I will have to defer more discussion. I know that `silent' silences an unwanted file link. And there are a few other ways to do this. So, if it is determined to proceed, adding an implicit `file' will not prohibit uses in which it was not actually wanted. Best, Chuck > On Jul 10, 2021, at 2:00 PM, Jack Kamm wrote: > > Hi Chuck, > >> If you modify the ECM to change `:exports results' to `:exports >> none' and clean older fig[12].png's from the directory, the export >> fails. > > Thanks for this example. I had mistakenly thought that code blocks > with ":exports none" would be evaluated for side effects, but you are > right, these blocks are skipped altogether during export. > > Instead, I think this use case could be handled by the ":results silent" > header. Blocks with that header are evaluated during export, but the > result is not inserted into the org buffer or the exported document. It > seems like a more general way to evaluate code blocks for side effects > only. > > To test this out, you could replace the header arguments in your > example with: > > ":exports results :results graphics file silent :file fig1.png" > >> So if everyone else is determined to make this change I can live >> with it. > > I do hope someone submits an RFC, so we can discuss this more > concretely. I still think it would be nice if we could go back to just > ":results graphics" to insert a figure. Unfortunately, I'm not currently > able to propose the patch, as I'm still in limbo w.r.t. my employer > agreement.
Re: [PATCH] ob-R output file with graphics parameter
Hi Chuck, > If you modify the ECM to change `:exports results' to `:exports > none' and clean older fig[12].png's from the directory, the export > fails. Thanks for this example. I had mistakenly thought that code blocks with ":exports none" would be evaluated for side effects, but you are right, these blocks are skipped altogether during export. Instead, I think this use case could be handled by the ":results silent" header. Blocks with that header are evaluated during export, but the result is not inserted into the org buffer or the exported document. It seems like a more general way to evaluate code blocks for side effects only. To test this out, you could replace the header arguments in your example with: ":exports results :results graphics file silent :file fig1.png" > So if everyone else is determined to make this change I can live > with it. I do hope someone submits an RFC, so we can discuss this more concretely. I still think it would be nice if we could go back to just ":results graphics" to insert a figure. Unfortunately, I'm not currently able to propose the patch, as I'm still in limbo w.r.t. my employer agreement.
Re: [PATCH] ob-R output file with graphics parameter
Re: [PATCH] ob-R output file with graphics parameter
> On Jul 6, 2021, at 12:20 PM, Jack Kamm wrote:
>
> Hi Chuck,
>
>> Here is an ECM that when exported with `C-c C-e l o y y` (or 'yes RET' for
>> each `y' depending on your setup)
>
> I don't see the example on your last email, could you try re-attaching
> it?
>
> Thanks,
> Jack
Mea culpa.
#+begin_src org
,* subfig ECM
:PROPERTIES:
:EXPORT_FILE_NAME: subfigures.tex
:EXPORT_OPTIONS: toc:nil
:EXPORT_LATEX_HEADER: \usepackage{subfig}
:END:
,#+macro: subfig @@latex:
\subfloat[$1]{\includegraphics[width=0.49\linewidth]{$2}}@@
,#+name: sub1
,#+begin_src R :exports results :results graphics :file fig1.png
plot(0:1,0:1)
text(0.5,0.5,"Fig 1")
,#+end_src
,#+name: sub2
,#+begin_src R :exports results :results graphics :file fig2.png
plot(0:1,0:1)
text(0.5,0.5,"Fig 2")
,#+end_src
,#+begin_figure
@@latex: {\centering@@
{{{subfig(First,fig1)}}}
{{{subfig(Second,fig2)}}}
@@latex: }@@
,#+end_figure
#+end_src
Re: [PATCH] ob-R output file with graphics parameter
Hi Chuck, > Here is an ECM that when exported with `C-c C-e l o y y` (or 'yes RET' for > each `y' depending on your setup) I don't see the example on your last email, could you try re-attaching it? Thanks, Jack
Re: [PATCH] ob-R output file with graphics parameter
> On Jul 6, 2021, at 8:04 AM, Jack Kamm wrote: > > Hello again, > >>> A user might like to construct a figure consisting of various subfigures >>> such as in a subfloat environment. >>> >>> Will this be reasonably simple to accomplish if `:results graphics' (with >>> no `file' element) automatically inserts a link? >>> >>> Currently, omitting the file element leaves the link out, which I believe >>> is the most direct way to approach subfloats. >> >> Thanks for bringing up this use case, it hadn't occurred to me before. > > Thinking about this more, it occurred to me that the ":exports code" or > ":exports none" header should already handle this. > > When that header is set, the graphics result won't be added to the latex > document, and the user can construct the subfigure separately in latex. > > Then we wouldn't need to support the use-case of ob-R creating a graphic > but not producing a result from it...which still feels a little strange > to me, to be honest. > > Or am I missing something still? Well, if the src blocks export nothing, the graphics results are not produced and no files are created. Here is an ECM that when exported with `C-c C-e l o y y` (or 'yes RET' for each `y' depending on your setup) 1) Produces two graphics files: - fig1.png - fig2.png 2) Produces file `subfigures.pdf` with a page with one figure containing those subfigures rendered side-by-side. If you modify the ECM to change `:exports results' to `:exports none' and clean older fig[12].png's from the directory, the export fails. Of course, there are workarounds to having Type=file implied by Format=graphics. So if everyone else is determined to make this change I can live with it. Best, Chuck
Re: [PATCH] ob-R output file with graphics parameter
Hello again, >> A user might like to construct a figure consisting of various subfigures >> such as in a subfloat environment. >> >> Will this be reasonably simple to accomplish if `:results graphics' (with no >> `file' element) automatically inserts a link? >> >> Currently, omitting the file element leaves the link out, which I believe is >> the most direct way to approach subfloats. > > Thanks for bringing up this use case, it hadn't occurred to me before. Thinking about this more, it occurred to me that the ":exports code" or ":exports none" header should already handle this. When that header is set, the graphics result won't be added to the latex document, and the user can construct the subfigure separately in latex. Then we wouldn't need to support the use-case of ob-R creating a graphic but not producing a result from it...which still feels a little strange to me, to be honest. Or am I missing something still?
Re: [PATCH] ob-R output file with graphics parameter
Hi Chuck, > A user might like to construct a figure consisting of various subfigures such > as in a subfloat environment. > > Will this be reasonably simple to accomplish if `:results graphics' (with no > `file' element) automatically inserts a link? > > Currently, omitting the file element leaves the link out, which I believe is > the most direct way to approach subfloats. Thanks for bringing up this use case, it hadn't occurred to me before. I guess this use case is relatively new, since prior to Org 9.3 ":results graphics" would insert a link. But, I can see why this functionality would be useful, and if people have come to use it, we should try not to break back-compatibility, or at least provide an alternate mechanism to support it. I do think that inserting a link for graphics is probably the more common use case, and should be easier by default. But clearly, the situation is not quite as simple as I had originally thought. Best, Jack
Re: [PATCH] ob-R output file with graphics parameter
Sorry if I have misunderstood the proposals here, but ... A user might like to construct a figure consisting of various subfigures such as in a subfloat environment. Will this be reasonably simple to accomplish if `:results graphics' (with no `file' element) automatically inserts a link? Currently, omitting the file element leaves the link out, which I believe is the most direct way to approach subfloats. If you deem it important to have the default behavior of `:results graphics` generate a link, maybe you can assure that there is a mechanism to avoid inserting the link when that is what the user wants. Best, Chuck > On Jul 2, 2021, at 9:21 PM, Jack Kamm wrote: > > Hi Jeremie, > >>> The requirement for a second file parameter was added in Org 9.3 to >>> support the use case in this thread: >>> >>> https://urldefense.com/v3/__https://orgmode.org/list/3ac2f42a-8ff2-1464-fa36-451e2ef0e...@pressure.to/__;!!LLK065n_VXAQ!wrIx4O0aTDnjRc6QXnCty-Wf2_U0nrUvZzibHsZuLd3mjHpT9S5oQZbENlolMfVxcA$ >>> >>> >>> But this syntax is annoyingly verbose for ob-R users, and also broke >>> lots of ob-R examples prior to Org 9.3. >>> >>> A simple fix might be to have the "graphics" flag implicitly add the >>> "file" flag as well. But we would need to first check that this doesn't >>> break other use cases. >> >> I do agree with this solution. If the current specification works, we >> could make it easy for ob-R user by implicitly adding a file flag. But >> as far as I understand, the change will have to be made in ob-core.el. > > Hmm, I think you're right -- this would have to be done in ob-core.el. > > I think it would still make sense though, and would be beneficial beyond > ob-R. According to [1], the "graphics" and "link" arguments don't do > anything unless used with "file", so it would make sense for them to > automatically add the "file" argument. > > [1] > https://urldefense.com/v3/__https://orgmode.org/manual/Results-of-Evaluation.html*Results-of-Evaluation__;Iw!!LLK065n_VXAQ!wrIx4O0aTDnjRc6QXnCty-Wf2_U0nrUvZzibHsZuLd3mjHpT9S5oQZbENlqSa5Lb1Q$ >
Re: [PATCH] ob-R output file with graphics parameter
Hello Jack, Many thanks for the feed back On Friday, 2 Jul 2021 at 21:21, Jack Kamm wrote: > Hi Jeremie, > >>> The requirement for a second file parameter was added in Org 9.3 to >>> support the use case in this thread: >>> >>> https://orgmode.org/list/3ac2f42a-8ff2-1464-fa36-451e2ef0e...@pressure.to/ >>> >>> But this syntax is annoyingly verbose for ob-R users, and also broke >>> lots of ob-R examples prior to Org 9.3. >>> >>> A simple fix might be to have the "graphics" flag implicitly add the >>> "file" flag as well. But we would need to first check that this doesn't >>> break other use cases. >> >> I do agree with this solution. If the current specification works, we >> could make it easy for ob-R user by implicitly adding a file flag. But >> as far as I understand, the change will have to be made in ob-core.el. > > Hmm, I think you're right -- this would have to be done in ob-core.el. >From what I understand, the document has grown in complexity and it is a bit complicated to generate graphics. I unfortunately cannot measure fully the impact of the change other client of the :graphics, :file parameters. I see that the source of the difficulty is that ob-core is handling too much. I remember a time where we had only output, graphics, value, and raw, for the output, and the we file-ext came, this was still fine, the second file parameter might be telling that we are over heating ob-core.el and it will become difficult for it to satisfy all its clients at some point. A way out of this might be for ob-core to delegate more to the respective ob-*.el. It will be duplicated work in some cases but each maintainer would find it easier to add and remove stuffs without having to consider the effect of the change on other ob-*.el. Regarding ob-R.el most of the job was done there already, in fact with the second :file parameter, I believe that the file handling was removed from ob-R.el. So what can ob-core delegate more to it's clients? Regarding the documentation, it might be good that we have a small case for each ob-*.el. When a user is looking how to produce graph with python or R, asymptote or shell might not be very telling for them and the :graphics parameter has a src shell as an example. This might be a killer for the new user. #+begin_src shell :results file link :file "download.tar.gz" wget -c "http://example.com/download.tar.gz; #+end_src Please don't see my comments as criticism. I'm short of time and I share responsibility if anything. I'll try to improve this part. > > I think it would still make sense though, and would be beneficial beyond > ob-R. According to [1], the "graphics" and "link" arguments don't do > anything unless used with "file", so it would make sense for them to > automatically add the "file" argument. I do agree with you again. > > [1] > https://orgmode.org/manual/Results-of-Evaluation.html#Results-of-Evaluation > Best regards, -- Jeremie Juste
Re: [PATCH] ob-R output file with graphics parameter
Timothy writes: > Would it be strange if running the code block with just > > :output graphics > > Automatically added "link" if *only* graphics is set, and generated a > file name if no :file is set? It wouldn't be strange. ob-jupyter [1] auto-generates file names for images, and it's convenient. Currently, I believe that if you set global ":file-ext" and ":output-dir" arguments, and also set ":results graphics file" and name the source block, then org-mode will generate the file name based on the source block name, output-dir, and file-ext. I think this is similar to what you want, except for the requirement to name the source block. Perhaps we could generate the filename from a UUID or hash, similar to ob-jupyter, if the source block isn't named. I do think this is more involved, and somewhat orthogonal, to dropping the ":results file" requirement when ":results graphics" is present. So it should probably be done in a separate commit. [1] https://github.com/nnicandro/emacs-jupyter
Re: [PATCH] ob-R output file with graphics parameter
Jack Kamm writes: > I think it would still make sense though, and would be beneficial beyond > ob-R. According to [1], the "graphics" and "link" arguments don't do > anything unless used with "file", so it would make sense for them to > automatically add the "file" argument. Mmmm, I think it would be good if we could make it so it's generally less effort to create plots. Would it be strange if running the code block with just :output graphics Automatically added "link" if *only* graphics is set, and generated a file name if no :file is set? I think it would be nice if I could declare a "figures directory" (default to "/tmp" or "."?) for exactly this. -- Timothy
Re: [PATCH] ob-R output file with graphics parameter
Hi Jeremie, >> The requirement for a second file parameter was added in Org 9.3 to >> support the use case in this thread: >> >> https://orgmode.org/list/3ac2f42a-8ff2-1464-fa36-451e2ef0e...@pressure.to/ >> >> But this syntax is annoyingly verbose for ob-R users, and also broke >> lots of ob-R examples prior to Org 9.3. >> >> A simple fix might be to have the "graphics" flag implicitly add the >> "file" flag as well. But we would need to first check that this doesn't >> break other use cases. > > I do agree with this solution. If the current specification works, we > could make it easy for ob-R user by implicitly adding a file flag. But > as far as I understand, the change will have to be made in ob-core.el. Hmm, I think you're right -- this would have to be done in ob-core.el. I think it would still make sense though, and would be beneficial beyond ob-R. According to [1], the "graphics" and "link" arguments don't do anything unless used with "file", so it would make sense for them to automatically add the "file" argument. [1] https://orgmode.org/manual/Results-of-Evaluation.html#Results-of-Evaluation
Re: [PATCH] ob-R output file with graphics parameter
Hello, Sorry for the delayed reply. On Sunday, 27 Jun 2021 at 10:12, Jack Kamm wrote: @Colin, thanks for your feedback. I have to confess that I didn't know about the second file parameter at all until I provided the patch. I just discovered main branch works with the second :file specification, by chance just before your mail. I have been led into the wrong direction trying to get back the old specification for graphics link. #+BEGIN_SRC R :results output graphics :file test.pdf plot(1) #+end_src The documentation about this part is poor and I must have missed these dicussions on the mailing list. So all this time I lived without the graphics link. ;-|. Now that I am back on track, I will check how well the current version works particularly for remote connection. If it does the patch will be redundant. > However, I tested Jeremie's example on latest org master and it also > worked fine for me, also on remote sessions. @Jack thanks for your feedback. I'll improve my style. > > The requirement for a second file parameter was added in Org 9.3 to > support the use case in this thread: > > https://orgmode.org/list/3ac2f42a-8ff2-1464-fa36-451e2ef0e...@pressure.to/ > > But this syntax is annoyingly verbose for ob-R users, and also broke > lots of ob-R examples prior to Org 9.3. > > A simple fix might be to have the "graphics" flag implicitly add the > "file" flag as well. But we would need to first check that this doesn't > break other use cases. I do agree with this solution. If the current specification works, we could make it easy for ob-R user by implicitly adding a file flag. But as far as I understand, the change will have to be made in ob-core.el. > >> Subject: [PATCH 1/4] ob-R.el: Remove redundant argument to function > > I think it would be better to squash these changes into a single commit. > Thanks again for the feedback. Best regards, -- Jeremie Juste
Re: [PATCH] ob-R output file with graphics parameter
> Jack Kamm writes: > Hi all, >> I obviously missing something. The above works for me without the >> patch. Unfortunately, I can't trace back the thread in order to >> understand the context. > I think this is a followup from this mail: > https://orgmode.org/list/87zgxc42qg@gmail.com/ > wherein Jeremie states: >> The current patch have been tested for remote connections as well >> and AFAIK, nothing breaks. >> >> But I'm afraid that the graphical output is broken and has long >> been even before the path. The test for graphical output is >> compromised and does not do the right test. I will suggest new >> ones. > So I think it's to do with graphical outputs in remote R sessions. Thank you for explaining. Best wishes
Re: [PATCH] ob-R output file with graphics parameter
Hi all, > I obviously missing something. The above works for me without the > patch. Unfortunately, I can't trace back the thread in order to > understand the context. I think this is a followup from this mail: https://orgmode.org/list/87zgxc42qg@gmail.com/ wherein Jeremie states: > The current patch have been tested for remote connections as well and > AFAIK, nothing breaks. > > But I'm afraid that the graphical output is broken and has long been > even before the path. The test for graphical output is compromised and > does not do the right test. I will suggest new ones. So I think it's to do with graphical outputs in remote R sessions. However, I tested Jeremie's example on latest org master and it also worked fine for me, also on remote sessions. Jeremie, could you clarify the issue this fixes? > +(defun org-babel-output-link-path:R (params) > + "format org-link to file from PARAMS" > + > + (format "[[file:%s]]" (concat (cdr (assq :dir params)) > + "/" > +(cdr (assq :file params) Rather than concat, I think it is better to use expand-file-name, and also call file-name-as-directory on the directory component. Stylistically, I don't think there should be a blank line between the docstring and the code. The docstring should also start with a capital letter and end with a period. > +(setq out-file-path (concat > + (replace-regexp-in-string "/ssh:.*?:" "" (cdr > (assq :dir params))) > + "/" > + out-file)) Use org-babel-process-file-name instead of replace-regexp-in-string to get the local path of the file. > - Remove second the need for a second file parameter This would indeed be nice. The requirement for a second file parameter was added in Org 9.3 to support the use case in this thread: https://orgmode.org/list/3ac2f42a-8ff2-1464-fa36-451e2ef0e...@pressure.to/ But this syntax is annoyingly verbose for ob-R users, and also broke lots of ob-R examples prior to Org 9.3. A simple fix might be to have the "graphics" flag implicitly add the "file" flag as well. But we would need to first check that this doesn't break other use cases. > Subject: [PATCH 1/4] ob-R.el: Remove redundant argument to function I think it would be better to squash these changes into a single commit.
Re: [PATCH] ob-R output file with graphics parameter
Hi Jeremie, > Jeremie Juste writes: > Hello, > With the following patch the link to graphics output is finally > back on with R source code. Note that on top of the "graphics" > parameter the "file" parameter have to be used for the org-link to > work out of the box. I will try to remove the need for a second > "file" parameter in the future. > #+begin_src R :results output graphics file :file test2.pdf > :session *local* :cache no :dir "~/Documents/images" > plot(rnorm(100)) #+end_src > #+RESULTS: [[file:images/test2.pdf]] I obviously missing something. The above works for me without the patch. Unfortunately, I can't trace back the thread in order to understand the context. Best wishes,
[PATCH] ob-R output file with graphics parameter
Hello,
With the following patch the link to graphics output is finally back on
with R source code. Note that on top of the "graphics" parameter the
"file" parameter have to be used for the org-link to work out of the
box. I will try to remove the need for a second "file" parameter in the
future.
#+begin_src R :results output graphics file :file test2.pdf :session *local*
:cache no :dir "~/Documents/images"
plot(rnorm(100))
#+end_src
#+RESULTS:
[[file:images/test2.pdf]]
The link also works for R remote sessions. Comments are welcome. The
next steps
- Remove second the need for a second file parameter
- Add tests to avoid regression
- implement async in ob-R
>From e3d37da7b643990dc70ee42528051f1323fa5cae Mon Sep 17 00:00:00 2001
From: Jeremie Juste
Date: Wed, 23 Jun 2021 23:58:26 +0200
Subject: [PATCH 1/4] ob-R.el: Remove redundant argument to function
* lisp/ob-R.el (org-babel-R-construct-graphics-device-call): Modify
function to take only 'params' and not 'graphics-file'. The parameter
graphics-file can be extracted from params.
---
lisp/ob-R.el | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index 2d9073cee..8266dc4ae 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-R.el
@@ -170,8 +170,7 @@ This function is called by `org-babel-execute-src-block'."
(mapconcat 'identity
(if graphics-file
(append
- (list (org-babel-R-construct-graphics-device-call
- graphics-file params))
+ (list (org-babel-R-construct-graphics-device-call params))
inside
(list "},error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='', axes=FALSE); text(x=0, y=0, labels=e$message, col='red'); paste('ERROR', e$message, sep=' : ')}); dev.off()"))
inside)
@@ -311,13 +310,16 @@ Each member of this list is a list with three members:
3. the name of the argument to this function which specifies the
file to write to (typically \"file\" or \"filename\")")
-(defun org-babel-R-construct-graphics-device-call (out-file params)
+(defun org-babel-R-construct-graphics-device-call (params)
"Construct the call to the graphics device."
(let* ((allowed-args '(:width :height :bg :units :pointsize
:antialias :quality :compression :res
:type :family :title :fonts :version
:paper :encoding :pagecentre :colormodel
:useDingbats :horizontal))
+
+ (out-file (cdr (assq :file params)))
+
(device (file-name-extension out-file))
(device-info (or (assq (intern (concat ":" device))
org-babel-R-graphics-devices)
--
2.20.1
>From 589eab5d98a4156b46943c7201404300f0ae6ca0 Mon Sep 17 00:00:00 2001
From: Jeremie Juste
Date: Thu, 24 Jun 2021 00:04:59 +0200
Subject: [PATCH 2/4] ob-R.el: New function to construct org-link
* lisp/ob-R.el (org-babel-output-link-path:R): New function to
contruct org-link from 'params'.
---
lisp/ob-R.el | 7 +++
1 file changed, 7 insertions(+)
diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index 8266dc4ae..c325c9cfa 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-R.el
@@ -185,6 +185,13 @@ This function is called by `org-babel-execute-src-block'."
(org-babel-pick-name
(cdr (assq :rowname-names params)) rownames-p)
(if graphics-file nil result
+(defun org-babel-output-link-path:R (params)
+ "format org-link to file from PARAMS"
+
+ (format "[[file:%s]]" (concat (cdr (assq :dir params))
+ "/"
+(cdr (assq :file params)
+
(defun org-babel-prep-session:R (session params)
"Prepare SESSION according to the header arguments specified in PARAMS."
--
2.20.1
>From b55148df0da94312e1a3e5709263ed9b66355384 Mon Sep 17 00:00:00 2001
From: Jeremie Juste
Date: Thu, 24 Jun 2021 00:07:39 +0200
Subject: [PATCH 3/4] ob-R.el: Return link if graphics parameter is used
* lisp/ob-R.el (org-babel-execute:R): Return org-link instead of nil if graphics
parameter is used.
---
lisp/ob-R.el | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index c325c9cfa..9f32db97a 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-R.el
@@ -184,7 +184,9 @@ This function is called by `org-babel-execute-src-block'."
(or (equal "yes" rownames-p)
(org-babel-pick-name
(cdr (assq :rowname-names params)) rownames-p)
- (if graphics-file nil result
+ (if graphics-file (org-babel-output-link-path:R params)
+result
+
(defun org-babel-output-link-path:R (params)
"format org-link to file from PARAMS"
--
2.20.1
>From 12a06671415a55c726975d6e0297a20aefbbce62 Mon Sep 17 00:00:00 2001
From: Jeremie Juste
Date: Thu, 24 Jun 2021 00:11:10 +0200
Subject: [PATCH 4/4] ob-R.el: Handle graphics file path for remote R session
* lisp/ob-R.el (org-babel-R-construct-graphics-device-call): If R
session is remote, remove "/ssh:" part in file path before writing the
graph to file on remote host.
---
lisp/ob-R.el | 7 ++-
1 file changed,
