From: Nick Dokos <nicholas.dokos@hp.com>
To: "Thomas S. Dye" <tsd@tsdye.com>
Cc: "Sébastien Vauban" <wxhgmqzgwmuf@spammotel.com>,
nicholas.dokos@hp.com, emacs-orgmode@gnu.org
Subject: Re: Re: eval: Invalid read syntax: "#"Error during redisplay: (void-function -mode)
Date: Sun, 12 Dec 2010 17:57:13 -0500 [thread overview]
Message-ID: <26738.1292194633@gamaville.dokosmarshall.org> (raw)
In-Reply-To: Message from "Thomas S. Dye" <tsd@tsdye.com> of "Sat, 11 Dec 2010 12:14:01 -1000." <C91A7CA9-D952-40D3-99B3-E7AF53100C83@tsdye.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)
next prev parent reply other threads:[~2010-12-12 22:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-10 17:56 eval: Invalid read syntax: "#"Error during redisplay: (void-function -mode) Thomas S. Dye
2010-12-10 18:15 ` Nick Dokos
2010-12-10 18:27 ` Thomas S. Dye
2010-12-10 18:34 ` Nick Dokos
2010-12-10 18:55 ` Thomas S. Dye
2010-12-11 18:04 ` Bernt Hansen
2010-12-11 18:51 ` Nick Dokos
2010-12-11 20:26 ` Sébastien Vauban
2010-12-11 22:14 ` Thomas S. Dye
2010-12-11 23:06 ` Nick Dokos
2010-12-12 0:03 ` Sébastien Vauban
2010-12-12 0:42 ` Thomas S. Dye
2010-12-12 22:57 ` Nick Dokos [this message]
2010-12-13 19:42 ` Eric Schulte
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=26738.1292194633@gamaville.dokosmarshall.org \
--to=nicholas.dokos@hp.com \
--cc=emacs-orgmode@gnu.org \
--cc=tsd@tsdye.com \
--cc=wxhgmqzgwmuf@spammotel.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public 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).