[bug] [babel] results eat up following text

[bug] [babel] results eat up following text

[Eric S Fraga]

[-- Attachment #1: Type: text/plain, Size: 743 bytes --]

Hello,

please see attached file for a simple example of a bug in babel: if you
execute the code block, the results section overwrites the text that
follows the code block.

If you insert an extra blank line between the end of the code block and
the text that follows (before executing the block for the first time),
the results will *not* overwrite the text *but* if you then execute the
block again, the text will be overwritten.

My feeling is that there's some interplay between lists (I use the 'both
org-list-ending-method) and babel.  I've no idea otherwise what is
happening unfortunately.  

I can send my full configuration if need be but always prefer not to as
I have to spend time obfuscating a number of things...

Thanks,
eric


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: examplebug.org --]
[-- Type: text/orgmode, Size: 303 bytes --]

# -*- coding: utf-8; -*-
#+TITLE:     examplebug.org
#+AUTHOR:    Eric S Fraga
#+EMAIL:     e.fraga@ucl.ac.uk

* babel results overwrite following text 

  - start an item so that following is indented:

    #+begin_src octave :var x=10
3*x+5
    #+end_src

    This is some text that follows the code.

[-- Attachment #3: Type: text/plain, Size: 46 bytes --]


-- 
Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D)

[-- Attachment #4: 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

Re: [bug] [babel] results eat up following text

[Eric Schulte]

Hi Eric,

Thanks for catching this issue.  It turns out this was a result of
adding lists as supported output types, the code block thinks that the
enclosing list is the results list, and deletes it before inserting new
results.

Luckily this was a quick 2-character change, which has been committed.

Cheers -- Eric

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> Hello,
>
> please see attached file for a simple example of a bug in babel: if you
> execute the code block, the results section overwrites the text that
> follows the code block.
>
> If you insert an extra blank line between the end of the code block and
> the text that follows (before executing the block for the first time),
> the results will *not* overwrite the text *but* if you then execute the
> block again, the text will be overwritten.
>
> My feeling is that there's some interplay between lists (I use the 'both
> org-list-ending-method) and babel.  I've no idea otherwise what is
> happening unfortunately.  
>
> I can send my full configuration if need be but always prefer not to as
> I have to spend time obfuscating a number of things...
>
> Thanks,
> eric
>
> # -*- coding: utf-8; -*-
> #+TITLE:     examplebug.org
> #+AUTHOR:    Eric S Fraga
> #+EMAIL:     e.fraga@ucl.ac.uk
>
> * babel results overwrite following text 
>
>   - start an item so that following is indented:
>
>     #+begin_src octave :var x=10
> 3*x+5
>     #+end_src
>
>     This is some text that follows the code.

Re: [bug] [babel] results eat up following text

[Eric S Fraga]

"Eric Schulte" <schulte.eric@gmail.com> writes:

> Hi Eric,
>
> Thanks for catching this issue.  It turns out this was a result of
> adding lists as supported output types, the code block thinks that the
> enclosing list is the results list, and deletes it before inserting new
> results.
>
> Luckily this was a quick 2-character change, which has been committed.

And thank you for the quick fix!  Works perfectly.

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.4 (release_7.4.260.gba0f6.dirty)

[babel] Feature request, was Re: [bug] [babel] results eat up following text

[Eric S Fraga]

"Eric Schulte" <schulte.eric@gmail.com> writes:

> Hi Eric,
>
> Thanks for catching this issue.  It turns out this was a result of
> adding lists as supported output types, the code block thinks that the
> enclosing list is the results list, and deletes it before inserting new
> results.
>
> Luckily this was a quick 2-character change, which has been committed.
>
> Cheers -- Eric

Eric,

maybe this will also be a quick change...

I have a (very low priority) feature request: as I often have babel
source code blocks within lists, it would be nice if the #+results line
were generated to be indented to the same level as the #+begin_src
&/or #+begin_end lines.  Babel appears to generate a results header with
only 2 spaces before it, if no such line exists already, regardless of
the indentation of the code block.

However, if the results header is already there, the indentation is
preserved, which is really nice!  This is why it's a low priority
request: it's straightforward enough to indent the line the first time
it is generated!

Thanks,
eric

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.4 (release_7.4.260.gba0f6.dirty)