Ihor Radchenko <yanta...@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....@nicolasgoaziou.fr/
[2] https://list.orgmode.org/87eenpfe77....@gmail.com/
