From: Rainer M Krug <Rainer@krugs.de>
To: Feng Shu <tumashu@gmail.com>
Cc: orgmode <emacs-orgmode@gnu.org>
Subject: Re: ob-R, about :results value verbatim drawer
Date: Wed, 24 Sep 2014 09:52:06 +0200 [thread overview]
Message-ID: <m2r3z1zc9l.fsf@krugs.de> (raw)
In-Reply-To: <87zjdpn04o.fsf@gmail.com> (Aaron Ecay's message of "Tue, 23 Sep 2014 23:55:03 -0400")
[-- Attachment #1: Type: text/plain, Size: 3266 bytes --]
Aaron Ecay <aaronecay@gmail.com> writes:
> Hi Feng,
>
> 2014ko irailak 23an, Feng Shu-ek idatzi zuen:
>> but when I add a #+PROPERTY, it show error like below, how to deal with
>> it ? thanks ...
>>
>> #+PROPERTY: header-args:R :colnames yes :rownames no :exports both
>> #+BEGIN_SRC R :results value verbatim drawer
>> data <- list(a="[[./test1.org]]",b="[[./test2.org]]",c="[[./test3.org]]")
>> c(data$a,data$b,data$c)
>> #+END_SRC
>>
>>
>> executing R code block...
>> Wrote /tmp/babel-1984743i/ob-input-198472lB
>> org-babel-R-evaluate-external-process: Wrong type argument: listp, "x
>> [[./test1.org]]
>> [[./test2.org]]
>> [[./test3.org]]
>> "
>
> The simple answer is don’t add the #+property line. In particular, the
> :colnames yes setting doesn’t play well with your code block. If you
> must have the #+property line for other reasons, override the global
> setting of :colnames yes with :colnames no on the source block.
And another problem with different ways of setting header arguments.
Is this only a problem of R, or is this general (it does not seem to be
only me...) in org?
The more I think, a proper outline and description is needed how header
arguments for source blocks (probably in general, but I use org mainy
for literate programming and data analysis therefore always including
source code blocks) can be set and how these interact (inheritance, the
+, different ways of setting header arguments as above, ...). These
header arguments are a *very* powerful tool and you can do many things -
but you can also break things very easily.
In many cases, I resort to trial and error: This is working, now I want
to have that behaviour for this code block, normally I would do it like
this, not working, let's try out what is working. But this is far from
ideal and leads to spaghetti-code type property setting which is quite
fragile.
Again: is it only me? I don't think (hope?) so.
So what could be done to remedy this? I think a few aspects should be
tackeled:
1) a lot of information is in the manual - but spread out in many
different locations / sections. The first would be to bring these
sections together and to consolidate them into one section.
2) We need a set of simple and easily to understand examples which
build on each other. So starting with simple examples and expand
these to complex examples.
3) These examples should be uaed as tests (maybe there are tests for
this, but I am not at all familiar with the test framework of org).
4) based on these, the org code should be checked for
- bugs (obviously)
- inconsistencies in the approach used for header argument setting
and inheritance and
- possibly deprecate certain aspects to simplify it (but keep the
flexibility which is there at the moment!
5) the property inheritance and hierarchy of different ways of setting
these should be documented in a structured way.
So is there anything in this direction? I guess this would be quite a
big task - would there be interest in pursuing this?
Rainer
--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982
[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]
next prev parent reply other threads:[~2014-09-24 7:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-24 2:43 ob-R, about :results value verbatim drawer Feng Shu
2014-09-24 3:55 ` Aaron Ecay
2014-09-24 7:52 ` Header Arguments of Code Blocks - problems and challenges Rainer M Krug
2014-09-24 7:52 ` Rainer M Krug [this message]
2014-09-26 0:13 ` ob-R, about :results value verbatim drawer Grant Rettke
2014-09-26 7:54 ` Rainer M Krug
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=m2r3z1zc9l.fsf@krugs.de \
--to=rainer@krugs.de \
--cc=emacs-orgmode@gnu.org \
--cc=tumashu@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).