bypassing the R.app help browser?

John Fox · 2014-08-12T22:15:28Z

Hi Marc, > -----Original Message----- > From: Marc Schwartz [mailto:marc_schwartz at me.com] > Sent: Tuesday, August 12, 2014 5:10 PM > To: John Fox > Cc: r-sig-mac at r-project.org > Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? > > Hi John, > > Happy to help. I recalled seeing something previously on this, so a > search using rseek.org was fruitful. > > The potential gotcha, of course, is if for some reason the GUI exits in > a manner possibly not under your control. The setti

John Fox

Tue, Aug 12, 2014 3:15 PM

Hi Marc,

Yes, there is that possibility.

As you guessed, this is for the Rcmdr, where the built-in R.app browser
doesn't play well with dialog help buttons -- the browser is unresponsive
until the dialog that called it closes -- while an external html-help
browser works fine.

I've now successfully implemented the approach I outlined, in which the
previous setting is restored when the Commander GUI closes. As you point
out, this isn't bullet-proof, but I think it is the best I can do for now.
Allowing the user to apply the change would be safer, but users are unlikely
to discover the option.

Yes, that would be welcome. I still think that a setting via options() would
be better.

Thanks again for your help,
 John

Best regards,

Marc


On Aug 12, 2014, at 3:46 PM, John Fox <jfox at mcmaster.ca> wrote:

Hi Marc,

Thanks for this. It does work, and I wasn't aware of it -- you've

obviously

done a better job than I did of searching for a solution!

Although this approach works, it has the disadvantage of permanently
changing the help browser in R.app, beyond the current session, at

least

until the change is explicitly undone. I think that I can work around

that

by something like

	current <- system("defaults read org.R-project.R", intern=TRUE)

to discover whether the use.external.help preference exists, and if

so, what

its value is; to then set the preference to YES if it's NO or unset;

and

finally to remove the preference on exit.

Again, thanks -- I think that I can work with this, though it would

in my

opinion be better if the help browser were settable for the current

session

directly via options() in R, or if one could specify the browser in a

call

to help().

Best (and thanks again),
John

-----Original Message-----
From: Marc Schwartz [mailto:marc_schwartz at me.com]
Sent: Tuesday, August 12, 2014 4:04 PM
To: John Fox
Cc: r-sig-mac at r-project.org
Subject: Re: [R-SIG-Mac] bypassing the R.app help browser?

On Aug 12, 2014, at 2:33 PM, John Fox <jfox at mcmaster.ca> wrote:

Dear list members,

Is there a way to bypass the R.app help browser, and to use instead

an alternative browser, such as the one pointed to by
getOption("browser")?

I've tried a number of strategies, including setting .Platform$GUI

<-

"unknown". The only approach I tried that works is to mask the

help()

function with a modified version, but this produces other problems,
such as referencing unexported objects from utils and tools.

It would be nice if the help() function had a browser argument,

similar to that in browseURL(), and defaulting to the current
behaviour.

Any suggestions would be appreciated.

John


John,

I found this post from Simon that seems to work:

 https://stat.ethz.ch/pipermail/r-sig-mac/2009-December/006908.html

I tried it on my Mac in the latest version of R.app, which I

normally

do not use and the help system does now popup a browser.


Regards,

Marc Schwartz

bypassing the R.app help browser?

Thread (16 messages)