John, 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.
Cheers, Simon On Aug 12, 2014, at 6:15 PM, John Fox <[email protected]> wrote: > Hi Marc, > >> -----Original Message----- >> From: Marc Schwartz [mailto:[email protected]] >> Sent: Tuesday, August 12, 2014 5:10 PM >> To: John Fox >> Cc: [email protected] >> 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 <[email protected]> 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:[email protected]] >>>> Sent: Tuesday, August 12, 2014 4:04 PM >>>> To: John Fox >>>> Cc: [email protected] >>>> Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? >>>> >>>> On Aug 12, 2014, at 2:33 PM, John Fox <[email protected]> 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 > [email protected] > https://stat.ethz.ch/mailman/listinfo/r-sig-mac > _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
