2013/8/23 Nicolas Goaziou <n.goaziou@gmail.com>:
> Nicolas Girard <girard.nicolas@gmail.com> writes:
>
> I see.
>
> There is an important difference between evaluating a buffer and
> evaluating a buffer during export. In the latter, Babel has to deal with
> replacement values, i.e., code block is replaced by its results. See the
> difference between `org-export-execute-babel-code' and
> `org-babel-execute-buffer' in a buffer containing only
>
>   src_emacs-lisp[:results raw]{(+ 1 2)}
>
> In this case, your code removes the code (and much more) as
> a side-effect. This confuses `org-babel-exp-non-block-elements', which
> also tries to remove it. As this fails, it removes a random part of the
> buffer instead (probably as a mean revenge).
>

Thanks very much for your insight ! I came to the same conclusions and
found a temporary solution, namely using the value (bufferp
org-current-export-file) to check wether the code is called by the
exporter or just Babel. Attached is a modified version of my code that
behaves differently depending of the value of (bufferp
org-current-export-file).

Do you think it could be robust enough ?

> `org-babel-exp-non-block-elements' and `org-babel-exp-process-buffer'
> could probably check if code still exists before trying to remove (and
> replace) it.
>

Yeah, I don't know how much work it would represent but it seems much
more appropriate that my hack-ish solution.

---
Nicolas