[ESS] Finding Rterm in R 2.12.0 on Windows

[Paul Johnson]

On Tue, Feb 1, 2011 at 4:34 AM, Martin Maechler
<maechler at stat.math.ethz.ch> wrote:
>>>>>> Dale W Steele <Dale.W.Steele at gmail.com>
>>>>>>     on Tue, 01 Feb 2011 00:26:00 +0000 writes:

>    > One interesting issue. If I open an empty file test.R and
>    > navigate via the ESS menu, Ie. "Start Process:Other and select
>    > the 64 bit version, then the following text appears in the
>    > buffer:
>
>    > "ESS [S(R): C:/Program Files/R/R-2.12.1patched/bin/i386/Rterm.exe] starting data directory?"
>
>    > Although this appears to point to the 32-bit version, the 64-bit
>    > version opens in the R buffer when I hit enter.
>
> Yes. That is actually another glitch, not at all related to
> Windows or even R: Inside "[..]" the S or R version displayed is
> sometimes wrong, i.e. the "previous" version instead of the one
> that will be taken.

I've been watching this thread with interest.  Lately I've installed
Emacs and R on about 15 student computers with various versions of
windows. I've run into all of the various problems described in this
thread.  Emacs/ESS can't find R, etc. There are many ways to break
this chain of tools, some of which we could simplify for the ordinary
average non-computer science grad student.

Here are suggestions I am thinking of making to the R for Windows
packagers. Please tell me what you think:

1. The DEFAULT install path for R should NOT have an R version number
in it. It should only be C:/Program Files/R.  I propose to do that,
either for 64bit or 32bit installs, even on a Win7 system, where the
system seems to prefer to install in C:/Program Files (x86)/R.   For
ordinary users, only one version of R will be desired, and expert
users can add the version number to the path if they want several
installed.

Benefits.  Supposing that the R packaging does not change the location
of Rterm.exe, we can put the right folder in the PATH and forget about
it.  We need either bin (old packaging), or bin/i386 or bin/x64. That
can be added to the system PATH and it will not have to be revised
when R is updated.  And ESS will always be able to find R, since it
will be in the path.

This is a *good thing* because sometimes other programs--not just
Emacs/ESS--will want to run R executables.

2. The update.packages function should default to checkBuilt=T, so
users who update R will, unless they actively resist, get the packages
that match their installation.

The current install path, including the version number, creates a very
confusing scenario for updates of packages.  Did you ever study the R
for Windows FAQ discussion on what a user is supposed to do about the
old lib dir and packages? I'm pretty good at computing and I can
barely figure it out.  By adding checkBuilt=T, we completely eliminate
that problem.

These suggestions bring the Windows install closer to the default
Unix/Linux install. Install R in one place, don't keep version numbers
in the install path, etc.

Well, what do you say?



-- 
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas