cleaning all the #+results from an org document

cleaning all the #+results from an org document

[Stephen Eglen]

Is there an easy way to delete all the #+results: blocks that have been
generated as the result of running org mode blocks?  e.g. If I have the
following chunk:

#+begin_src R 
round(runif(n=5, min=0, max=1), 3)
#+end_src

#+results:
| 0.435 |
| 0.884 |
| 0.219 |
| 0.748 |
| 0.532 |

I'd like the results table to be deleted, but not the code chunk.

Stephen

Re: cleaning all the #+results from an org document

[suvayu ali]

Hi Stephen,

On Thu, Jul 28, 2011 at 10:31 AM, Stephen Eglen
<S.J.Eglen@damtp.cam.ac.uk> wrote:
> Is there an easy way to delete all the #+results: blocks that have been
> generated as the result of running org mode blocks?  e.g. If I have the
> following chunk:
>
> #+begin_src R
> round(runif(n=5, min=0, max=1), 3)
> #+end_src
>
> #+results:
> | 0.435 |
> | 0.884 |
> | 0.219 |
> | 0.748 |
> | 0.532 |
>
> I'd like the results table to be deleted, but not the code chunk.
>

If you don't want the results to be produced at all, you can always use
the babel header option[1] :results silent.

> Stephen
>
>

Footnotes:

[1] <http://orgmode.org/manual/Specific-header-arguments.html#Specific-header-arguments>

-- 
Suvayu

Open source is the future. It sets us free.

Message-ID: <m3d3guepan.fsf@kuru.homelinux.net>
From: Suvayu Ali <jallad@kuru.homelinux.net>

Re: cleaning all the #+results from an org document

[Stephen Eglen]

> 
> If you don't want the results to be produced at all, you can always use
> the babel header option[1] :results silent.

Thanks Suvayu, I'm gradually learning about all the various ways output
can be exported vs shown in the org buffer.  Am I right in understanding
that :results silent just affects whether or not output is written into
the .org buffer, not whether it is exported or not (e.g. into html?)

Stephen

Re: cleaning all the #+results from an org document

[Sebastien Vauban]

Hi Suvayu and Stephen,

suvayu ali wrote:
>> #+begin_src R
>> round(runif(n=5, min=0, max=1), 3)
>> #+end_src
>>
>> #+results:
>> | 0.435 |
>> | 0.884 |
>> | 0.219 |
>> | 0.748 |
>> | 0.532 |
>>
>> I'd like the results table to be deleted, but not the code chunk.
>
> If you don't want the results to be produced at all, you can always use
> the babel header option[1] :results silent.

Even slightly better: don't evaluate the code chunk at all, with option
":eval no".

Best regards,
  Seb

-- 
Sebastien Vauban

Re: cleaning all the #+results from an org document

[suvayu ali]

Hi Stephen,

On Thu, Jul 28, 2011 at 1:41 PM, Stephen Eglen
<S.J.Eglen@damtp.cam.ac.uk> wrote:
>>
>> If you don't want the results to be produced at all, you can always use
>> the babel header option[1] :results silent.
>
> Thanks Suvayu, I'm gradually learning about all the various ways output
> can be exported vs shown in the org buffer.  Am I right in understanding
> that :results silent just affects whether or not output is written into
> the .org buffer, not whether it is exported or not (e.g. into html?)
>

Since I don't know what you are trying to achieve, I'll take a guess.

You wish babel to evaluate the source block and export the results. If
so, then I am afraid the results will be present in the buffer. If
however you only want the source block for fontification and don't
want it to be evaluated, you could try my solution or even better
would be what Seb suggested. However if you wish babel to evaluate the
block but suppress the results, then you should use my suggestion.

The export preferences can be controlled by :exports header. These are
all documented in detail in the manual (referenced in my earlier
email).

> Stephen

Hope this helps.

-- 
Suvayu

Open source is the future. It sets us free.

Re: cleaning all the #+results from an org document

[Torsten Wagner]

Hi,

but there is one interesting aspect missing. If I want to evaluate the 
blocks and see the results but e.g.

a) send it to someone without the results (to let him create his own)
b) archive them without having possible huge amount of lines of results 
which can be reproduced any time by executing the block again.
c) to delete all the old results and start "fresh"

A function to remove all results might become handy.
Sometimes I find it quite difficult to see if a source-code block 
execute at all and if the results are "up-to-date" or still rather old 
results. Sure there is the message in the mini-buffer but its quickly 
overlooked or removed by a key-press.

Actually, I would prefer that "old" results are deleted at the very 
first step, then the source code block should be executed and finally 
results are printed again. Its simply to dangerous to overlook that some 
results might not be updated after all because something might went 
silently wrong within the execution.

Another idea would be to add a timestamp making the last time of 
successful execution clear, which might be nice for many different other 
reasons.

#+results: [2011-07-28 Thu 21:15] ;; huh, no seconds in org-mode ?!

Greetings

Totti


On 07/28/2011 05:31 PM, Stephen Eglen wrote:
> Is there an easy way to delete all the #+results: blocks that have been
> generated as the result of running org mode blocks?  e.g. If I have the
> following chunk:
>
> #+begin_src R
> round(runif(n=5, min=0, max=1), 3)
> #+end_src
>
> #+results:
> | 0.435 |
> | 0.884 |
> | 0.219 |
> | 0.748 |
> | 0.532 |
>
> I'd like the results table to be deleted, but not the code chunk.
>
> Stephen
>

Re: cleaning all the #+results from an org document

[Stephen Eglen]

Thanks Torsten, you've expressed it elegantly!
> 
> a) send it to someone without the results (to let him create his own)
> b) archive them without having possible huge amount of lines of
> results which can be reproduced any time by executing the block again.
> c) to delete all the old results and start "fresh"

I was mostly thinking about b (for putting into version control) and c,
for giving to students to try out.  

Stephen

Re: cleaning all the #+results from an org document

[Ista Zahn]

On Thu, Jul 28, 2011 at 8:59 AM, Stephen Eglen
<S.J.Eglen@damtp.cam.ac.uk> wrote:
> Thanks Torsten, you've expressed it elegantly!
>>
>> a) send it to someone without the results (to let him create his own)
>> b) archive them without having possible huge amount of lines of
>> results which can be reproduced any time by executing the block again.
>> c) to delete all the old results and start "fresh"

+1 for c. I often work with R objects that are simply too large to
store in org tables, so I use babel caching + session + write / load R
data files from disk. This works, but it becomes easy to get to an
inconsistent state, and I would like to be able to delete the results
blocks and run the whole thing fresh.

Best,
Ista

>
> I was mostly thinking about b (for putting into version control) and c,
> for giving to students to try out.
>
> Stephen
>
>



-- 
Ista Zahn
Graduate student
University of Rochester
Department of Clinical and Social Psychology
http://yourpsyche.org

Re: cleaning all the #+results from an org document

[Eric Schulte]

Ista Zahn <izahn@psych.rochester.edu> writes:

> On Thu, Jul 28, 2011 at 8:59 AM, Stephen Eglen
> <S.J.Eglen@damtp.cam.ac.uk> wrote:
>> Thanks Torsten, you've expressed it elegantly!
>>>
>>> a) send it to someone without the results (to let him create his own)
>>> b) archive them without having possible huge amount of lines of
>>> results which can be reproduced any time by executing the block again.
>>> c) to delete all the old results and start "fresh"
>
> +1 for c. I often work with R objects that are simply too large to
> store in org tables, so I use babel caching + session + write / load R
> data files from disk. This works, but it becomes easy to get to an
> inconsistent state, and I would like to be able to delete the results
> blocks and run the whole thing fresh.
>

You could try evaluating the following with "M-x :" in an Org-mode
buffer.  If this works well then I'll give it its own function name and
key shortcut (key combo suggestions welcome).

#+begin_src emacs-lisp
  (org-babel-map-src-blocks nil (org-babel-remove-result))
#+end_src

Thank -- Eric

>
> Best,
> Ista
>
>>
>> I was mostly thinking about b (for putting into version control) and c,
>> for giving to students to try out.
>>
>> Stephen
>>
>>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: cleaning all the #+results from an org document

[Sebastien Vauban]

Hi Eric,

Eric Schulte wrote:
> Ista Zahn <izahn-7lguHJXwfyo6QsK68V2XfZVzexx5G7lz@public.gmane.org> writes:
>
>> On Thu, Jul 28, 2011 at 8:59 AM, Stephen Eglen
>> <S.J.Eglen-S7bItITd6I5K/gkPnarB6Q@public.gmane.org> wrote:
>>> Thanks Torsten, you've expressed it elegantly!
>>>>
>>>> a) send it to someone without the results (to let him create his own)
>>>> b) archive them without having possible huge amount of lines of
>>>> results which can be reproduced any time by executing the block again.
>>>> c) to delete all the old results and start "fresh"
>>
>> +1 for c. I often work with R objects that are simply too large to
>> store in org tables, so I use babel caching + session + write / load R
>> data files from disk. This works, but it becomes easy to get to an
>> inconsistent state, and I would like to be able to delete the results
>> blocks and run the whole thing fresh.
>
> You could try evaluating the following with "M-x :" in an Org-mode
> buffer.  If this works well then I'll give it its own function name and
> key shortcut (key combo suggestions welcome).
>
> #+begin_src emacs-lisp
>   (org-babel-map-src-blocks nil (org-babel-remove-result))
> #+end_src

On the file I took for testing, this works OK.

Regarding a key binding, looking at =C-c C-v h=, this is already quite full.
Though, =k= is free, and could be used for "killing the results".

Best regards,
  Seb

-- 
Sebastien Vauban

Re: cleaning all the #+results from an org document

[Sebastien Vauban]

Hi Eric,

"Sebastien Vauban" wrote:
> Eric Schulte wrote:
>> Ista Zahn <izahn-7lguHJXwfyo6QsK68V2XfZVzexx5G7lz@public.gmane.org> writes:
>>> On Thu, Jul 28, 2011 at 8:59 AM, Stephen Eglen
>>> <S.J.Eglen-S7bItITd6I5K/gkPnarB6Q@public.gmane.org> wrote:
>>>> Thanks Torsten, you've expressed it elegantly!
>>>>>
>>>>> c) to delete all the old results and start "fresh"
>>>
>>> +1 for c. I often work with R objects that are simply too large to store
>>> in org tables, so I use babel caching + session + write / load R data
>>> files from disk. This works, but it becomes easy to get to an inconsistent
>>> state, and I would like to be able to delete the results blocks and run
>>> the whole thing fresh.
>>
>> You could try evaluating the following with "M-x :" in an Org-mode buffer.
>>
>> #+begin_src emacs-lisp
>>   (org-babel-map-src-blocks nil (org-babel-remove-result))
>> #+end_src
>
> On the file I took for testing, this works OK.

More complete test...

* Test 1 -- OK!

** Anonym block

#+begin_src emacs-lisp :results output org
(print "Test")
#+end_src

#+results:
#+BEGIN_ORG

"Test"
#+END_ORG

** Named block

#+source: echo
#+begin_src emacs-lisp :var n="me"
  (message "hi %s" n)
#+end_src

#+results: echo
: hi me

* Test 2 -- OK!

Setting a global data through a fake results block:

#+results: max-lines
: 200

Then using it:

#+source: print-max-lines
#+begin_src emacs-lisp :var n=max-lines
  (message "there are %s lines" n)
#+end_src

#+results: print-max-lines
: there are 200 lines

The latter results block is deleted. The former, with the assignation, is not.
Excellent!

* Test 3 -- Not OK... <<<

And the call line for the named block:

#+call: echo()

#+results: echo()
: hi me

This results block is not deleted, while it should?

> Regarding a key binding, looking at =C-c C-v h=, this is already quite full.
> Though, =k= is free, and could be used for "killing the results".

Best regards,
  Seb

-- 
Sebastien Vauban

Re: cleaning all the #+results from an org document

[Torsten Wagner]

Hi Eric,

On 07/29/2011 08:04 AM, Eric Schulte wrote:
> #+begin_src emacs-lisp
>    (org-babel-map-src-blocks nil (org-babel-remove-result))
> #+end_src

it works on my java stuff, but for some reason it creates a result by 
itself in my system.
E.g.,
#+results:
: 508

There is another glitch...
The additional empty lines created by execution of a code block to 
create the result section are not removed. Going forth and back creates 
more and more empty lines.

    #+begin_src sh
    echo "No more empty rows"
    #+end_src
    * I am squeezed directly under the code block

execute it

    #+begin_src sh
    echo "No more empty rows"
    #+end_src

    #+results:
    : No more empty rows

    * I am squeezed directly under the code block

Remove the result with the given function

    #+begin_src sh
    echo "No more empty rows"
    #+end_src


    * I am squeezed directly under the code block

Execute the code again

    #+begin_src sh
    echo "No more empty rows"
    #+end_src

    #+results:
    : No more empty rows


    * I am squeezed directly under the code block


As for the key I like the C-c C-v k idea


What do you think about the (optional) timestamps idea for results ... 
might be great for archiving. Open a file a year later and still be able 
to see when you executed the blocks the last time might be helpful in 
terms of "Ohhh yeah this was before I fixed this terrible bug"...


