Re: [Orgmode] [BABEL] html export for R not working, but for sh and others

[Eric Schulte]

Hi Rainer,

My guess would be that the `htmlize-buffer' command which is used to
fontify code in html export is choking because the elisp below is
defining new fonts for R code.  If htmlize-buffer can't find the
definitions for these fonts then it will throw an error.

I'm not sure what the solution would be, but I'm pretty sure that's the
source of the problem.

Best -- Eric

Rainer M Krug <address@hidden> writes:

> Hi Eric
>
> I traced the problem to the following section in my emacs.org file:
>
> * Syntax highlighting for functions in R
>   based on https://mail.google.com/mail/#label/Lists%2FESS/125131ed24688970
>   The following code needs to be run in R:
>
>   obj <- do.call("c", sapply(c("package:base", "package:stats",
>   "package:utils"), objects, all.names=TRUE))
>   re <- "(^[^.[:alpha:][:digit:]]|<-|__)"  # to remove "weird" functions
>   obj <- obj[-grep(re, obj)]
>   fpath <- file.path(Sys.getenv("HOME"), ".emacs.d", "R-function-names.txt")
>   write.table(obj, fpath, quote=FALSE, row.names=FALSE, col.names=FALSE)
>
>   Read a whole file into list of lines
>   Author: Xah Lee
>   see http://xahlee.org/emacs/elisp_process_lines.html
> #+begin_src emacs-lisp
>   (defun read-lines (file)
>   "Return a list of lines in FILE."
>   (with-temp-buffer
>   (insert-file-contents file)
>   (split-string
>   (buffer-string) "\n" t)
>   )
>   )
>
>   (add-hook 'ess-mode-hook
>   '(lambda()
>   (setq ess-my-extra-R-function-keywords
>   (read-lines "~/.emacs.d/R-function-names.txt"))
>   (setq ess-R-mode-font-lock-keywords
>   (append ess-R-mode-font-lock-keywords
>   (list (cons (concat "\\<" (regexp-opt
>   ess-my-extra-R-function-keywords 'enc-paren) "\\>")
>   'font-lock-function-name-face))))))
>
> If I disable that section, it works. Do you have any ideas if it could be
> changes? I don't know anything about emacs-lisp.
>
> Thanks,
>
> Rainer
>
> On Fri, Jul 2, 2010 at 9:44 AM, Rainer M Krug <address@hidden> wrote:
>
>>
>>
>> On Thu, Jul 1, 2010 at 5:55 PM, Eric Schulte <address@hidden>wrote:
>>
>>> Hi Rainer,
>>>
>>
>> Hi Eric,
>>
>>
>>>
>>> Rainer M Krug <address@hidden> writes:
>>>
>>> > Hi
>>> >
>>> > I am trying to export the attached test.org file to HTML, but I can
>>> only
>>> > export it, when I change the source block language to anything different
>>> > from R.
>>> >
>>> > I also attach my emacs.org file, but I am not doing any customisations
>>> to R.
>>> >
>>>
>>> I've just started up a minimal Emacs instance and loaded the babel
>>> portion of your attached config, but I am able to export your attached
>>> org file w/o error.  A couple of questions.
>>>
>>> 1) are you able to export to latex?  If so, then maybe the issue has to
>>>   do with fontification of R code by htmlize-buffer
>>>
>>
>> Yes - export to latex (and from there to pdf) are working.
>>
>>>
>>> 2) could you send in the actual error being reported by Emacs, or a
>>>   stack trace?
>>>
>> These are the messages in emacs:
>>
>> Select command:
>> Exporting...
>> org-babel-exp processing...
>> Fontifying  *temp*... (regexps.............)
>> org-babel-exp processing...
>> font-lock-fontify-keywords-region: Invalid regexp: "Regular expression too
>> big"
>>
>> How can I get a stack trace?
>>
>> One more thing: if I start emacs with the -Q option, it works. So I assume
>> it is something in my emacs.org file. What is the easiest way to avoid
>> that source blocks under a heading in the emacs.org file are executed?
>>
>>
>>> >
>>> > In addition: if I specify :session *R* in #:BABEL: , the code is
>>> > evaluated, even though I specified :exports code. Is this intended?
>>> >
>>>
>>> Yes, this is for Sweave like behavior.
>>>
>>> If you have a session specified for every block in the buffer, and you
>>> are exporting the buffer, there are cases when you need a block to be
>>> executed (e.g. because it sets the value of a variable used by a
>>> subsequent block) even though you *do not* want the results of the block
>>> included in the final document.  To support these use cases, on export
>>> every block with a session is executed so that it's effects on the
>>> persist session takes place.
>>>
>>
>> OK - that makes sense.
>> If you need any further info, please let me know.
>>
>> Thanks,
>>
>> Rainer
>>
>>>
>>> Cheers -- Eric
>>>
>>> >
>>> > Thanks,
>>> >
>>> > Rainer
>>>
>>
>>
>>
>> --
>> NEW GERMAN FAX NUMBER!!!
>>
>> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
>> UCT), Dipl. Phys. (Germany)
>>
>> Centre of Excellence for Invasion Biology
>> Natural Sciences Building
>> Office Suite 2039
>> Stellenbosch University
>> Main Campus, Merriman Avenue
>> Stellenbosch
>> South Africa
>>
>> Cell:           +27 - (0)83 9479 042
>> Fax:            +27 - (0)86 516 2782
>> Fax:            +49 - (0)321 2125 2244
>> email:          address@hidden
>>
>> Skype:          RMkrug
>> Google:         address@hidden
>>
>>