From: Aaron Ecay <aaronecay@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Bug in new exporter with babel blocks
Date: Tue, 22 Jan 2013 16:54:32 -0500 [thread overview]
Message-ID: <87obggevdz.fsf@gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2011 bytes --]
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
[-- Attachment #2: org-bug.el --]
[-- Type: application/emacs-lisp, Size: 708 bytes --]
[-- Attachment #3: org-bug.org --]
[-- Type: text/plain, Size: 128 bytes --]
* Intro
#+name: setup
#+begin_src elisp :results output :exports both
(+ 1 1)
#+end_src
foo
#+begin_foo
bar
#+end_foo
baz
next reply other threads:[~2013-01-22 21:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-22 21:54 Aaron Ecay [this message]
2013-01-23 13:28 ` Nicolas Goaziou
2013-02-21 18:11 ` Aaron Ecay
2013-04-20 19:32 ` Nicolas Goaziou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87obggevdz.fsf@gmail.com \
--to=aaronecay@gmail.com \
--cc=emacs-orgmode@gnu.org \
--subject='Re: Bug in new exporter with babel blocks' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox:
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).