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?
1+1
by5%>%2
and callC-c C-c
you also getcould 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 perpkill -QUIT emacs
. The result was that I gotR aborted
in the emacs R-shell buffer. But this does not always work. Sometimes emacs just quits also onpkill -QUIT emacs
. But, my environment is special with regard of kill. I am working under cygwin. – Tobias Dec 30 '15 at 19:46%>%
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:21C-c C-c
in the header section first to make the config take effect. – Ken Williams Dec 30 '15 at 20:22