[R-SIG-Mac] bypassing the R.app help browser?
jfox at mcmaster.ca
Wed Aug 13 00:15:28 CEST 2014
> -----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 setting would not be
> returned to the default and the therefore, as you note, retained for a
> subsequent session where the behavior may not be desired.
Yes, there is that possibility.
> If this is for Rcmdr, perhaps this is something that could be added to
> a menu, where the user can alter the behavior in either direction as
> desired, if that makes sense.
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.
> Simon would need to comment on the potential for alternatives.
Yes, that would be welcome. I still think that a setting via options() would
Thanks again for your help,
> Best regards,
> 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
> > 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
> > until the change is explicitly undone. I think that I can work around
> > 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;
> > 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
> > directly via options() in R, or if one could specify the browser in a
> > 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
> >> 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
> >> do not use and the help system does now popup a browser.
> >> Regards,
> >> Marc Schwartz
More information about the R-SIG-Mac