From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Schulte" Subject: Re: Re: eval: Invalid read syntax: "#"Error during redisplay: (void-function -mode) Date: Mon, 13 Dec 2010 12:42:17 -0700 Message-ID: <87hbehihnq.fsf@gmail.com> References: <26374.1292004951@gamaville.dokosmarshall.org> <4A9A4769-88C0-4FB3-8D94-17ED3C2DAC81@tsdye.com> <80fwu4f43a.fsf@missioncriticalit.com> <26738.1292194633@gamaville.dokosmarshall.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from [140.186.70.92] (port=49685 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PSEId-00024C-7X for emacs-orgmode@gnu.org; Mon, 13 Dec 2010 14:43:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PSEIG-0008UB-4A for emacs-orgmode@gnu.org; Mon, 13 Dec 2010 14:43:07 -0500 Received: from mail-gw0-f48.google.com ([74.125.83.48]:40536) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PSEIF-0008Tk-Uz for emacs-orgmode@gnu.org; Mon, 13 Dec 2010 14:42:44 -0500 Received: by gwaa20 with SMTP id a20so4607252gwa.35 for ; Mon, 13 Dec 2010 11:42:43 -0800 (PST) In-Reply-To: <26738.1292194633@gamaville.dokosmarshall.org> (Nick Dokos's message of "Sun, 12 Dec 2010 17:57:13 -0500") 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: nicholas.dokos@hp.com Cc: =?utf-8?Q?S=C3=A9bastien?= Vauban , emacs-orgmode@gnu.org 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 writes: > 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): > > * 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. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode