Hello, I’m dealing with a puzzling bug in the new exporter. As background, I’ve written a custom function to process special-blocks, to replicate in the new exporter the functionality of the org-exp-blocks package (http://orgmode.org/worg/org-contrib/org-exp-blocks.html). Because I need the un-processed text inside the special-block (not parsed into an org-elements structure nor escaped for LaTeX special characters), I use the :contents-begin and -end properties of the element to extract this information. These values aren’t accurate in the presence of babel source blocks. In order to reproduce this, extract the attached elisp and org files into your home directory, adjust the paths to point to an up-to-date git checkout of the org sources (I am on today’s commit 196c579), and eval-buffer the lisp file in an emacs -Q (I am using an up-to-date trunk checkout of the meacs sources). Then look in the *Messages* buffer to see what follows “RESULT IS: “. It should be “bar”; I get something else (specifically “ 1)” from the middle of the babel block). Deleting the babel block from the org file and re-running the export call delivers the expected “RESULT IS: bar” message. (Note that the final output is correct because the test elisp falls back to the original definition of ‘org-e-latex-special-block’, but in my use the output is wrong because I rely on the result of the buffer-substring call.) I’m not sure if this is a long-standing problem or not; this is the first time I’ve combined babel with my custom special-blocks code. I’m also at a loss of how to debug the internals of org-elements and org-export, two complex bits of machinery. I guess the value of the :contents-begin and -end properties needs to be fixed in any case. I’d also be happy to discover another, better way of getting the raw text content of the special-block that doesn’t succumb to this problem. Thanks in advance, Aaron Ecay