[R-SIG-Mac] bypassing the R.app help browser?

Simon Urbanek simon.urbanek at r-project.org
Wed Aug 13 06:25:30 CEST 2014


can't you address the underlying issue instead and don't block the event loop? A lot of things don't work if the event loop is blocked and I would argue that changing user's preferences behind the scenes is a violation of the CRAN policies.
I'm happy to help if you send me a bit more details.


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

> 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 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
> 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
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac at r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac

More information about the R-SIG-Mac mailing list