[ESS] Weird behaviour of assignment symbols with Emacs-24.1 (and ESS 12.04-4)
John Maindonald
john.maindonald at anu.edu.au
Sat Jun 16 02:57:04 CEST 2012
I've reverted to the previous build, with Emacs 23.4 and ESS 12.04-3.
The assignment symbol ('<-') again displays as it should. Several
further points:
1) I have not tried the result from installing ESS 12.04-4 into a 23.4
Vincent Goulet build. It is not clear to me how one would do this.
2) I moved my .emacs aside, with the Emacs 24.1 build. The
assignment symbol was as before not displayed.
3) If (with the 24.1 build) I delete where the '-' should be from
'<-', the '<' is shown.
4) One could of course give up on '<-' and use '=' for assignments.
It would go against the grain to do that.
John Maindonald email: john.maindonald at anu.edu.au
phone : +61 2 (6125)3473 fax : +61 2(6125)5549
Centre for Mathematics & Its Applications, Room 1194,
John Dedman Mathematical Sciences Building (Building 27)
Australian National University, Canberra ACT 0200.
http://www.maths.anu.edu.au/~johnm
On 16/06/2012, at 10:26 AM, Chris Howden wrote:
> Hi John,
>
> I'm experiencing some 'weird' behaviour on a new emacs 24.1 installation
> as well (using Vincent's package). I posted last week about it.
>
> I'm currently flat chat getting an analysis done for a client with a
> Monday deadline.
>
> But when I have some time next week I'm going to have a look at some LISP
> links I was kindly referred to, and also try installing a 23.3.1 build
> from Vincent's archives. This is the build I have on my previous computer
> and it works great. This way I can determine if it's the new build or my
> new computer.
>
> I'll report back to the list once I've had time to do it
>
> Chris Howden B.Sc. (Hons) GStat.
> Founding Partner
> Evidence Based Strategic Development, IP Commercialisation and Innovation,
> Data Analysis, Modelling and Training
> (mobile) 0410 689 945
> (fax) +612 4782 9023
> chris at trickysolutions.com.au
>
>
>
>
> Disclaimer: The information in this email and any attachments to it are
> confidential and may contain legally privileged information. If you are
> not the named or intended recipient, please delete this communication and
> contact us immediately. Please note you are not authorised to copy, use or
> disclose this communication or any attachments without our consent.
> Although this email has been checked by anti-virus software, there is a
> risk that email messages may be corrupted or infected by viruses or other
> interferences. No responsibility is accepted for such interference. Unless
> expressly stated, the views of the writer are not those of the company.
> Tricky Solutions always does our best to provide accurate forecasts and
> analyses based on the data supplied, however it is possible that some
> important predictors were not included in the data sent to us. Information
> provided by us should not be solely relied upon when making decisions and
> clients should use their own judgement.
>
> -----Original Message-----
> From: ess-help-bounces at r-project.org
> [mailto:ess-help-bounces at r-project.org] On Behalf Of
> ess-help-request at r-project.org
> Sent: Friday, 15 June 2012 8:00 PM
> To: ess-help at r-project.org
> Subject: ESS-help Digest, Vol 112, Issue 24
>
> Send ESS-help mailing list submissions to
> ess-help at r-project.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://stat.ethz.ch/mailman/listinfo/ess-help
> or, via email, send a message with subject or body 'help' to
> ess-help-request at r-project.org
>
> You can reach the person managing the list at
> ess-help-owner at r-project.org
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of ESS-help digest..."
>
>
> Today's Topics:
>
> 1. Re: Emacs 24, ESS and R/Sweave - 2 changes in behavior from
> Emacs 23 (Marc Schwartz)
> 2. Weird behaviour of assignment symbols with Emacs-24.1 (and
> ESS 12.04-4) (John Maindonald)
> 3. Weird behaviour of assignment symbols with Emacs-24.1 (and
> ESS 12.04-4) (John Maindonald)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 14 Jun 2012 06:28:45 -0500
> From: Marc Schwartz <marc_schwartz at me.com>
> To: Vitalie Spinu <spinuvit at gmail.com>
> Cc: ESS-help <ess-help at stat.math.ethz.ch>
> Subject: Re: [ESS] Emacs 24, ESS and R/Sweave - 2 changes in behavior
> from Emacs 23
> Message-ID: <CE2C41C9-3F2B-409F-BC2C-8D63C7978D96 at me.com>
> Content-Type: text/plain; charset="US-ASCII"
>
> 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
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 14 Jun 2012 22:27:25 +1000
> From: John Maindonald <john.maindonald at anu.edu.au>
> To: <ess-help at stat.math.ethz.ch>
> Subject: [ESS] Weird behaviour of assignment symbols with Emacs-24.1
> (and ESS 12.04-4)
> Message-ID: <65323BEF-BA47-42BB-AF36-890F0AFA26F9 at anu.edu.au>
> Content-Type: text/plain; charset="us-ascii"
>
> I have just now installed Vincent Goulet's latest
> Emacs-24.1-modified-1.dmg for MacOS X, dated 11 June 2012.
>
> If I type
> a <- 2
> into my R session, the assignment symbol promptly changes to blank space.
> Once the command has been executed, the symbol reappears. This behaviour
> happens whether the symbol is entered as <-, or by typing an underscore.
>
> If I open a .R script file, the assignment symbols likewise appear as
> blank space.
> If I copy relevant code e.g. into this email message, the assignment
> symbols magically reappear. Thus, the issue seems to be one of displaying
> the symbol.
>
> Has anyone else experienced this behaviour? I am guessing that something
> in my .emacs file may be interacting with some feature of Emacs 24.1 to
> cause the problem. Any suggestions on what I might check for?
>
> John Maindonald email: john.maindonald at anu.edu.au
> phone : +61 2 (6125)3473 fax : +61 2(6125)5549
> Centre for Mathematics & Its Applications, Room 1194, John Dedman
> Mathematical Sciences Building (Building 27) Australian National
> University, Canberra ACT 0200.
> http://www.maths.anu.edu.au/~johnm
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 14 Jun 2012 22:33:30 +1000
> From: John Maindonald <john.maindonald at anu.edu.au>
> To: <ess-help at stat.math.ethz.ch>
> Subject: [ESS] Weird behaviour of assignment symbols with Emacs-24.1
> (and ESS 12.04-4)
> Message-ID: <317BAF0B-0C5E-4B5D-9EDB-2A7BAF548397 at anu.edu.au>
> Content-Type: text/plain; charset="us-ascii"
>
> PS: I forgot to mention. I am using MacOS 10.7.4
>
> I have just now installed Vincent Goulet's latest
> Emacs-24.1-modified-1.dmg for MacOS X, dated 11 June 2012.
>
> If I type
> a <- 2
> into my R session, the assignment symbol promptly changes to blank space.
> Once the command has been executed, the symbol reappears. This behaviour
> happens whether the symbol is entered as <-, or by typing an underscore.
>
> If I open a .R script file, the assignment symbols likewise appear as
> blank space.
> If I copy relevant code e.g. into this email message, the assignment
> symbols magically reappear. Thus, the issue seems to be one of displaying
> the symbol.
>
> Has anyone else experienced this behaviour? I am guessing that something
> in my .emacs file may be interacting with some feature of Emacs 24.1 to
> cause the problem. Any suggestions on what I might check for?
>
> John Maindonald email: john.maindonald at anu.edu.au
> phone : +61 2 (6125)3473 fax : +61 2(6125)5549
> Centre for Mathematics & Its Applications, Room 1194, John Dedman
> Mathematical Sciences Building (Building 27) Australian National
> University, Canberra ACT 0200.
> http://www.maths.anu.edu.au/~johnm
>
>
>
> ------------------------------
>
> _______________________________________________
> ESS-help mailing list DIGESTED
> ESS-help at r-project.org
> https://stat.ethz.ch/mailman/listinfo/ess-help
>
>
> End of ESS-help Digest, Vol 112, Issue 24
> *****************************************
More information about the ESS-help
mailing list