Re: [O] Bug: Org Bable: Set R-specific buffer-wide graphics headers == no R src block eval [8.2.10 (8.2.10-1-g8b63dc-elpa @ /home/user/.emacs.d/elpa/org-20141027/)]

[John Hendy]

On Fri, Oct 31, 2014 at 11:50 PM, myq larson <address@hidden> wrote:
> Remember to cover the basics, that is, what you expected to happen and
> what in fact did happen.  You don't know how to make a good report?  See
>
>      http://orgmode.org/manual/Feedback.html#Feedback
>
> Your bug report will be posted to the Org-mode mailing list.
> ------------------------------------------------------------------------
>
> The documentation suggests that the following should be possible:

Could you link to the /specific/ documentation where you saw this?
Since Org uses a manual as well as a ton of stuff in Worg, I find it
helpful to look at the actual bit of code/explanation you were looking
at. For example, the manual leads me to *somewhat* agree that the
following should be possible (more on that later):
- http://orgmode.org/manual/Header-arguments-in-Org-mode-properties.html

>     ,----
>     | #+PROPERTY: header-args:R :exports results
>     | #+PROPERTY: header-args   :results output graphics
>     | #+PROPERTY: header-args:R :width 400
>     |
>     | #+BEGIN_SRC R :file /tmp/bug.png
>     |   plot(rnorm(100));
>     | #+END_SRC
>     `----
>
> But the third line (`#+PROPERTY: header-args:R :width 400') silently
> prevents /all/ R blocks from being evaluated. Changing the document to
> the following works:

I think your interpretation may be incorrect. Why do you think the
blocks are not being evaluated?

>From fiddling around myself, I believe the true cause is that the
buffer can accept only *one* of each of these properties. My guess is
that you're setting a variable somewhere, and adding two
=header-args:R= simply overwrites the variable with the contents of
the second vs. appending it. I could be wrong.

>     ,----
>     | #+PROPERTY: header-args:R :exports results
>     | #+PROPERTY: header-args   :results output graphics
>     |
>     | #+BEGIN_SRC R  :width 400 :file /tmp/bug.png
>     |   plot(rnorm(100));
>     | #+END_SRC
>     `----
>
> but doing so means that buffer-wide, /language-specific/ header defaults can 
> not
> be set to maintain consistency (at least for R) which is unfortunate. It
> seems that buffer-wide headers can be set for /specific languages/, but
> not language-specific headers? Maybe I haven't read enough of the
> documentation yet, but it seems like that should be possible.

Here was my experiment:

Generates bug.png, exports into PDF, and size responds to changing 800 <-> 400
#+PROPERTY: header-args:R :width 800 :exports results
#+PROPERTY: header-args   :results output graphics

Generates bug.png, exports into PDF, but size is not affected by :width arg
#+PROPERTY: header-args:R :width 800
#+PROPERTY: header-args   :results output graphics
#+PROPERTY: header-args:R :exports results

Generates bug.png, does *not* export to PDF, but you can verify that
the size changes by viewing bug.png after using different :width
settings:
#+PROPERTY: header-args:R :exports results
#+PROPERTY: header-args   :results output graphics
#+PROPERTY: header-args:R :width 800

So, my conclusion was that only the second property gets applied. If
your conclusion that the block wasn't being executed was due to the
plot not appearing in your resultant document, then we're on the same
page. If you didn't even get a bug.png file with any of the
combinations above... then maybe we have different issues.

M-x org-version
Org-mode version 8.3beta (release_8.3beta-483-g58bb3a @
/home/jwhendy/.elisp/org.git/lisp/)

It's up to someone else regarding whether or not the #+property
behavior is desired. I wondered what two subsequent #+options lines
would do, for example, and they appear to be cumulative. For example:

#+options:  toc:nil
#+options: num:nil

Yielded both results even though the default contains both. An analog
would have been for my document to retain a toc but with no section
numbers. So, *something's* different between how these behave.


Best regards,
John


> Thank you very much for this wonderful code/format/project. It's very useful!