[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