[ESS] Emacs 24, ESS and R/Sweave - 2 changes in behavior from Emacs 23

[Marc Schwartz]

Hi all,

Greetings from useR at Vanderbilt in Nashville.

Having upgraded to Emacs 24 earlier this week, I began to notice some behavioral changes from Emacs 23 when editing Sweave .Rnw files. I spent some time isolating both problems and had the opportunity here to discuss them with Rich Heiberger and Martin Maechler who suggested that I post to the list.

For completeness:

1. Running on a MacBook Pro with fully updated OSX Lion
2. Emacs 23 and 24 binaries from http://emacsformacosx.com/
3. ess-12.04-4
4. auctex-11.86


The first issue, which turns out to be my problem, is that for years, I have had the following Emacs directive at the top of my .Rnw files:

  % -*- mode: noweb; noweb-default-code-mode: R-mode; -*-

Now, in all honesty, I can't for the life of me recall the etiology of this inclusion in my .Rnw templates. I have been using Emacs and Sweave since circa 2003 (R itself since circa 2001). Perhaps some of the grey-haired folks like me whose recollection is better than my own can provide some history, presuming that this was dealing with some multi-mode issues in Emacs.

That all being said, this all worked fine through Emacs versions 21 and 23 on Windows, RH/Fedora Linux and OSX. That changed with 24.

For assistance purposes, if the above line is present, one gets an error message:

  "noweb mode removed"

and noweb font lock mode fails. Took me a while to figure out where that was coming from.

Looks like this message comes from the noweb-mode.el file in ESS AFAICS, around line 491, not from other Emacs sources. So it would seem that something pertaining to noweb mode changed and Martin had suggested that he recalled some recent communications regarding noweb related code in Emacs 24 that might now conflict with the above incantation. In either case, the above causes problems, is no longer needed and perhaps in reality, has not been for some time. 

The second issue, which is a bit more perplexing is a variation on a problem that I have had for some time and I believe others have had as well. The prior issue is that if one includes a "$" in a LaTeX section of the file (eg. DataFrameName$ColumnName), for example within a \Sexpr{} to return a scalar value, the presence of the "$" kills the correct font lock coloration and representations (eg. subscripts, etc.) for text that follows, until a following R code chunk. That issue is easily avoided by having a preceding R code chunk which does the more complicated manipulation of data and assigns that to a scalar, suitably named, that is then included in the \Sexpr{}.

The new behavior in Emacs 24, is that if one includes the "$" in an R code chunk, the following LaTeX content is not correctly represented. In my case, all LaTeX section text turns a brownish color (eg. rather than black) and any other TeX specific font sizes, etc. are lost. For example, create a simple R chunk followed by some LaTeX mode text:

<<>>=
  iris$Species
@

Some LaTeX mode text here


You may have to scroll the cursor through the lines of text to see the effect.

Completely by accident, I found that if one adds a second "$" in that R code chunk (eg. iris$Species$), such that there is now a pair of "$"s, that seems to trigger a correction of the underlying situation and the LaTeX section that follows is correctly colored/represented as it should be. So this is a change in behavior in 24 and seems to suggest that somehow the font lock mode is interpreting the "$"s as an opening and closing pair of some kind of tag. This pairing behavior seems to continue based upon either an odd or even number of "$"s in the R chunk, thus iris$Species$$ fails, iris$Species$$$ succeeds, and so forth.

I am not sure if folks are aware of this second issue with Emacs 24 since the stable release is just out, but wanted to report my observations. As noted, I did not observe this behavior with 23. If you need more information, let me know.

Thanks for taking the time to read this.

Regards,

Marc Schwartz