emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: David Hajage <dhajage@gmail.com>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Re: problem with babel and R
Date: Fri, 27 Aug 2010 00:06:39 +0200	[thread overview]
Message-ID: <AANLkTinhurWcsVTJxSfL9F_B4ayQSQ0RzPrdpHEpZ6Em@mail.gmail.com> (raw)
In-Reply-To: <AANLkTimsYvBrYh63YmB0SdU_A8u-c_3BqoamQZpjVrC0@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 20298 bytes --]

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 |
|---+-------+-----------+----------+--------+-----------|
| 1 | 25-34 | 0-39g/day | 0-9g/day | 0.00   | 40.00     |
| 2 | 25-34 | 0-39g/day | 10-19    | 0.00   | 10.00     |
| 3 | 25-34 | 0-39g/day | 20-29    | 0.00   | 6.00      |
#+END_SRC

#+results:
|   | agegp | alcgp     |    tobgp | ncases | ncontrols |
|---+-------+-----------+----------+--------+-----------|
| 1 | 25-34 | 0-39g/day | 0-9g/day |   0.00 |     40.00 |
| 2 | 25-34 | 0-39g/day |    10-19 |   0.00 |     10.00 |
| 3 | 25-34 | 0-39g/day |    20-29 |   0.00 |      6.00 |

Then, the results is repeated twice in the buffer. I understand why, but
perhaps the "silent" option should be turned on by default for org code
blocks?

David


On Thu, Aug 26, 2010 at 23:51, David Hajage <dhajage@gmail.com> wrote:

