[PATCH] ob-R output file with graphics parameter

[PATCH] ob-R output file with graphics parameter

[Jeremie Juste]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]


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



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: ob-R-graphs.patch --]
[-- Type: text/x-diff, Size: 5447 bytes --]

From e3d37da7b643990dc70ee42528051f1323fa5cae Mon Sep 17 00:00:00 2001
From: Jeremie Juste <jeremiejuste@gmail.com>
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 <jeremiejuste@gmail.com>
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 <jeremiejuste@gmail.com>
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 <jeremiejuste@gmail.com>
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, 6 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index 9f32db97a..2769804a4 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-R.el
@@ -336,6 +336,11 @@ Each member of this list is a list with three members:
         (extra-args (cdr (assq :R-dev-args params))) filearg args)
     (setq device (nth 1 device-info))
     (setq filearg (nth 2 device-info))
+    (setq out-file-path  (concat
+                          (replace-regexp-in-string "/ssh:.*?:" "" (cdr (assq :dir params)))
+                                 "/"
+                                      out-file))
+
     (setq args (mapconcat
 		(lambda (pair)
 		  (if (member (car pair) allowed-args)
@@ -344,7 +349,7 @@ Each member of this list is a list with three members:
 			      (cdr pair)) ""))
 		params ""))
     (format "%s(%s=\"%s\"%s%s%s); tryCatch({"
-	    device filearg out-file args
+	    device filearg out-file-path args
 	    (if extra-args "," "") (or extra-args ""))))
 
 (defconst org-babel-R-eoe-indicator "'org_babel_R_eoe'")
-- 
2.20.1


[-- Attachment #3: Type: text/plain, Size: 34 bytes --]



Best regards,
-- 
Jeremie Juste

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

[Colin Baxter]

Hi Jeremie,
>>>>> Jeremie Juste <jeremiejuste@gmail.com> 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,

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

[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.fsf@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-451e2ef0eacd@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

[Colin Baxter]

>>>>> Jack Kamm <jackkamm@gmail.com> 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.fsf@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

[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-451e2ef0eacd@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]

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-451e2ef0eacd@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

[Timothy]

Jack Kamm <jackkamm@gmail.com> 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

[Jack Kamm]

Timothy <tecosaur@gmail.com> 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

[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-451e2ef0eacd@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

[Berry, Charles via General discussions about Org-mode.]

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 <jackkamm@gmail.com> 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-451e2ef0eacd@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

[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

[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

[Berry, Charles via General discussions about Org-mode.]

> On Jul 6, 2021, at 8:04 AM, Jack Kamm <jackkamm@gmail.com> 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

[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

[Berry, Charles via General discussions about Org-mode.]

> On Jul 6, 2021, at 12:20 PM, Jack Kamm <jackkamm@gmail.com> 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

[Jeremie Juste]

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

[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

[Berry, Charles via General discussions about Org-mode.]

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 <jackkamm@gmail.com> 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

[Bastien]

Hi Jeremie,

Jeremie Juste <jeremiejuste@gmail.com> 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

[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

[Bastien]

Hi Jeremie,

Jeremie Juste <jeremiejuste@gmail.com> 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