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

[Marc Schwartz]

Hi Vitalie,

Thanks. Here is mine:

########################

\documentclass{article}

\begin{document}

<<>>=
  iris$Species
@

Here is some text

\end{document}

########################


Regards,

Marc

On Jun 14, 2012, at 4:00 AM, Vitalie Spinu wrote:

> 
> Thanks for reports. Noweb is inherently broken and will be most likely
> replaced in the next version of ESS. I've already started working on a
> general literate programing frontend,  available here:
> https://github.com/vitoshka/litprog . 
> 
> To avoid repeating mistakes in noweb I would like to have as many self
> contained reproducible examples as I can. So, if you experience problems
> with noweb, please send your snippets to me personally or to this list.
> 
> I can reproduce Carslav's example on emacs 24. Mark, can you please send
> a short self contained file with your problems?
> 
> Thanks, 
> Vitalie.
> 
>>> "Carslaw, David" <david.carslaw at kcl.ac.uk>
>>> on Wed, 13 Jun 2012 21:40:41 +0100 wrote:
> 
>> Thanks Marc.  I too have related problems that would seem a good time to mention (using Vincent Goulet's latest release for Windows based on emacs 24.1).
>> Given a minimal example like this:
> 
>> #############################################
>> \documentclass{article}
> 
>> King's College London
> 
>> \begin{document}
>> <<>>=
>> test <- data.frame(x = 1:3, y = 1:3)
>> @
>> \end{document} 
>> ##############################################
> 
>> The R code is shown as a string face (M-x Describe-face) and ends up like this
>> because of the ' in King's.  I think there are other issues with constructs like
>> the quotes using backticks e.g. `backtick', which also affects fontification.
>> These issues are not present in the emacs 23.4 I was previously using.
> 
>> All the best 
> 
>> David Carslaw
> 
>> -----Original Message-----
>> From: ess-help-bounces at r-project.org [mailto:ess-help-bounces at r-project.org] On Behalf Of Marc Schwartz
>> Sent: 13 June 2012 21:21
>> To: ESS-help
>> Subject: [ESS] Emacs 24, ESS and R/Sweave - 2 changes in behavior from Emacs 23
> 
>> 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