Re: [PATCH] ob-R output file with graphics parameter

2021-09-26 Thread Bastien
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

2021-09-26 Thread Jeremie Juste
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

2021-09-26 Thread Bastien
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

2021-07-10 Thread Berry, Charles
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

2021-07-10 Thread Jack Kamm
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

2021-07-10 Thread Jeremie Juste


Re: [PATCH] ob-R output file with graphics parameter

2021-07-06 Thread Berry, Charles



> 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

2021-07-06 Thread Jack Kamm
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

2021-07-06 Thread Berry, Charles



> 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

2021-07-06 Thread Jack Kamm
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

2021-07-03 Thread Jack Kamm
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

2021-07-03 Thread Berry, Charles
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

2021-07-03 Thread Jeremie Juste
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

2021-07-03 Thread Jack Kamm
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

2021-07-02 Thread Timothy


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

2021-07-02 Thread Jack Kamm
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

2021-06-28 Thread Jeremie Juste
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

2021-06-28 Thread Colin Baxter
> 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

2021-06-27 Thread Jack Kamm
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

2021-06-24 Thread Colin Baxter
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

2021-06-23 Thread Jeremie Juste

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,