[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jeremie Juste
Subject: Re: [PATCH] ob-R output file with graphics parameter
Date: Sat, 03 Jul 2021 19:08:14 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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

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";

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]