Re: Re: eval: Invalid read syntax: "#"Error during redisplay: (void-function -mode)

[Nick Dokos <nicholas.dokos@hp.com>]

Thomas S. Dye <tsd@tsdye.com> wrote:

> ...
> The other problem persists.  I put the example in its own buffer and
> was able to export the entire buffer without problem.
> 
> Are you able to export a subtree?  I get an error if I try to export
> just the subtree.
> 
> The problem appears to be related to exporting results.  If I have
> :exports code, all is well.  With :exports results or :exports  both,
> the error pops up.
> 

I've been playing with the following org file (basically, Tom's example,
except for the results block that gets added when the first src block gets
executed):

--8<---------------cut here---------------start------------->8---
* Export problem

#+begin_src emacs-lisp :results wrap :exports both
   "code block results"
#+end_src

#+results:
#+BEGIN_RESULT
: code block results
#+END_RESULT
#+begin_src emacs-lisp :var lst=a-list :results list
   (reverse lst)
#+end_src

--8<---------------cut here---------------end--------------->8---

Exporting the whole buffer to LaTeX (C-c C-e l): no problem. Exporting
the subtree (C-c C-e 1 l): invalid read syntax: "#'. Just as Tom
described.

The problem seems to have something to do with text properties, in
particular the :org-export-license-to-kill property, but I don't know
either the code or text properties well enough to figure it
out. Nevertheless, here are some observations:

o org-export-preprocess-string creates a temp buffer, inserts its string
argument into the buffer and then does a series of transformations on
the temp buffer (among them org-export-kill-licensed-text and
org-export-blocks-preprocess), and finally scrapes what's left in the
buffer and returns it as its result. BTW, as a minor nit, this should
probably be slightly rewritten to use with-temp-buffer.

o org-export-preprocess-string is called twice: the first time, the
string argument begins on the newline before the first #+begin_src and
ends at the last #+end_src. There are no license-to-kill properties
anywhere. The second time, the string argument is the whole thing from
the asterisk to the last #+end_src. This time, the innards of the code
blocks (the actual code, of face "org-block") have
an :org-license-to-kill property, whereas the meta-lines (starting
with #+ and whose face is "org-meta-line") do not.

o When org-export-kill-licensed-text gets its hands on this buffer, it
kills the code block innards, since they possess the license-to-kill
property, leaving empty src/result blocks:

#+begin_src emacs-lisp :results wrap :exports both
#+end_src
#+results:
#+BEGIN_RESULT
#+END_RESULT
#+begin_src emacs-lisp :var lst=a-list :results list
#+end_src

o Then org-export-blocks-preprocess loops over this and blows up the first
time through its regexp-matching loop: it parses the first line as a header
and it thinks the rest (from the first #+end+_src to the last #+end_src)
is the "body" of the code block, tries to evaluate it as elisp and fails
with the invalid read syntax error.

o One experiment I tried was to comment out the call to
org-export-kill-licensed-text in org-export-preprocess-string: that's
obviously the wrong thing to do, but it does prevent the error from happening,
since the code block innards do not get deleted.

I'm not sure how any of this is supposed to work, so I cannot really go
any further with what I've got. I hope the information above is helpful
to whoever decides to take a look. Or if someone can describe how this
is supposed to work at a high level, maybe I can dig a bit further.

Thanks,
Nick

GNU Emacs 23.2.50.1 (i686-pc-linux-gnu, GTK+ Version 2.14.4) of 2010-10-27 on gamaville.dokosmarshall.org
Org-mode version 7.4 (release_7.4.13.gb65ba.dirty)