Re: [Orgmode] Re: eval: Invalid read syntax: "#"Error during redisplay: (void-function -mode)
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 ___ 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
Re: [Orgmode] Re: eval: Invalid read syntax: "#"Error during redisplay: (void-function -mode)
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) ___ 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
Re: [Orgmode] Re: eval: Invalid read syntax: "#"Error during redisplay: (void-function -mode)
Sorry Seb, I typed carelessly. The variable is org-src-tab-acts- natively. Tom On Dec 11, 2010, at 2:03 PM, Sébastien Vauban wrote: Footnotes: [1] Did not know about `org-src-tabify-natively'... Though, it does not exist (as variable) on my current git system!? ___ 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
[Orgmode] Re: eval: Invalid read syntax: "#"Error during redisplay: (void-function -mode)
Hi Thomas and Nick, Nick Dokos wrote: > Thomas S. Dye wrote: >> Thanks for looking into this. I pulled as you suggested and now get >> consistent version strings. I'm pleased that we share a solution to that >> inconsistency. Thanks! Good start. >> The other problem persists. I put the example in its own buffer and was >> able to export the entire buffer without problem. Idem. >> 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. >> >> Also, I followed your lead and switched off org-src-fontify-natively and >> org-src-tabify-natively, but neither of these made the error go away. > > Argh - I missed the subtree part in your OP. I can reproduce the problem > when I try to export the subtree, just as you describe. With my same old good settings (no native fontification[1]) and the same example I used a couple of hours ago, yes, I can reproduce your problem. I wasn't aware you talked of subtree export (read too quickly, maybe). So, export of whole buffer is OK. But export of subtree gives the exact same error string as in your subject. So, we're now 3 getting the same problem.[2] Best regards, Seb Footnotes: [1] Did not know about `org-src-tabify-natively'... Though, it does not exist (as variable) on my current git system!? [2] Regarding the previous error I had (described in a previous thread), that was when exporting the whole buffer, as I do 99% of the time. I almost never use subtree export, hence my (too) optimistic first answer on your problem. -- Sébastien Vauban ___ 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
Re: [Orgmode] Re: eval: Invalid read syntax: "#"Error during redisplay: (void-function -mode)
[Double argh: I forgot to copy the list...] Thomas S. Dye wrote: > Aloha Seb, > > Thanks for looking into this. I pulled as you suggested and now get > consistent version strings. I'm pleased that we share a solution to > that inconsistency. Thanks! > > 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. > > Also, I followed your lead and switched off org-src-fontify-natively > and org-src-tabify-natively, but neither of these made the error go > away. > Argh - I missed the subtree part in your OP. I can reproduce the problem when I try to export the subtree, just as you describe. Nick ___ 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
Re: [Orgmode] Re: eval: Invalid read syntax: "#"Error during redisplay: (void-function -mode)
Aloha Seb, Thanks for looking into this. I pulled as you suggested and now get consistent version strings. I'm pleased that we share a solution to that inconsistency. Thanks! 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. Also, I followed your lead and switched off org-src-fontify-natively and org-src-tabify-natively, but neither of these made the error go away. All the best, Tom On Dec 11, 2010, at 10:26 AM, Sébastien Vauban wrote: Hi Thomas, Nick and others, "Thomas S. Dye" wrote: On Dec 10, 2010, at 8:15 AM, Nick Dokos wrote: Thomas S. Dye wrote: So, Seb and I have two things that others can't reproduce: the error in the OP, and the version string for the latest Org-mode. Let's say it's an honor to share things with you ;-) I'm using Org-mode version 7.3 (release_7.4.2.g32f816.dirty) First, regarding the string problem, as just reported, that has been fixed. Org-mode version 7.4 (release_7.4.6.g561c0) I get subject error when exporting this subtree to LaTeX: * Export problem #+begin_src emacs-lisp :results wrap :exports both "code block results" #+end_src #+begin_src emacs-lisp :var lst=a-list :results list (reverse lst) #+end_src The error goes away and LaTeX export succeeds if I get rid of the :exports header argument in the first source block, or get rid of the second code block. This sounds suspiciously like something that Seb ran into a few weeks ago: http://thread.gmane.org/gmane.emacs.orgmode/33922 but I'm not sure how that was resolved. I cannot really say it has been resolved. It simply disappeared after I came back to a more standard version. I had applied a couple of patches from Eric (Org RESULT block) and Dan (fontification minibug), and just git pulled to come back to the master branch. After that, and with no native fontification anymore[1], it did not occur again. But I don't think it has been solved. Simply it occurs in particular contexts. FWIW, I cannot reproduce it: I did export the above both to HTML and PDF with no problem. First code block is run, and results exported; second simply exported. Sorry. Do you still have the problem with current current current git? No sandbox with extra patches? Best regards, Seb Footnotes: [1] "No native fontification" is still my current standard, among others because of the fontification minibug -- not yet applied by Dan --, and because I need more visibility of code blocks inside the prose -- see my patch, not yet accepted, and hopefully other coming patches to add new faces to the Babel lines). -- Sébastien Vauban ___ 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 ___ 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
[Orgmode] Re: eval: Invalid read syntax: "#"Error during redisplay: (void-function -mode)
Hi Thomas, Nick and others, "Thomas S. Dye" wrote: > On Dec 10, 2010, at 8:15 AM, Nick Dokos wrote: >> Thomas S. Dye wrote: > So, Seb and I have two things that others can't reproduce: the error in the > OP, and the version string for the latest Org-mode. Let's say it's an honor to share things with you ;-) >>> I'm using Org-mode version 7.3 (release_7.4.2.g32f816.dirty) First, regarding the string problem, as just reported, that has been fixed. Org-mode version 7.4 (release_7.4.6.g561c0) >>> I get subject error when exporting this subtree to LaTeX: >>> >>> * Export problem >>> >>> #+begin_src emacs-lisp :results wrap :exports both >>> "code block results" >>> #+end_src >>> >>> #+begin_src emacs-lisp :var lst=a-list :results list >>> (reverse lst) >>> #+end_src >>> >>> The error goes away and LaTeX export succeeds if I get rid of the :exports >>> header argument in the first source block, or get rid of the second code >>> block. >> >> This sounds suspiciously like something that Seb ran into a few weeks ago: >> >> http://thread.gmane.org/gmane.emacs.orgmode/33922 >> >> but I'm not sure how that was resolved. I cannot really say it has been resolved. It simply disappeared after I came back to a more standard version. I had applied a couple of patches from Eric (Org RESULT block) and Dan (fontification minibug), and just git pulled to come back to the master branch. After that, and with no native fontification anymore[1], it did not occur again. But I don't think it has been solved. Simply it occurs in particular contexts. >> FWIW, I cannot reproduce it: I did export the above both to HTML and PDF with no problem. First code block is run, and results exported; second simply exported. Sorry. Do you still have the problem with current current current git? No sandbox with extra patches? Best regards, Seb Footnotes: [1] "No native fontification" is still my current standard, among others because of the fontification minibug -- not yet applied by Dan --, and because I need more visibility of code blocks inside the prose -- see my patch, not yet accepted, and hopefully other coming patches to add new faces to the Babel lines). -- Sébastien Vauban ___ 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
Re: [Orgmode] Re: eval: Invalid read syntax: "#"Error during redisplay: (void-function -mode)
Bernt Hansen wrote:
> "Thomas S. Dye" writes:
>
> > So, Seb and I have two things that others can't reproduce: the error
> > in the OP, and the version string for the latest Org-mode.
> >
> >>>
> >>> I'm using Org-mode version 7.3 (release_7.4.2.g32f816.dirty)
> >>>
> >>
> >>
> >> FWIW, I cannot reproduce it:
> >>
> >> 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.5.gb0844.dirty)
>
> The version string problem is reproducible. At commit 32f816 (2 commits
> after the release_7.4 tag) the version number is 7.3 even though it is
> after the release_7.4 tag.
>
> In b0844 (5 commits after the release_7.4 tag) this problem has been
> fixed which is why Nick doesn't see it.
>
I was really talking about the latex-export/eval problem that Tom is
seeing, not the version string problem.
Speaking of the eval problem, I notice in the backtrace[fn:1] that Tom
posted that org-babel-exp-src-blocks is called with
"#+end_src\n#+begin_src emacs-lisp :var lst=a-list :results list" as
argument:
org-babel-exp-src-blocks(#("#+end_src\n#+begin_src emacs-lisp :var lst=a-list
:results list" ...)
But when I latex-export the same blocks through my setup (I edebug
org-babel-exp-src-blocks and when it stops, I evaluate the variable
``body''), org-babel-exp-src-blocks is called twice with the *body* of
each of the blocks as argument:
o the first time I get: #("\"code block results\"" 0 20 (fontified nil
font-lock-fontified t))
o the second time I get: #("(reverse lst)" 0 13 (fontified nil
font-lock-fontified t))
So it looks as if the parsing somehow gets out of sync in Tom's case,
but I don't understand why or how. In my case, the latex export goes
through with no problems.
Nick
Footnotes:
[fn:1] A backtrace of Tolstoian proportions...
___
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
[Orgmode] Re: eval: Invalid read syntax: "#"Error during redisplay: (void-function -mode)
"Thomas S. Dye" writes: > So, Seb and I have two things that others can't reproduce: the error > in the OP, and the version string for the latest Org-mode. > >>> >>> I'm using Org-mode version 7.3 (release_7.4.2.g32f816.dirty) >>> >> >> >> FWIW, I cannot reproduce it: >> >> 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.5.gb0844.dirty) The version string problem is reproducible. At commit 32f816 (2 commits after the release_7.4 tag) the version number is 7.3 even though it is after the release_7.4 tag. In b0844 (5 commits after the release_7.4 tag) this problem has been fixed which is why Nick doesn't see it. HTH, Bernt ___ 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
