From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: Re: eval: Invalid read syntax: "#"Error during redisplay: (void-function -mode) Date: Sun, 12 Dec 2010 17:57:13 -0500 Message-ID: <26738.1292194633@gamaville.dokosmarshall.org> References: <26374.1292004951@gamaville.dokosmarshall.org> <4A9A4769-88C0-4FB3-8D94-17ED3C2DAC81@tsdye.com> <80fwu4f43a.fsf@missioncriticalit.com> Reply-To: nicholas.dokos@hp.com Return-path: Received: from [140.186.70.92] (port=50467 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PRur1-0003DM-E8 for emacs-orgmode@gnu.org; Sun, 12 Dec 2010 17:57:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PRuqz-00033N-Dd for emacs-orgmode@gnu.org; Sun, 12 Dec 2010 17:57:19 -0500 Received: from vms173017pub.verizon.net ([206.46.173.17]:41825) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PRuqz-00032a-AG for emacs-orgmode@gnu.org; Sun, 12 Dec 2010 17:57:17 -0500 Received: from gamaville.dokosmarshall.org ([unknown] [173.76.32.106]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LDC00BHG7RESP00@vms173017.mailsrvcs.net> for emacs-orgmode@gnu.org; Sun, 12 Dec 2010 16:57:15 -0600 (CST) In-reply-to: Message from "Thomas S. Dye" of "Sat, 11 Dec 2010 12:14:01 -1000." List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: "Thomas S. Dye" Cc: =?ISO-8859-1?Q?S=E9bastien_Vauban?= , nicholas.dokos@hp.com, emacs-orgmode@gnu.org Thomas S. Dye 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)