Greetings

Totti

Re: cleaning all the #+results from an org document

[Eric Schulte]

"Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:

> Hi Eric,
>
> "Sebastien Vauban" wrote:
>> Eric Schulte wrote:
>>> Ista Zahn <izahn@psych.rochester.edu> writes:
>>>> On Thu, Jul 28, 2011 at 8:59 AM, Stephen Eglen
>>>> <S.J.Eglen@damtp.cam.ac.uk> wrote:
>>>>> Thanks Torsten, you've expressed it elegantly!
>>>>>>
>>>>>> c) to delete all the old results and start "fresh"
>>>>
>>>> +1 for c. I often work with R objects that are simply too large to store
>>>> in org tables, so I use babel caching + session + write / load R data
>>>> files from disk. This works, but it becomes easy to get to an inconsistent
>>>> state, and I would like to be able to delete the results blocks and run
>>>> the whole thing fresh.
>>>
>>> You could try evaluating the following with "M-x :" in an Org-mode buffer.
>>>
>>> #+begin_src emacs-lisp
>>>   (org-babel-map-src-blocks nil (org-babel-remove-result))
>>> #+end_src
>>
>> On the file I took for testing, this works OK.
>
> More complete test...
>
> * Test 1 -- OK!
>
> ** Anonym block
>
> #+begin_src emacs-lisp :results output org
> (print "Test")
> #+end_src
>
> #+results:
> #+BEGIN_ORG
>
> "Test"
> #+END_ORG
>
> ** Named block
>
> #+source: echo
> #+begin_src emacs-lisp :var n="me"
>   (message "hi %s" n)
> #+end_src
>
> #+results: echo
> : hi me
>
> * Test 2 -- OK!
>
> Setting a global data through a fake results block:
>
> #+results: max-lines
> : 200
>
> Then using it:
>
> #+source: print-max-lines
> #+begin_src emacs-lisp :var n=max-lines
>   (message "there are %s lines" n)
> #+end_src
>
> #+results: print-max-lines
> : there are 200 lines
>
> The latter results block is deleted. The former, with the assignation, is not.
> Excellent!
>
> * Test 3 -- Not OK... <<<
>
> And the call line for the named block:
>
> #+call: echo()
>
> #+results: echo()
> : hi me
>
> This results block is not deleted, while it should?
>

Thanks,

I've just pushed up a new interactive function `org-babel-kill-results'
which deletes code block results, inline code block results, and call
line results.

>
>> Regarding a key binding, looking at =C-c C-v h=, this is already quite full.
>> Though, =k= is free, and could be used for "killing the results".
>

Sounds good to me, the above function is now bound to "C-c C-v k".  If
called w/o a prefix argument it only applies to the current code block,
when called with a prefix argument it applies to the entire buffer.

Best -- Eric

>
> Best regards,
>   Seb

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: cleaning all the #+results from an org document

[Eric Schulte]

>
> There is another glitch...
> The additional empty lines created by execution of a code block to
> create the result section are not removed. Going forth and back
> creates more and more empty lines.
>
>    #+begin_src sh
>    echo "No more empty rows"
>    #+end_src
>    * I am squeezed directly under the code block
>
> execute it
>
>    #+begin_src sh
>    echo "No more empty rows"
>    #+end_src
>
>    #+results:
>    : No more empty rows
>
>    * I am squeezed directly under the code block
>
> Remove the result with the given function
>
>    #+begin_src sh
>    echo "No more empty rows"
>    #+end_src
>
>
>    * I am squeezed directly under the code block
>
> Execute the code again
>
>    #+begin_src sh
>    echo "No more empty rows"
>    #+end_src
>
>    #+results:
>    : No more empty rows
>
>
>    * I am squeezed directly under the code block
>

Yes, this is something that seems to need fine tuning from time to time,
as new result and code block types are added and removed.  I've made a
note to take a look at this.

>
>
> As for the key I like the C-c C-v k idea
>

great, applied.

>
>
> What do you think about the (optional) timestamps idea for results
> ... might be great for archiving. Open a file a year later and still
> be able to see when you executed the blocks the last time might be
> helpful in terms of "Ohhh yeah this was before I fixed this terrible
> bug"...
>

I do think this is a good idea.  I don't have the time to implement this
now as it will involve some nontrivial reworking of the syntax of
results lines, but I'll add it to my stack.  Patches welcome :).

Thanks -- Eric

>
>
> Greetings
>
> Totti

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/