From: Jack Kamm <jackkamm@gmail.com>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: Liu Hui <liuhui1610@gmail.com>, emacs-orgmode@gnu.org
Subject: Re: [PATCH] ob-python: support header argument `:results file graphics'
Date: Tue, 11 Jul 2023 22:10:45 -0700 [thread overview]
Message-ID: <87fs5tk94a.fsf@gmail.com> (raw)
In-Reply-To: <87sf9x8n38.fsf@localhost>
Ihor Radchenko <yantar92@posteo.net> writes:
> ":results file" imply that results of the code block are written to a file
> (the file is specified using header args).
>
> ":results file link" imply that results of the code block are interpreted
> as file link. The fact that presence of :file header arg overrides this
> behaviour is something we may want to reconsider - it is confusing.
I think this is a lot clearer and more intuitive than the current
behavior, and worth doing.
But it is a breaking change, so it would be good to provide a variable
to re-enable the previous behavior, for back-compatibility of older
Org documents.
In particular, the Worg matplotlib example of ":results file" without
":file" header arg is fairly old, and I have a few Org docs using
":results file" this way as well. So I would appreciate a
backwards-compatibility variable if we change this.
> ":results graphics file" imply that graphics generated during code
> block execution is saved to file specified in the :file header args.
> This feature is only available for some backends that can derive
> graphics data from the source block. When :file is not specified,
> using the actual code block output is confusing, and we may want to
> reconsider this behaviour.
I agree.
On a related note, I think we should revert most of b088389c6 on
bugfix branch. That documentation causes more harm than good, and is
based on some confusion in [1] ("graphics" and "link" are _not_
equivalent in general).
> Sorry, but I do not fully understand.
> Generated graphics is not what Org sees as "results of evaluation".
> I think it is well illustrated by
>
> #+begin_src R :file img.png
> hist(rnorm(100))
> "img.png is going to contain this string."
> #+end_src
>
> #+begin_src R :file img.png :results graphics
> hist(rnorm(100))
> "But now img.png is going to contain graphics."
> #+end_src
>
> The latter has nothing to do with block output, which is a string.
IMO block _value_ is string, while block _output_ is string AND
graphics.
So by my interpretation, ob-R is slightly incorrect in how it handles
":results output graphics" vs ":results value graphics". IMO the more
technically correct approach is in the ob-python patch that I proposed
a couple years ago [2], and plan to revisit soon. In that patch,
ob-python ":results graphics output" will plot from pyplot.gcf(),
while ":results graphics value" will expect a matplotlib.Figure object
to be returned for plotting.
(Note I do _not_ suggest changing ob-R -- even if my interpretation is
correct, I think that common usage and backwards-compatibility
outweighs strict technical correctness in this case).
[1] https://list.orgmode.org/87fu41zcn2.fsf@nicolasgoaziou.fr/
[2] https://list.orgmode.org/87eenpfe77.fsf@gmail.com/
next prev parent reply other threads:[~2023-07-12 5:16 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-03 4:31 [PATCH] ob-python: support header argument `:results file graphics' Liu Hui
2023-07-03 9:28 ` Ihor Radchenko
2023-07-03 10:40 ` Liu Hui
2023-07-03 11:41 ` Ihor Radchenko
2023-07-03 13:23 ` Liu Hui
2023-07-04 11:29 ` Ihor Radchenko
2023-07-05 5:23 ` Jack Kamm
2023-07-05 11:05 ` Ihor Radchenko
2023-07-06 2:49 ` Jack Kamm
2023-07-07 10:53 ` Ihor Radchenko
2023-07-08 13:55 ` Jack Kamm
2023-07-09 9:12 ` Ihor Radchenko
2023-07-12 5:10 ` Jack Kamm [this message]
2023-07-12 8:38 ` Ihor Radchenko
2023-07-14 2:47 ` Jack Kamm
2023-07-05 8:09 ` Liu Hui
2023-07-05 4:55 ` Jack Kamm
2023-07-07 10:56 ` Ihor Radchenko
2023-07-05 5:13 ` Jack Kamm
2023-07-05 8:11 ` Liu Hui
2023-07-06 3:49 ` Jack Kamm
2023-07-06 9:54 ` Liu Hui
2023-07-08 13:59 ` Jack Kamm
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=87fs5tk94a.fsf@gmail.com \
--to=jackkamm@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=liuhui1610@gmail.com \
--cc=yantar92@posteo.net \
/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).