all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* [babel] possible bug in org-babel-execute-buffer?
@ 2010-05-26 23:59 Erik Iverson
  2010-05-27  1:45 ` Eric Schulte
  0 siblings, 1 reply; 3+ messages in thread
From: Erik Iverson @ 2010-05-26 23:59 UTC (permalink / raw)
  To: emacs-orgmode

Hello,

I am using Emacs 23.1, orgmode pulled from git just an hour ago, but I noticed 
the following issue on a version pulled about a week ago, too.  I don't know if 
it ever worked as I expect.  These development versions have C-c C-v as the 
babel prefix keys, so if you are using a stable version, the following may be 
different.  Also, all my examples use R.

I'm trying to use C-c C-v C-b to call org-babel-execute-buffer, which is 
documented as:

Call `org-babel-execute-src-block' on every source block in
the current buffer.

However, what happens when this is called seems to depend on which trees are 
visible in the buffer when it's called!

Paste the following orgmode file into an org buffer, and make sure all trees are 
fully collapsed, i.e., you just see the headlines "Big Block 1" and "Big Block 
2", and try C-c C-v C-b.

After it's done executing, notice that only the *last* source blocks of each 
tree were run.  Now collapse everything again, and call org-babel-execute-buffer 
again.  The same thing happens, except now there are *two* results present for 
those last code blocks.

Now start all over again with the below code, so no results are present.  Expand 
all subtrees so everything is visible.  Do C-c C-v C-b, and all results are 
inserted as expected.  Run the blocks a second time with everything open, and 
every block still only has 1 results section, as expected.  This is how I would 
expect/hope the function to work regardless of the hide/show states of the trees.

So I think there are two possibly related problems when trees aren't fully 
expanded:

1) Only the last source code block per hidden tree is getting run
2) That last block will insert results multiple times if 
org-babel-execute-buffer is called multiple times

Thanks!
Erik

=================== orgmode code follows below ======================


* Big Block 1
** my first bit of code!
#+begin_src R
  "from the first nested code block in Big Block 1"
#+end_src
** and some more code!
#+begin_src R
   "from the middle nested code block in Big Block 1"
#+end_src
** and final code!
#+begin_src R
   "from the final nested code block in Big Block 1"
#+end_src
* Big Block 2
#+begin_src R
   "from the only code block in Big Block 2"
#+end_src

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [babel] possible bug in org-babel-execute-buffer?
  2010-05-26 23:59 [babel] possible bug in org-babel-execute-buffer? Erik Iverson
@ 2010-05-27  1:45 ` Eric Schulte
  2010-05-27  4:54   ` Erik Iverson
  0 siblings, 1 reply; 3+ messages in thread
From: Eric Schulte @ 2010-05-27  1:45 UTC (permalink / raw)
  To: Erik Iverson; +Cc: emacs-orgmode

Hi Erik,

Thanks for the report, this should now be fixed in the latest git HEAD,
please let me know if the problem persists.

Best -- Eric

Erik Iverson <eriki@ccbr.umn.edu> writes:

> Hello,
>
> I am using Emacs 23.1, orgmode pulled from git just an hour ago, but I
> noticed the following issue on a version pulled about a week ago, too.
> I don't know if it ever worked as I expect.  These development
> versions have C-c C-v as the babel prefix keys, so if you are using a
> stable version, the following may be different.  Also, all my examples
> use R.
>
> I'm trying to use C-c C-v C-b to call org-babel-execute-buffer, which
> is documented as:
>
> Call `org-babel-execute-src-block' on every source block in
> the current buffer.
>
> However, what happens when this is called seems to depend on which
> trees are visible in the buffer when it's called!
>
> Paste the following orgmode file into an org buffer, and make sure all
> trees are fully collapsed, i.e., you just see the headlines "Big Block
> 1" and "Big Block 2", and try C-c C-v C-b.
>
> After it's done executing, notice that only the *last* source blocks
> of each tree were run.  Now collapse everything again, and call
> org-babel-execute-buffer again.  The same thing happens, except now
> there are *two* results present for those last code blocks.
>
> Now start all over again with the below code, so no results are
> present.  Expand all subtrees so everything is visible.  Do C-c C-v
> C-b, and all results are inserted as expected.  Run the blocks a
> second time with everything open, and every block still only has 1
> results section, as expected.  This is how I would expect/hope the
> function to work regardless of the hide/show states of the trees.
>
> So I think there are two possibly related problems when trees aren't
> fully expanded:
>
> 1) Only the last source code block per hidden tree is getting run
> 2) That last block will insert results multiple times if
> org-babel-execute-buffer is called multiple times
>
> Thanks!
> Erik
>
> =================== orgmode code follows below ======================
>
>
> * Big Block 1
> ** my first bit of code!
> #+begin_src R
>  "from the first nested code block in Big Block 1"
> #+end_src
> ** and some more code!
> #+begin_src R
>   "from the middle nested code block in Big Block 1"
> #+end_src
> ** and final code!
> #+begin_src R
>   "from the final nested code block in Big Block 1"
> #+end_src
> * Big Block 2
> #+begin_src R
>   "from the only code block in Big Block 2"
> #+end_src
>
>
>
> _______________________________________________
> 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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [babel] possible bug in org-babel-execute-buffer?
  2010-05-27  1:45 ` Eric Schulte
@ 2010-05-27  4:54   ` Erik Iverson
  0 siblings, 0 replies; 3+ messages in thread
From: Erik Iverson @ 2010-05-27  4:54 UTC (permalink / raw)
  To: Eric Schulte; +Cc: emacs-orgmode

Eric Schulte wrote:
> Hi Erik,
> 
> Thanks for the report, this should now be fixed in the latest git HEAD,
> please let me know if the problem persists.
> 
> Best -- Eric

Looks good on the test file I had included in my initial report, thank you very 
much.  When I get back to work tomorrow, I will try it on the actual file that 
was giving me trouble.  Thank you, Eric.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-05-27  5:06 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-26 23:59 [babel] possible bug in org-babel-execute-buffer? Erik Iverson
2010-05-27  1:45 ` Eric Schulte
2010-05-27  4:54   ` Erik Iverson

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.