I thought I would post an update concerning using ST2 with R in Windows since I have been using the setup exclusively for a couple of weeks now. There are some pros, some cons, and a bug I thought I'd point out. wuub, if you want the bug(s) posted to the Github repo, let me know and I can do that.
- Syntax highlighting (both in .R files and in the REPL window for R). I never realized how awesomely helpful a syntax highlighted R-terminal window would be. It's great.
- Text-file like navigation of the R REPL window. It's helpful (sometimes) to be able to use the arrow keys to navigate through the terminal and terminal output history like it's one big text file. However, this does have some drawbacks
- Numerous other ST2-related benefits. auto-complete, multiple cursors, etc.
- Plotting to multiple windows (vs overwriting the content of a single window) by default
- Launching the R REPL using the current directory as the working directory
Cons *(vs. the classic R GUI)***:**
- No tab-complete in the REPL. Coming from the RGUI, a handy feature for member access is to do something like the following: object$, followed by the tab key which allows for tabbing through the members of the object. This is not unlike tab-complete in any other shell. In an R REPL, however, since the terminal is manipulated like a text file, the tab key works as tab would in a text editor. The same is true for the enter key. So, to run a line, for example, I have to have ensure that the cursor is at the end of the line and then hit Enter. This con is by no means a deal-breaker for me, and in many cases the REPL behaving like a text document is beneficial. It's just something I thought I'd point out if anyone else considers going with the R REPL setup. In short, the REPL acts like a text file, and is therefore not manipulated in the way you intuitively expect command line interpreters to work. Not a bad thing, just takes some getting used to, and some may consider it a con.
- Closing an R REPL tab in ST2 sometimes does not close the RTerm.exe process, leading to running processes that must be killed via Ctrl+alt+del. This isn't a huge hindrance in most cases; however, sometimes the orphaned Rterm.exe process will begin to consume massive amounts of CPU. On my Core2Duo machine for example, the process will consume 50% CPU, dominating a single core. This leads to massive slowdown and, to someone unfamiliar with the issue, can cause quite a bit of frustration since the computer essentially bogs down with no obvious reason. I have verified that this bug exists on multiple machines (all Win 7). Other members of my lab (who have seen firsthand how much better the SublimeREPL approach to R is over the traditional R GUI), have also noticed the issue on their setups, again all Windows 7 machines. I have yet to test if a similar problem arises on OS X, but I can if necessary. Also note that the Rterm.exe process can always be killed effectively (in Windows) using Ctrl+Alt+Del. In Unix-y terms, the process isn't a zombie, just an orphan.
This may just be a general SublimeREPL bug that I'm not familiar with, but I thought I'd point it out in any case.
TL;DR: R + SublimeREPL = happiness, Cons exist but they're minimal when compared to the pros, an orphan process bug within SublimeREPL (when using R) seems to exist.