emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Jeremie Juste <jeremiejuste@gmail.com>
To: Jack Kamm <jackkamm@gmail.com>
Cc: Colin Baxter <m43cap@yandex.com>,
	Org Mode <emacs-orgmode@gnu.org>, Timothy <tecosaur@gmail.com>
Subject: Re: [PATCH] ob-R output file with graphics parameter
Date: Sat, 03 Jul 2021 19:08:14 +0200	[thread overview]
Message-ID: <87y2anwcjl.fsf@gmail.com> (raw)
In-Reply-To: <87h7hcowmv.fsf@gmail.com> (Jack Kamm's message of "Fri, 02 Jul 2021 21:21:28 -0700")

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


  parent reply	other threads:[~2021-07-03 17:08 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-23 22:50 [PATCH] ob-R output file with graphics parameter Jeremie Juste
2021-06-24  9:21 ` Colin Baxter
2021-06-27 17:12   ` Jack Kamm
2021-06-28  9:56     ` Colin Baxter
2021-06-28 21:54     ` Jeremie Juste
2021-07-03  4:21       ` Jack Kamm
2021-07-03  4:52         ` Timothy
2021-07-03 13:01           ` Jack Kamm
2021-07-03 17:08         ` Jeremie Juste [this message]
2021-07-03 18:14         ` Berry, Charles via General discussions about Org-mode.
2021-07-03 20:48           ` Jack Kamm
2021-07-06 15:04             ` Jack Kamm
2021-07-06 17:58               ` Berry, Charles via General discussions about Org-mode.
2021-07-06 19:20                 ` Jack Kamm
2021-07-06 21:43                   ` Berry, Charles via General discussions about Org-mode.
2021-07-10 10:16                     ` Jeremie Juste
2021-07-10 21:00                     ` Jack Kamm
2021-07-11  3:23                       ` Berry, Charles via General discussions about Org-mode.
2021-09-26  8:48 ` Bastien
2021-09-26  9:13   ` Jeremie Juste
2021-09-26  9:29     ` Bastien

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y2anwcjl.fsf@gmail.com \
    --to=jeremiejuste@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=jackkamm@gmail.com \
    --cc=m43cap@yandex.com \
    --cc=tecosaur@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).