Inline and executing the document

Inline and executing the document

[Erich Neuwirth]

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

Re: Inline and executing the document

[Eric Schulte]

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

Re: Inline and executing the document

[Neuwirth Erich]

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?

Re: Inline and executing the document

[Eric Schulte]

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

Re: Inline and executing the document

[Neuwirth Erich]

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?
> 
> 
> 

Re: Inline and executing the document

[Erich Neuwirth]

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?
>> 
>> 
>> 
> 
> 

Re: Inline and executing the document

[Bastien]

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