The following examples shows some issues #+title: Inline formatting Inline code examples src_emacs-lisp{(+ 2 3)} src_emacs-lisp[:results raw]{(2 + 5)} #+BEGIN_SRC emacs-lisp (+ 11 12) #+END_SRC #+RESULTS: : 23 #+BEGIN_SRC emacs-lisp :results raw (+ 11 13) #+End_Src ################################## In 3 of the 4 examples running the code repeatedly with C-c C-c will produce multiple copies of the output. Only the default code block (example 3) "knows" to delete the old result when a new one is produced. If one is not careful about this, one can easily produce inconsistent documents. Changing the code but not the old results will keep different results within the document and these results will also be exported. A solution would be to have markers like #+begin_results #+end_results Then, org mode could know what exactly to delete. This would need to me modified for inline src statements bit should be doable. I think this could help with the general concept of producing consistent reproducible research documents. Anny suggestions regarding this issue? Erich
Erich Neuwirth <erich.neuwirth@univie.ac.at> writes: > The following examples shows some issues > All of these examples execute as expected. It is not always possible to automatically identify and remove the results of a code block execution. Remember that Org-mode files are just plain text. > > #+title: Inline formatting > > Inline code examples > > src_emacs-lisp{(+ 2 3)} > Inline code blocks like the above are mainly intended for use during execution, not to be executed in the buffer during normal use. > > src_emacs-lisp[:results raw]{(2 + 5)} > The above is not valid elisp, but the same statement still applies. > > #+BEGIN_SRC emacs-lisp > (+ 11 12) > #+END_SRC > > #+RESULTS: > : 23 > > #+BEGIN_SRC emacs-lisp :results raw > (+ 11 13) > #+End_Src > By definition "raw" results are not marked in any way and thus can not be removed from the buffer. Maybe try ":results wrap" if you want un-quoted un-exampled results which can still be automatically removed. Best, > > ################################## > > In 3 of the 4 examples running the code repeatedly > with C-c C-c > will produce multiple copies of the output. > Only the default code block (example 3) > "knows" to delete the old result when a new one is produced. > > If one is not careful about this, one can easily produce inconsistent documents. > Changing the code but not the old results will keep different results within the document > and these results will also be exported. > > A solution would be to have markers like > > #+begin_results > #+end_results > > Then, org mode could know what exactly to delete. > This would need to me modified for inline src statements bit should be doable. > > I think this could help with the general concept of producing consistent reproducible research documents. > > Anny suggestions regarding this issue? > > Erich > > > > > > > > -- Eric Schulte http://cs.unm.edu/~eschulte
Sorry for not reading the docs carefully enough. I had overlooked :results wrap But even with this options things behave strangely. src_emacs-lisp[:results wrap]{(+ 2 3)} :RESULTS: 5:END: :RESULTS: 5:END: :RESULTS: 5:END: :RESULTS: 5:END: :RESULTS: 5:END: Running the code multiple times in the document produces multiple outputs. I though the whole idea of wrapping was intended to mark results in a way the are replaces when the command is reexecuted. Furthermore, on exporting the keywords :RESULTS: and :END: are written into the exported document (I tried LaTeX+pdf and HTML) Am I still misunderstanding something?
Neuwirth Erich <erich.neuwirth@univie.ac.at> writes: > Sorry for not reading the docs carefully enough. > I had overlooked :results wrap > But even with this options things behave strangely. > > src_emacs-lisp[:results wrap]{(+ 2 3)} :RESULTS: > 5:END: > :RESULTS: > 5:END: > :RESULTS: > 5:END: > :RESULTS: > 5:END: > :RESULTS: > 5:END: > Inline code blocks are only meant for execution during export. They were added so that results of code blocks could be inserted inline in blocks of prose. An example like the above should use a regular code block. I would not be surprised if the manual is insufficiently clear on this point. If you could suggest a placement where wording such as the above would have been helpful please let me know and I'll update the manual. Thanks, > > > Running the code multiple times in the document produces multiple outputs. > I though the whole idea of wrapping was intended to mark results in a way the are replaces > when the command is reexecuted. > > Furthermore, on exporting the keywords :RESULTS: and :END: > are written into the exported document (I tried LaTeX+pdf and HTML) > > Am I still misunderstanding something? > > > -- Eric Schulte http://cs.unm.edu/~eschulte
Thank you,
this clarified things for me!
I will look and suggest a place for mentioning this in the docs.
Erich
On Sep 20, 2012, at 4:23 PM, Neuwirth Erich <erich.neuwirth@univie.ac.at> wrote:
> Sorry for not reading the docs carefully enough.
> I had overlooked :results wrap
> But even with this options things behave strangely.
>
> src_emacs-lisp[:results wrap]{(+ 2 3)} :RESULTS:
> 5:END:
> :RESULTS:
> 5:END:
> :RESULTS:
> 5:END:
> :RESULTS:
> 5:END:
> :RESULTS:
> 5:END:
>
>
> Running the code multiple times in the document produces multiple outputs.
> I though the whole idea of wrapping was intended to mark results in a way the are replaces
> when the command is reexecuted.
>
> Furthermore, on exporting the keywords :RESULTS: and :END:
> are written into the exported document (I tried LaTeX+pdf and HTML)
>
> Am I still misunderstanding something?
>
>
>
One more thought:
The :RESULTS: xxxx :END:
wrapper would allow to replace when inline code is run once again.
It would fit with my personal workflow to be able to check what will go into the exported documents
while fiddling around in the source document.
If this does not fit with what the org designers think, thats OK.
I just wanted to note that the implementation replacement of results of inline code
in this special case could probably done with ease.
Erich
On Sep 20, 2012, at 9:09 PM, Neuwirth Erich <erich.neuwirth@univie.ac.at> wrote:
> Thank you,
> this clarified things for me!
>
> I will look and suggest a place for mentioning this in the docs.
>
> Erich
>
>
> On Sep 20, 2012, at 4:23 PM, Neuwirth Erich <erich.neuwirth@univie.ac.at> wrote:
>
>> Sorry for not reading the docs carefully enough.
>> I had overlooked :results wrap
>> But even with this options things behave strangely.
>>
>> src_emacs-lisp[:results wrap]{(+ 2 3)} :RESULTS:
>> 5:END:
>> :RESULTS:
>> 5:END:
>> :RESULTS:
>> 5:END:
>> :RESULTS:
>> 5:END:
>> :RESULTS:
>> 5:END:
>>
>>
>> Running the code multiple times in the document produces multiple outputs.
>> I though the whole idea of wrapping was intended to mark results in a way the are replaces
>> when the command is reexecuted.
>>
>> Furthermore, on exporting the keywords :RESULTS: and :END:
>> are written into the exported document (I tried LaTeX+pdf and HTML)
>>
>> Am I still misunderstanding something?
>>
>>
>>
>
>
Hi Erich, Erich Neuwirth <erich.neuwirth@univie.ac.at> writes: > One more thought: > The :RESULTS: xxxx :END: > wrapper would allow to replace when inline code is run once again. > It would fit with my personal workflow to be able to check what will go into the exported documents > while fiddling around in the source document. > > If this does not fit with what the org designers think, thats OK. It would not be a "drawer" anymore. > I just wanted to note that the implementation replacement of results of inline code > in this special case could probably done with ease. FWIW you can use src_<language>{<body>} for inline code. Best, -- Bastien