I just ran into this problem. It is caused by the calls to ‘org-babel-import-elisp-from-file’ on lines 310 and 343 of ‘ob-R.el’ (for non-session and session code blocks respectively). I determined this by setting ‘debug-on-quit’ to t in Emacs, then hitting C-g when cpu usage spiked, and examining the backtrace.
It seems like Emacs tries to read in the last value of the R command, to print it in the minibuffer. It gets bogged down doing so. As a stopgap, putting NULL as the last line of the source block fixes the problem (the value “returned” by the block is just NULL). I believe setting “:results output” (as opposed to “value”) would also make the bug disappear, since the output will be very small. This is likely what made cberry’s test differ from John’s. I’m not sure what the right strategy would be for a fix. Two ideas would be: 1) adding a sanity check to o-b-import-elisp-from-file, which asks the user whether to really import very large files (or just ignores such files) 2) adding a new :results handling header arg “really-silent” (probably with a better name...) that discards the result entirely, not even printing it to the minibuffer. -- Aaron Ecay
