Oh no!
It appears this solution may have been too clever for it's own good.
Thanks for suggesting ":results silent" as an additional default header
argument, that appears to fixed this weird behavior.
I've just pushed up that fix.
Cheers -- Eric
David Hajage writes:
> One comment:
>
> When I
One comment:
When I execute all the buffer (org-babel-execute-buffer), the result is:
#+begin_src R :results output org :exports both
library(ascii)
options(asciiType = "org")
ascii(head(esoph, 3))
#+end_src
#+results:
#+BEGIN_SRC org
| | agegp | alcgp | tobgp| ncases | ncontrols |
|--
Oups, I forgot ob-org in my .emacs... OK, now, really sorry for this.
David
On Thu, Aug 26, 2010 at 22:20, David Hajage wrote:
> I am so sorry to bother you again, but I must miss something.
>
> When I write:
>
> #+begin_src R :results output org :exports both
> library(ascii)
> options(asciiTy
I am so sorry to bother you again, but I must miss something.
When I write:
#+begin_src R :results output org :exports both
library(ascii)
options(asciiType = "org")
ascii(head(esoph))
#+end_src
The results is:
#+results:
#+BEGIN_SRC org
| | agegp | alcgp | tobgp| ncases | ncontrols |
Hi,
A fix to this issue has been pushed up to the repository. As can now be
read in the documentation of the `org-babel-insert-result' function [1],
there is now a subtle distinction between ":results org" and ":results
raw", where ":results org" will wrap code block results in a "begin_src
org"
Hi David,
"#+end_results: foo" (or some derivative syntax) sounds like a good
idea, I'll add it to the Babel task list.
Thanks -- Eric
David Hajage writes:
> OK, I understand that using ":results org", the results is not altered,
> there is no post processing. But I don't want a post processin
OK, I understand that using ":results org", the results is not altered,
there is no post processing. But I don't want a post processing, I would
like a way to tell babel where is the begining *and the end* of the output
produces by a particular R source block. I think an "#+end_results: foo" at
the
Eric Schulte gmail.com> writes:
> Under normal usage w/o this header argument, results are either tabular
> or are textual. If tabular a single table can easily be recognized and
> handled, if textual they are normally enclosed in a block (example,
> html, latex, etc...), the block then allows f
Hi David,
David Hajage writes:
> Thank you very much for your answer.
>
My pleasure
>
> But when I run the following code directly into R, no extra lines is
>added
> by the ascii function:
>> library(ascii)
> Le chargement a nécessité le package : proto
>> options(asciiType = "org")
>> ascii(h
Thank you very much for your answer.
But when I run the following code directly into R, no extra lines is added
by the ascii function:
> library(ascii)
Le chargement a nécessité le package : proto
> options(asciiType = "org")
> ascii(head(esoph)) # no extra line
| | agegp | alcgp | tobgp
Hi David,
It seems that the problem here is in the ascii package. It is inserting
an empty line at the beginning of your table, so that the table is not
snugly sitting under the #+results foo tag, because of this the table
isn't seen as results and is not replaced -- if you delete that space
then
I tried the code with the last development version of org-mode:
#+srcname: foo
#+begin_src R :session *R* :results output org replace
library(ascii)
options(asciiType = "org")
ascii(head(esoph))
#+end_src
#+results: foo
| | agegp | alcgp | tobgp| ncases | ncontrols |
|---+--
12 matches
Mail list logo
