The change in date format makes sense. The short term workaround is to set the
specific R you want.
In general, that ESS code on Windows was designed to find R in any of a number
of standard places. The list of what
those standard places are is also a variable you can set. The details have
been changed since I wrote it, so someone
more current will need to verify and modify the code.
From: ESS-help on behalf of Kevin R. Coombes
Date: Wednesday, July 13, 2022 at 11:16
To: Shreyas Ragavan
Subject: [External] Re: [ESS] ESS confused about newest R
I think I have found the offending code in "ess-r-mode.el". The critical
function appears to be "ess-r-version-date". This function actually runs
the Rterm.exe for each version of R (who knew?) that it located, using
the "--version" command line argument. It then parses the version line
to find the actual release date. Starting with R-4.2.0 (at least on
Windows), that line has changed from the previous form:
R version 4.1.0 (2021-05-18) -- "Camp Pontanezen"
to something like:
R version 4.2.0 (2022-04-22 ucrt) -- "Vigorous Calisthenics"
Note in particular the extra " ucrt" in the parenthetical display of the
date. I strongly suspect that the regexp being used to parse the date
fails to recognize this new form.
I am also 100% certain that I cannot rewrite the regexp to work in this
setting without breaking something else, since it is carefully and
complexly designed to parse *all* of the version-date lines going back
to R 1.0.1.
To whom and where should I report this as a bug in order to encourage
one of the ESS gurus to see if my conjectured explanation of the bug is
correct and (I hope) manage to fix it?
On 6/29/2022 1:24 PM, Kevin R. Coombes wrote:
> I just installed the latest emacs (28.1) and used MELPA to install the
> latest version of ESS (20220621). With this new setup, I still have
> the same problem. ESS/R finds all versions of R on my system, and
> generates separate commands for each one (including the newest,
> R-4.2.1-64bit. However, R-newest thinks that the newest version I have
> is R-4.1.0, and so the command "M-x R" starts the 64bit version of
> To test my hypothesis that this has something to do with 32-bit vs
> 64-bit, I tried the following experiment. I created a folder
> "bin/i386" inside my R 4.2.1 installation, and copied R.exe and
> Rterm.exe from the R-4.1.0 installation into that folder. Now when I
> try to run R, it finds both the real R-4.2.1-64bit and my fake
> R-4.2.1-32bit. But (damnit) it still runs R-4.1.0 as though it were
> the newest version. So, I have no idea if 32bit is a red herring or
> not, and I am mightily confused about why ESS doesn't seem to like
> On 6/29/2022 11:18 AM, Kevin R. Coombes wrote:
>> To clarify, I don't ever start R (as Rterm) from a command line
>> prompt on Windows. As a result, I really don't bother to put the R
>> installation location into the PATH environment variable, since I
>> don't want to have to update it every time a new version is released.
>> (For the same reason, I don't want to have to manually set
>> "inferior-ess-r-program" and have to remember to update it with new
>> I have desktop icons for the RGui. I can see the version number and
>> name on those icons if I want to start R that way; those all work. I
>> also have no problem using RStudio, which continues to be successful
>> in automatically finding the newest versions. The only problem is
>> with ESS inside of emacs, and it started with version 4.2.0, which
>> coincided with dropping the creation of 32-bit R versions on Windows.
>> Further, ESS/R does *find *all versions of R on my system. I know
>> this because it creates separate startup commands (such as
>> R-4.2.0-64bit). That part that fails is the code in the file
>> "ess-r-mode.el" that is supposed to find the newest R from the list
>> of all available versions.
>> On 6/29/2022 9:57 AM, Shreyas Ragavan wrote:
>>> I wanted to add a suggestion here that when or if you add multiple R
>>> versions from non-standard paths to your PATH environment variable in
>>> Windows (to enable Emacs or any program to find the R executable) - it is
>>> important to make sure the desired version of R is the First path. Programs
>>> will stop looking for the executable once it is found, and if an earlier R
>>> version is found before the desired version - that is what would start up.
Your (from description) Windows system appears confused about where to find
R, and doubly so as a 32/64 bit convention is dead, and there is only
On operating systems that use $PATH you can _always_ just point to a
R by pointing RHOME/bin so that the right R is found. It has been years
I worked on Windows but it got the R I wanted when I told ESS in no