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

[Eric Schulte]

Hi Nick,

Thanks for your thorough investigation below.  I walked through the
steps you outlined locally and ran into the same problems, one
surprising issue is that if you export the subtree by first narrowing to
the subtree with org-narrow-to-subtree and then export the problem does
not present itself.

I don't know enough about the export mechanism to understand why
org-export-preprocess-string is called twice but it seems to me that is
the source of the problem.

I've added this as a test to the Org-mode test suite to help whoever
does know enough about the export mechanics to tell what is taking
place.  This is also troubling in that it appears that even without this
error code block would be evaluated twice on export, which would not be
desirable in the case of code blocks with side-effects.

Best -- Eric

Nick Dokos <address@hidden> writes:

> Thomas S. Dye <address@hidden> 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):
>
> * 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
>
>
> 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)
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> address@hidden
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode