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

["Thomas S. Dye" <tsd@tsdye.com>]

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 <tsd@tsdye.com> 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