2

I have the following Emacs org buffer that I'm editing:

#+BEGIN_SRC R
regimes <- read.spreadsheet(wlda, 3) %>%
    within({
        TurbineID <- paste(Site, Turbine)
        Date.of.Change.of.Risk.Level <- convert.excel.date(Date.of.Change.of.Risk.Level)
        Non.REA <- Non.REA=="Yes"  # Convert to boolean & foo
        X9 <- X10 <- NULL # Trailing columns
    }) %>%
    group_by(Site, Turbine) %>%
    mutate(
        Curtailment.Level.Before = na.locf(Curtailment.Level.Before),
        Curtailment.Level.After  = na.locf(Curtailment.Level.After, fromLast=TRUE)
    )
#+END_SRC

Syntax highlighting (font-lock-mode) is enabled in this buffer.

I hit Meta-x R to start a new R session.

If I then go back to the Org buffer, highlight all the code in the code block, hit Meta-w to grab it, and then move to the R session buffer and yank it (Ctrl-y, which runs ess-yank), Emacs immediately freezes and consumes 100% CPU. None of Ctrl-g, Ctrl-c, or anything else I've tried will interrupt it, I have to actually kill the Emacs process from a shell.

Note that I have not actually tried to execute the R code at this point, it's just been yanked (pasted) into the ESS console buffer.

Anyone help with some debugging here?

My setup:

  • Emacs 24.5.1, installed using homebrew
  • OS X 10.10.5
  • Org-mode 8.3.2, installed using org-plus-contrib 20151228 from ELPA
  • ESS 15.09-2, installed from ELPA 20151217.544

This behavior happens whether I'm using the OS X .app or running in a terminal.

Update

I think this has something to do with syntax highlighting. If I run font-lock-mode to turn off highlighting in my org buffer before I grab the text, the problem disappears. I simplified the example above to reflect this.

Update 2

I triggered this problem in the way described above, then I hit the process with a SIGUSR2 signal and got the following backtrace:

Debugger entered--beginning evaluation of function call form:
* (byte-code "r^Hq\210\302      !\210)\302\207" [buffer table set-syntax-table] 2)
  font-lock-default-fontify-region(802 1304 nil)
  inferior-ess-fontify-region(802 1304 nil)
  font-lock-fontify-region(802 1304)
  run-hook-with-args(font-lock-fontify-region 802 1304)
  #[0 "\302\303\300\242\301\242#\207" [(802) (1304) run-hook-with-args jit-lock-functions] 4 "\n\n(fn)"]()
  funcall(#[0 "\302\303\300\242\301\242#\207" [(802) (1304) run-hook-with-args jit-lock-functions] 4 "\n\n(fn)"])
  jit-lock-fontify-now(802 1302)
  jit-lock-function(802)
  redisplay_internal\ \(C\ function\)()

I notice that the docs of byte-code say "If the third argument is incorrect, Emacs may crash." In this case, the third argument (MAXDEPTH) is passed as 2, perhaps that's the problem?

  • When I do C-c C-c in the first block, it returns the value "2" but does not start a persistent R session. When I start an R session and copy the second block over, I get an error: "could not find function "%>%" – Tyler Dec 30 '15 at 19:28
  • Yes, if you replace 1+1 by 5%>%2 and call C-c C-c you also get could not find function "%>%. I could reproduce your problem. It is not emacs that hangs but R. One time I killed R and sent emacs a QUIT signal per pkill -QUIT emacs. The result was that I got R aborted in the emacs R-shell buffer. But this does not always work. Sometimes emacs just quits also on pkill -QUIT emacs. But, my environment is special with regard of kill. I am working under cygwin. – Tobias Dec 30 '15 at 19:46
  • Those results mean you can't duplicate the problem. In my scenario R is definitely never getting invoked (because yanking into a buffer doesn't run R), so it never has a chance to decide whether %>% is defined or not. In my "full" orgmode file all that stuff is defined, including the functions being called, variables referenced, etc. and the problem is the same. – Ken Williams Dec 30 '15 at 20:21
  • @Tyler - Perhaps you have to run C-c C-c in the header section first to make the config take effect. – Ken Williams Dec 30 '15 at 20:22
  • 2
    github.com/emacs-ess/ESS/issues/123. I had this problem before on both OSX and Ubuntu machines and couldn't find a solution. But there is a better way than copy/past for sending the code to R process, which don't have this hang problem. – yi.tang.uni Jan 1 '16 at 10:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.