[ESS] ESS in Windows: Unable to run editor "gnuclient.exe"

Martin Maechler maechler at stat.math.ethz.ch
Thu Mar 3 09:04:23 CET 2011

>>>>> Joshua Wiley <jwiley.psych at gmail.com>
>>>>>     on Tue, 1 Mar 2011 23:03:47 -0800 writes:

    > Hi Paul, I could be way off target of what was meant, but
    > I think this from within Emacs will produce similar
    > results to fix (at least, it is how I tinker with
    > functions, I'm absolutely open to learning):

    > C-c C-d [name of object] <RET> ## make whatever edits you
    > want C-c C-l <RET> ## to load the file

    > In my opinion this works quite nicely when you have the
    > screen split.  It just opens a new buffer in whatever is
    > opposite the R one, you can see everything, make changes,
    > load it, make more changes, (re)load it, etc.  I am pretty
    > sure it is always assigned in the global environment
    > (which might sometimes cause problems??), but I think
    > fix() does the same thing.

    > Cheers,

    > Josh

Thank you, Josh.

Yes, indeed,  using  C-c C-d  ---if you really must *) ---
has been the reason why I have never ever used 
fix() or edit()..

*)- I typically always get/find the source *.R 
    file and rather edit that inside emacs
 ((Yes, I download all CRAN packages in source from, unpack and install,
   and keep the unpacked package source directories; as R Core
   member, I use the source *.R files for R itself anyway, of course..))

    > On Tue, Mar 1, 2011 at 10:40 PM, Paul Johnson
    > <pauljohn32 at gmail.com> wrote:
    >> Hello, Rich:
    >> I'm very happy to get such a quick answer.
    >> On Tue, Mar 1, 2011 at 10:45 PM, Richard M. Heiberger
    >> <rmh at temple.edu> wrote:
    >>> Paul,
    >>> you hit two issues.
    >>> 1. ESS by default finds R automatically when R is
    >>> installed in the standard places defined by R-Core which
    >>> are (in English locales, it also does the right thing in
    >>> other languages) c:/Program Files/R/R-*/ When you place
    >>> R in a non-standard place such as c:/Program Files/R/, a
    >>> workaround like the one that you used is necessary.  It
    >>> would be better to put that statement   (setq-default
    >>> inferior-R-program-name "c:/Program
    >>> Files/R/bin/i386/rterm.exe") in your .emacs, rather than
    >>> make changes to ess-site.el.  This type of workaround is
    >>> illustrated in ess-site.el.
> OK, well at least I know I inflicted it on myself.  On this
    >> one, I think I'm right and the world is wrong.
    >> R Core doesn't ask for version specific installation
    >> folders on Unix or Mac.   Why Windows? With the most
    >> elementary users being clustered in Windows systems, the
    >> accumulation of multiple editions of R is a support
    >> hassle. Only experts want multiple versions, and they
    >> could get that for themselves at install time if they
    >> wanted it.
    >> But I've lost that argument a lot of times.
    >>> 2. The gnuclient issue.  We have gnuclient hardwired in
    >>> the code for Windows.  The newer emacs distributes with
    >>> emacsclient.
    >>> You can manually issue the command to R,
    >>>    options(STERM='iESS', editor='emacsclientw.exe')
    >>> I don't like emacsclient as much as I liked gnuclient. 
    >>> If you still have an old gnuclient on your machine you
    >>> can use it by starting it in your .emacs file.
> I never heard of "gnuclient" before, don't know what its for,
    >> but I'm sorry I don't have it :)
    >>> ESS intercepts R page() commands at the command line and
    >>> open them in emacs.  That is somewhat easier since the
    >>> pager doesn't have a return value.
    >>> It is not obvious to me why you would want to use the R
    >>> fix() or edit() command when you are working in the
    >>> emacs environment.
> Insert "browser()"!  You already knew, I'm sure, but I just
    >> learned this.  To me it is quite fantastic. In R
    >> Extensions manual, it describes ability to insert
    >> "browser()" into code for existing functions.  To test, I
    >> did it to famous ones
    >>> fix (lm)
    >> and, sure enough, I can edit the *actual code* of the lm
    >> function, put browser() in, close the editor, run the
    >> function, and then *really learn* something. But now, it
    >> seems quite awesome to me. Its like gdb on super
    >> steriods.  Its about the most obvious benefit of "R is an
    >> interpreted language" that I've ever seen.  To stop a
    >> function from a famous package, and then interact with
    >> its variables?  Too cool.
    >> I need this to "just work" in the Windows lab.  It does
    >> in Linux. But in Windows, well, frustrating. I don't mind
    >> having to use windows notepad to do the editing, I just
    >> need this to work without users having to run
    >>> options (editor="whatever")
    >> That's a deal killer.
    >> Couldn't you change from 'gnuclient' to 'notepad'?  we
    >> are sure that exists everywhere.
    >> Couldn't you set it to "runemacs.exe". I don't mind if
    >> another instance gets spawned.  I don't mind starting the
    >> server, if necessary, as long as I can configure it so
    >> users never see it.
    >> Anyway,
    >> I figured, "Why not edit Rprofile.site?".  Users will
    >> never have to worry about it.   But Emacs/ESS ignores
    >> Rprofile.site?   If I set the editor "notepad" in there,
    >> that will fix it.  But no! When I'm in ordinary R (not
    >> via ESS), then options("editor") shows notepad and it
    >> uses it for functions.  But when I start Emacs/Ess,
    >> options("editor") still says "gnuclient.exe".
    >> Until now, I couldn't understand why there's so much push
    >> for Windows people to use "Tinn-R".
    >> Check out the R for beginners by Zuur from Springer
    >> publications, or Maindonald's notes "Installation of R,
    >> of R packages, and Editor Environments"
    >>  http://maths.anu.edu.au/~johnm/r-book/xtras/setup.pdf.
    >> I don't want Windows people to get "stuck" to their OS by
    >> Windows-only solutions, that's why I make them all try to
    >> use Emacs, even though the've never edited a file before
    >> :)
    >>> Question for other ESS-core members:  would it make
    >>> sense to intercept the edit() and fix() commands?  See
    >>> defun inferior-R-input-sender in ess-inf.el for details.
    >>> Rich
> --
> Paul E. Johnson Professor, Political Science 1541 Lilac Lane,
    >> Room 504 University of Kansas
    >> ______________________________________________
    >> ESS-help at r-project.org mailing list
    >> https://stat.ethz.ch/mailman/listinfo/ess-help

Joshua Wiley
    > Ph.D. Student, Health Psychology University of California,
    > Los Angeles http://www.joshuawiley.com/

    > ______________________________________________
    > ESS-help at r-project.org mailing list
    > https://stat.ethz.ch/mailman/listinfo/ess-help

More information about the ESS-help mailing list