> 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 <dhajage@gmail.com> 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(asciiType = "org")
>> ascii(head(esoph))
>> #+end_src
>>
>> The results is:
>>
>> #+results:
>> #+BEGIN_SRC org
>> |   | agegp | alcgp     | tobgp    | ncases | ncontrols |
>> |---+-------+-----------+----------+--------+-----------|
>> | 1 | 25-34 | 0-39g/day | 0-9g/day | 0.00   | 40.00     |
>> | 2 | 25-34 | 0-39g/day | 10-19    | 0.00   | 10.00     |
>> | 3 | 25-34 | 0-39g/day | 20-29    | 0.00   | 6.00      |
>> | 4 | 25-34 | 0-39g/day | 30+      | 0.00   | 5.00      |
>> | 5 | 25-34 | 40-79     | 0-9g/day | 0.00   | 27.00     |
>> | 6 | 25-34 | 40-79     | 10-19    | 0.00   | 7.00      |
>> #+END_SRC
>>
>> OK, the result is surrounded by BEGIN_SRC org/END_SRC. But when I export
>> this, the results is exported as fontified org code. What should I do to
>> have this result interpreted as org markup?
>> David
>>
>>
>>
>> On Thu, Aug 26, 2010 at 18:10, Eric Schulte <schulte.eric@gmail.com>wrote:
>>
>>> 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" block.  The block wrapper makes it possible for the entirety of the
>>> results to be located and removed by Babel upon code block
>>> re-evaluation.
>>>
>>> In addition a new ob-org.el file has been added providing support for
>>> evaluation of Org-mode blocks.  With this new language support loaded
>>> the above technique becomes a working replacement for ":results raw"
>>> allowing the body of the org code block to be interpreted as inline
>>> org-mode text on export.  This is done through some non-standard default
>>> header arguments described in the recent commit message (see [2])
>>>
>>> Best -- Eric
>>>
>>> "Eric Schulte" <schulte.eric@gmail.com> writes:
>>>
>>> > 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 <dhajage@gmail.com> 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 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 end of the output could do the job. Then, the option "replace"
>>> could
>>> >> work in all situation, even if a blank line is inserted somewhere in
>>> the org
>>> >> output. No?
>>> >> David
>>> >>
>>> >>
>>> >> On Tue, Aug 17, 2010 at 17:15, Eric Schulte <schulte.eric@gmail.com>
>>> wrote:
>>> >>
>>> >>> Hi David,
>>> >>>
>>> >>> David Hajage <dhajage@gmail.com> 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(head(esoph)) # no extra line
>>> >>> > |   | agegp | alcgp     | tobgp    | ncases | ncontrols |
>>> >>> > |---+-------+-----------+----------+--------+-----------|
>>> >>> > | 1 | 25-34 | 0-39g/day | 0-9g/day | 0.00   | 40.00     |
>>> >>> > | 2 | 25-34 | 0-39g/day | 10-19    | 0.00   | 10.00     |
>>> >>> > | 3 | 25-34 | 0-39g/day | 20-29    | 0.00   | 6.00      |
>>> >>> > | 4 | 25-34 | 0-39g/day | 30+      | 0.00   | 5.00      |
>>> >>> > | 5 | 25-34 | 40-79     | 0-9g/day | 0.00   | 27.00     |
>>> >>> > | 6 | 25-34 | 40-79     | 10-19    | 0.00   | 7.00      |
>>> >>> >
>>> >>>
>>> >>> ah, my fault, this isn't an ascii issue.
>>> >>>
>>> >>> >
>>> >>> > In fact, the solution was to run 'library(ascii)' in another source
>>> >>> block.
>>> >>> > When I run only this:
>>> >>> >
>>> >>>
>>> >>> Thanks for pointing this out, I see what's happening now.
>>> >>>
>>> >>> The :results output header argument (see [1] for information on
>>> header
>>> >>> arguments) informs Org-mode to collect all of the output of the
>>> source
>>> >>> code block.  This means that when library(ascii) is run, an empty
>>> line
>>> >>> is collected and appended to the output.  Removing the "output"
>>> header
>>> >>> argument should fix this issue.
>>> >>>
>>> >>> My I ask why you are using the ascii package for simple table output?
>>> >>> It seems to me that this would be much simpler using the pure
>>> Org-mode
>>> >>> solution I suggested in my previous email.
>>> >>>
>>> >>> >
>>> >>> > #+begin_src R :session *R* :results output org replace
>>> >>> >   ascii(head(esoph))
>>> >>> > #+end_src
>>> >>> >
>>> >>> > #+results: foo
>>> >>> > |   | agegp | alcgp     |    tobgp | ncases | ncontrols |
>>> >>> > |---+-------+-----------+----------+--------+-----------|
>>> >>> > | 1 | 25-34 | 0-39g/day | 0-9g/day |   0.00 |     40.00 |
>>> >>> > | 2 | 25-34 | 0-39g/day |    10-19 |   0.00 |     10.00 |
>>> >>> > | 3 | 25-34 | 0-39g/day |    20-29 |   0.00 |      6.00 |
>>> >>> > | 4 | 25-34 | 0-39g/day |      30+ |   0.00 |      5.00 |
>>> >>> > | 5 | 25-34 | 40-79     | 0-9g/day |   0.00 |     27.00 |
>>> >>> > | 6 | 25-34 | 40-79     |    10-19 |   0.00 |      7.00 |
>>> >>> >
>>> >>> > Everything is then OK.
>>> >>> > I have no idea why "library(ascii)..." generates an extra empty
>>> line in
>>> >>> the
>>> >>> > results.
>>> >>> >
>>> >>> > If I understand, the results is all the text directly under
>>> "#+results:",
>>> >>> > until the first empty line. But what happens if the result contains
>>> empty
>>> >>> > lines? Here an example with ascii and Hmisc package:
>>> >>> >
>>> >>>
>>> >>> This is not quite right, see [2] for a discussion of results
>>> handling.
>>> >>> The "org" option to results is a special case in which no
>>> >>> post-processing of the results takes place, and the raw output is
>>> >>> inserted into the org-mode buffer.
>>> >>>
>>> >>> 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 for empty lines while
>>> still
>>> >>> making it clear where the results end.
>>> >>>
>>> >>
>>> >>
>>> >>>
>>> >>> >
>>> >>> >> library(ascii)
>>> >>> >> library(Hmisc)
>>> >>> >> ascii(describe(esoph[, 1:3]))
>>> >>> > #+CAPTION: esoph[, 1:3]
>>> >>> > - 3 Variable
>>> >>> > - 88 Observations
>>> >>> >
>>> >>> > *agegp*
>>> >>> > | n  | missing | unique |
>>> >>> > | 88 | 0       | 6      |
>>> >>> >
>>> >>> > |           | 25-34 | 35-44 | 45-54 | 55-64 | 65-74 | 75+ |
>>> >>> > | Frequency | 15    | 15    | 16    | 16    | 15    | 11  |
>>> >>> > | %         | 17    | 17    | 18    | 18    | 17    | 12  |
>>> >>> >
>>> >>> > *alcgp*
>>> >>> > | n  | missing | unique |
>>> >>> > | 88 | 0       | 4      |
>>> >>> >
>>> >>> >  0-39g/day (23, 26%), 40-79 (23, 26%), 80-119 (21, 24%), 120+ (21,
>>> 24%)
>>> >>> >
>>> >>> > *tobgp*
>>> >>> > | n  | missing | unique |
>>> >>> > | 88 | 0       | 4      |
>>> >>> >
>>> >>> >  0-9g/day (24, 27%), 10-19 (24, 27%), 20-29 (20, 23%), 30+ (20,
>>> 23%)
>>> >>> >
>>> >>> > As you can see, describe() generate a description of my data, and
>>> ascii
>>> >>> > generate org-mode markup as result. The result contains empty rows.
>>> Since
>>> >>> > there is no special characters indicating the end of the results in
>>> >>> babel,
>>> >>> > replace option will not work in this case. Is there any workaround?
>>> >>> >
>>> >>>
>>> >>> When using ":results org" there is no workaround, as the explicit
>>> >>> purpose of this setting is for your results to be inserted directly
>>> into
>>> >>> the Org-mode buffer w/o any interpretation or alteration.
>>> >>>
>>> >>
>>> >>
>>> >>>
>>> >>> In general I would recommend keeping a 1-to-1 mapping between code
>>> >>> blocks and result items, which should resolve this issue.
>>> >>>
>>> >>> >
>>> >>> > Of course, ascii is not usefull in this case, but it can coerce
>>> into
>>> >>> > org-mode markup many other R objects (see my previous example and
>>> >>> > http://orgmode.org/worg/org-contrib/babel/examples/ascii.php)
>>> >>> >
>>> >>>
>>> >>> I see, that answers my question from above. Thanks
>>> >>>
>>> >>> Hope this helps -- Eric
>>> >>>
>>> >>> >
>>> >>> > David
>>> >>> >
>>> >>> >
>>> >>> > On Tue, Aug 17, 2010 at 15:57, Eric Schulte <
>>> schulte.eric@gmail.com>
>>> >>> wrote:
>>> >>> >
>>> >>> >> 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 re-run the code block you'll notice that the table is
>>> replaced.
>>> >>> >>
>>> >>> >> Org-mode is very capable of inserting tabular data into Org-mode
>>> >>> >> documents without using the ascii package.  For example the
>>> following
>>> >>> >> would be a more idiomatic example of using Org-mode to create a
>>> table
>>> >>> >> from R code.
>>> >>> >>
>>> >>> >> --8<---------------cut here---------------start------------->8---
>>> >>> >> #+begin_src R
>>> >>> >>  numbers <- matrix(c(51,43,22,92,28,21,68,22,9),ncol=3,byrow=TRUE)
>>> >>> >>  numbers
>>> >>> >> #+end_src
>>> >>> >>
>>> >>> >> #+results:
>>> >>> >> | 51 | 43 | 22 |
>>> >>> >> | 92 | 28 | 21 |
>>> >>> >> | 68 | 22 |  9 |
>>> >>> >>
>>> >>> >> #+begin_src R :colnames yes
>>> >>> >>  numbers <- matrix(c(51,43,22,92,28,21,68,22,9),ncol=3,byrow=TRUE)
>>> >>> >>  numbers
>>> >>> >> #+end_src
>>> >>> >>
>>> >>> >> #+results:
>>> >>> >> | V1 | V2 | V3 |
>>> >>> >> |----+----+----|
>>> >>> >> | 51 | 43 | 22 |
>>> >>> >> | 92 | 28 | 21 |
>>> >>> >> | 68 | 22 |  9 |
>>> >>> >> --8<---------------cut here---------------end--------------->8---
>>> >>> >>
>>> >>> >> or applied to your example, the following code block should
>>> generate the
>>> >>> >> desired results.
>>> >>> >>
>>> >>> >> --8<---------------cut here---------------start------------->8---
>>> >>> >> #+srcname: foo
>>> >>> >> #+begin_src R :session *R*
>>> >>> >>   head(esoph)
>>> >>> >> #+end_src
>>> >>> >> --8<---------------cut here---------------end--------------->8---
>>> >>> >>
>>> >>> >> One last small note: the "replace" argument to :results is
>>> normally the
>>> >>> >> default value, and doesn't need to be explicitly added (although I
>>> can
>>> >>> >> see why you would have added it in this case since it wasn't
>>> working as
>>> >>> >> expected).
>>> >>> >>
>>> >>> >> Cheers -- Eric
>>> >>> >>
>>> >>> >> David Hajage <dhajage@gmail.com> writes:
>>> >>> >>
>>> >>> >> > 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 |
>>> >>> >> > |---+-------+-----------+----------+--------+-----------|
>>> >>> >> > | 1 | 25-34 | 0-39g/day | 0-9g/day | 0.00   | 40.00     |
>>> >>> >> > | 2 | 25-34 | 0-39g/day | 10-19    | 0.00   | 10.00     |
>>> >>> >> > | 3 | 25-34 | 0-39g/day | 20-29    | 0.00   | 6.00      |
>>> >>> >> > | 4 | 25-34 | 0-39g/day | 30+      | 0.00   | 5.00      |
>>> >>> >> > | 5 | 25-34 | 40-79     | 0-9g/day | 0.00   | 27.00     |
>>> >>> >> > | 6 | 25-34 | 40-79     | 10-19    | 0.00   | 7.00      |
>>> >>> >> >
>>> >>> >> >  |   | agegp | alcgp     | tobgp    | ncases | ncontrols |
>>> >>> >> > |---+-------+-----------+----------+--------+-----------|
>>> >>> >> > | 1 | 25-34 | 0-39g/day | 0-9g/day | 0.00   | 40.00     |
>>> >>> >> > | 2 | 25-34 | 0-39g/day | 10-19    | 0.00   | 10.00     |
>>> >>> >> > | 3 | 25-34 | 0-39g/day | 20-29    | 0.00   | 6.00      |
>>> >>> >> > | 4 | 25-34 | 0-39g/day | 30+      | 0.00   | 5.00      |
>>> >>> >> > | 5 | 25-34 | 40-79     | 0-9g/day | 0.00   | 27.00     |
>>> >>> >> > | 6 | 25-34 | 40-79     | 10-19    | 0.00   | 7.00      |
>>> >>> >> >
>>> >>> >> > There is no more ">", but an extra space.
>>> >>> >> > But, the replace option doesn't work: results are still
>>> appended. I am
>>> >>> >> not
>>> >>> >> > an org-mode guru (far, far away), but I think this is because
>>> when
>>> >>> output
>>> >>> >> is
>>> >>> >> > org, there is no indication about the "end" of the results.
>>> >>> >> >
>>> >>> >> > David
>>> >>> >> >
>>> >>> >> >
>>> >>> >> > On Tue, Aug 17, 2010 at 10:17, David Hajage <dhajage@gmail.com>
>>> >>> wrote:
>>> >>> >> >
>>> >>> >> >> Hello,
>>> >>> >> >>
>>> >>> >> >> I am trying to use babel with R. Here the code:
>>> >>> >> >>
>>> >>> >> >> #+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 |
>>> >>> >> >> |---+-------+-----------+----------+--------+-----------|
>>> >>> >> >> | 1 | 25-34 | 0-39g/day | 0-9g/day | 0.00   | 40.00     |
>>> >>> >> >> | 2 | 25-34 | 0-39g/day | 10-19    | 0.00   | 10.00     |
>>> >>> >> >> | 3 | 25-34 | 0-39g/day | 20-29    | 0.00   | 6.00      |
>>> >>> >> >> | 4 | 25-34 | 0-39g/day | 30+      | 0.00   | 5.00      |
>>> >>> >> >> | 5 | 25-34 | 40-79     | 0-9g/day | 0.00   | 27.00     |
>>> >>> >> >> | 6 | 25-34 | 40-79     | 10-19    | 0.00   | 7.00      |
>>> >>> >> >>
>>> >>> >> >> > |   | agegp | alcgp     | tobgp    | ncases | ncontrols |
>>> >>> >> >> |---+-------+-----------+----------+--------+-----------|
>>> >>> >> >> | 1 | 25-34 | 0-39g/day | 0-9g/day | 0.00   | 40.00     |
>>> >>> >> >> | 2 | 25-34 | 0-39g/day | 10-19    | 0.00   | 10.00     |
>>> >>> >> >> | 3 | 25-34 | 0-39g/day | 20-29    | 0.00   | 6.00      |
>>> >>> >> >> | 4 | 25-34 | 0-39g/day | 30+      | 0.00   | 5.00      |
>>> >>> >> >> | 5 | 25-34 | 40-79     | 0-9g/day | 0.00   | 27.00     |
>>> >>> >> >> | 6 | 25-34 | 40-79     | 10-19    | 0.00   | 7.00      |
>>> >>> >> >>
>>> >>> >> >> With org-mode 7.01g in emacs 23, there is two problems:
>>> >>> >> >>  - an extra ">" is added in the first line while output is
>>> "org"
>>> >>> >> >>  - when I run the code twice, the new results is appended,
>>> while I
>>> >>> have
>>> >>> >> the
>>> >>> >> >> option "replace".
>>> >>> >> >>
>>> >>> >> >> Is there any problem with my header?
>>> >>> >> >>
>>> >>> >> >> Thank you very much for your help.
>>> >>> >> >> David
>>> >>> >> >>
>>> >>> >> > _______________________________________________
>>> >>> >> > Emacs-orgmode mailing list
>>> >>> >> > Please use `Reply All' to send replies to the list.
>>> >>> >> > Emacs-orgmode@gnu.org
>>> >>> >> > http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>>> >>> >>
>>> >>>
>>> >>> Footnotes:
>>> >>> [1]
>>> http://orgmode.org/manual/Header-arguments.html#Header-arguments
>>> >>>
>>> >>> [2]
>>> >>>
>>> http://orgmode.org/manual/Results-of-evaluation.html#Results-of-evaluation
>>> >>>
>>> >>>
>>> >>> L'intégrité de ce message n'étant pas assurée sur Internet,
>>> l'Institut
>>> >>> Curie ne peut être tenu responsable de son contenu.
>>> >>> Si vous n'êtes pas destinataire de ce message confidentiel, merci de
>>> le
>>> >>> détruire et d'avertir immédiatement l'expéditeur.
>>> >>> Afin de contribuer au respect de l'environnement, merci de n'imprimer
>>> ce
>>> >>> mail qu'en cas de nécessité.
>>> >>>
>>>
>>> Footnotes:
>>> [1]
>>> ,----[org-babel-insert-result]
>>> | org-babel-insert-result is a Lisp function in `ob.el'.
>>> |
>>> | (org-babel-insert-result RESULT &optional RESULT-PARAMS INFO HASH
>>> | INDENT LANG)
>>> |
>>> | Insert RESULT into the current buffer.
>>> | By default RESULT is inserted after the end of the
>>> | current source block.  With optional argument RESULT-PARAMS
>>> | controls insertion of results in the org-mode file.
>>> | RESULT-PARAMS can take the following values...
>>> |
>>> | replace - (default option) insert results after the source block
>>> |           replacing any previously inserted results
>>> |
>>> | silent -- no results are inserted
>>> |
>>> | file ---- the results are interpreted as a file path, and are
>>> |           inserted into the buffer using the Org-mode file syntax
>>> |
>>> | raw ----- results are added directly to the org-mode file.  This
>>> |           is a good option if you code block will output org-mode
>>> |           formatted text.
>>> |
>>> | org ----- this is the same as the 'raw' option
>>> |
>>> | html ---- results are added inside of a #+BEGIN_HTML block.  This
>>> |           is a good option if you code block will output html
>>> |           formatted text.
>>> |
>>> | latex --- results are added inside of a #+BEGIN_LATEX block.
>>> |           This is a good option if you code block will output
>>> |           latex formatted text.
>>> |
>>> | code ---- the results are extracted in the syntax of the source
>>> |           code of the language being evaluated and are added
>>> |           inside of a #+BEGIN_SRC block with the source-code
>>> |           language set appropriately.  Note this relies on the
>>> |           optional LANG argument.
>>> |
>>> | [back]
>>> `----
>>>
>>> [2]
>>> ,----
>>> | ob-org has two non-standard header arguments in that it exports it's
>>> | results by default and the result type defaults to raw, this ensures
>>> | that the body of a begin_src org block exports transparently.
>>> |
>>> | This is a breaking change in that if you are currently using org
>>> | code blocks to export org-fontified code you will have to set the
>>> | ":exports" header argument for org-mode blocks to "code" on a block,
>>> | file, language or system-wide basis.
>>> `----
>>>
>>
>>
>

[-- Attachment #1.2: Type: text/html, Size: 27208 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

  reply	other threads:[~2010-08-26 22:07 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-17  8:17 problem with babel and R David Hajage
2010-08-17 12:01 ` David Hajage
2010-08-17 13:57   ` Eric Schulte
2010-08-17 14:41     ` David Hajage
2010-08-17 15:15       ` Eric Schulte
2010-08-17 17:07         ` Tom Short
     [not found]       ` <1668ca$1pq4c@mail.curie.net>
2010-08-18  6:53         ` David Hajage
2010-08-18 22:13           ` Eric Schulte
2010-08-26 16:10             ` Eric Schulte
2010-08-26 20:20               ` David Hajage
2010-08-26 21:51                 ` David Hajage
2010-08-26 22:06                   ` David Hajage [this message]
2010-08-26 23:37                     ` Eric Schulte

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=AANLkTinhurWcsVTJxSfL9F_B4ayQSQ0RzPrdpHEpZ6Em@mail.gmail.com \
    --to=dhajage@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=schulte.eric@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).