[ESS] ESS confused about newest R

[Kevin R. Coombes]

Follow-up:

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 R-4.1.0.

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 R-4.2.1.

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 
> releases.)
>
> 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 64bit.
>>>
>>> On operating systems that use $PATH you can _always_ just point to a working
>>> R by pointing RHOME/bin so that the right R is found. It has been years since
>>> I worked on Windows but it got the R I wanted when I told ESS in no uncertain
>>> terms which one I wanted. It seems to me you would be well advised to try the
>>> same if you have confusing choice of multiple R versions to confuse ESS with.
>

	[[alternative HTML version deleted]]