I started using Emacs (ESS) as a default R editor (yes, #Dirk, as you've said, I want ESS), and I must admit it's by far the best R editor I've been using so far. However, I cannot manage to get an output of help() function up to web browser. It keeps displaying help page in a separate R buffer, even if options(help_type = "html", browser = "firefox") are set.
How can I get help back to browser, while using Emacs/ESS?
I can reproduce this under Linux: If I run R from the terminal, setting options(htmlhelp=TRUE) brings up help in a browser, but it fails from ESS. However,
help("plot",htmlhelp=getOption("htmlhelp"))
works -- help opens in Firefox for me. I think that's an anomalous behavior -- htmlhelp=getOption("htmlhelp") is a default argument for help (see ?help). Could it be a bug?.. A possible workaround is to invoke help via help("plot",htmlhelp=T) directly, or write a wrapper like myhelp <- function(x) help(x,htmlhelp=TRUE).
EDIT: A possible solution: put this into your .emacs
(setq inferior-ess-r-help-command "help(\"%s\", htmlhelp=TRUE)\n")
as per https://stat.ethz.ch/pipermail/ess-debian/2009-October/000093.html. This refers to ESS 5.5; the current one in Ubuntu repositories is 5.4, so I can't test the fix w/o upgrading ESS.
EDIT2: I upgraded to the latest R/ESS as per Dirk's suggestion, and did the following, after launching R/ESS: M-x customize-variable inferior-ess-r-help-command and replaced help_type=text with help_type=html. That fixed things (at least for version 2.10.1/ESS 5.8).
Related
When I open files with emacs it adds 12;rgb:1c1c/1c1c/1c1c on the top. How can I prevent this?
I have installed emacs on a clean reinstalled debian system.
Emacs: GNU Emacs 24.4.1
Terminal Emulator: MobaXterm Personal Edition v7.7
System (local): Windows 7 Ultimate
System (remote): Debian 8.0 "jessie" stable
As noted, "MobaXterm" is not "xterm". According to its webpage it is
Based on PuTTY/MinTTY with antialiased fonts and macro support
Lacking a detailed change history, and the problem reported by the OP, it seems that MobaXterm is based on PuTTY from a while back, and does not implement all of the control sequences which PuTTY does, much less those of xterm.
The particular sequence which is not recognized (referring to XTerm Control Sequences) may be this:
OSC Ps ; Pt ST
OSC Ps ; Pt BEL
...
Ps = 1 2 -> Change text cursor color to Pt.
That is part of a group of controls predating ANSI color support in xterm, referred to as dynamic colors.
Based on comments in other places, it seems that the problem could lie within the OP's Emacs configuration, by using scripts which do an ad hoc test of TERM to decide if it can do colors, rather than inspecting the terminal capabilities. See Terminal emacs colors only work with TERM=xterm-256color where someone worked around this problem by modifying their init.el to add special cases for rxvt and xterm.
Emacs of course is capable of doing colors in different terminals. See emacs colors based on $TERM environment variable for comments. And TERM=xterm on Debian has provided color for quite a while. So in a typical configuration, color should "just work".
However, there are different ways to configure Emacs. Attempting to reuse some 256-color script can fall into the hole dug by developers who assume that every terminal is just like the one in front of them. See the Emacs wiki page X Term Colors for an example.
!! SOLVED IN MOBAXTERM VERSION 8.2 !!
Looks like your terminal settings are out of sync. The settings of your terminal need to agree with the termcap/terminfo settings on the server. Try to set the TERM variable in the shell on the server to a value which better matches the terminal emulation capabilities of your terminal (common values are xterm, xterm-color, vt520, and vt102) or correspondingly change the settings of the terminal to match the current TERM value. (If the terminal is buggy, you may need some trial and error to find a mode which works well for you.)
VT220 works fine; Edit Session / Terminal Settings / Type: vt220
I am developing project in clojure using emacs cider under windows. And sometimes I have a problem that after accidently forgotten println function or on printing contents of big file Emacs stops responding (cursor and all key combinations doesn't work) and retire into oneself for processing that information to show it in repl. The only way to continue I know is to close program and open project files from scratch. And it is so simple to get in this trap.
Are there any other better solutions or configuration restrictions?
Though this suggestion will not solve your problem completely, it can help you a little.
First, set *print-length* to some value to limit the number of items of each collection to be printed.
(set! *print-length* 10)
And use cider-connect instead of cider-jack-in. You should run lein repl in a separate console window, then run cider-connect to connect to the repl. Then you can evaluate some expressions in the console window.
It would be good if there's an option to limit the contents to be printed by number of characters, however, I couldn't find it.
In nREPL, the user could simply C-x C-e to evaluate the preceding form in the running REPL.
However, in Cider, it seems there is only a way to evaluate the form in the echo area or a popup buffer.
Is this really the case?
Please someone correct me, because this is a useful feature to lose.
I'm using nREPL and by default evals to echo area.
If you want to send the C-x C-e output to the running repl you can use both solutions on this question which are working quite fine for me.
I'm cider's maintainer and I can assure you C-x C-e's behaviour hasn't changed in quite some time. I'm also absolutely certain nothing was changed when I renamed nrepl.el to cider some time ago. I'm OK with implementing such feature if you need it, though. Just open a ticket on the issue tracker.
C-c M-e which is bound to cider-eval-last-sexp-to-repl will get the job done. My cider version is 0.16.0.
When I use the slime-repl, I get this message in my minibuffer and emacs hangs for a second:
error in process filter: Wrong type argument: sequencep, :not-available
It stops happening when I turn off slime-autodoc-mode
Has anyone seen that before?
From this error report
joddie commented:
I experienced the same problem. After a cursory
investigation, it seems to be related to enabling the slime-fancy
module in slime/contrib. slime-fancy is a shortcut for enabling a
number of different slime modules, and I'm not sure which one is the
actual source of the problem, but disabling it seems to fix the
problem here at least.
(This is using the latest Git/CVS versions of slime and slime-js,
although I also tried rolling back to the 2010-02-12 version of slime
just in case; it made no difference).
ghost commented: #joddie : I just try it and remove slime-fancy, it
does work. Now I put
(slime-setup '(slime-js slime-repl))
in my .emacs. Before that I can not use auto complete in node even my
tab already bound to slime-indent-and-complete-symbol. Thanks. :)
For those of you using quicklisp and slime-helper to manage their slime setup open quicklisp/slime-helper.el to find the place where (slime-setup) is used.
I'm a relatively new user to R and Emacs and was wondering if Emacs could automatically correct any R commands that i've typed wrong. I know about the alt-/, but I was more thinking along the lines of if i type read.tale, it corrects it to read.table.
Also, I was using emacs the other day and whenever i typed read.table, it showed the usage options (that bit from the help file) in the bottom bit of the window-the minibuffer?. anyway, its not there now, and i don't know what i did to make it go away.
Thanks for your help
Independently of emacs, you can examine your code with the checkUsage function in the codetools package. For example:
> foo <- function(data){
+ read.tale(data,file='temp.txt')
+ }
> checkUsage(foo)
<anonymous>: no visible global function definition for ´read.tale´
Also, you can emacs autocompletion functions (e.g. hippie-expand or dabbrev-expand) to fill in the rest of recently used function and variable names.
If you aint married to emacs, you should give Komodo edit with sciviews-R / sciviews-K a try.
So far it´s the best auto-completion coding I found for R. At least to me the configuration was much easier than emacs, particularly because of binding problems with my exotic (swiss) keyboard. sciviews-R / Komodo
EDIT: I realize this thread is still being read. So in meantinem I got to give it up for RStudio. It has really become THE editor for everyday use for most people. Nice autocompletion, available on all major OS and a really nice context help. Plus some easy export of pdf graphics and much much more. On top R Studio is easy to install – no need to worry how to fire up R from the editor.