Re: [R-SIG-Mac] bypassing the R.app help browser?
Dear Brian, Peter, and Simon, As I explained, I removed the call to tkwait.window() in Rcmdr modal dialogs, and I've now had a chance to test the consequences. AFAICS, in almost all cases, the change is benign. Because control is returned to the R command prompt before a dialog closes, there is the possibility that a user will put R in a state that produce an error (e.g., erasing a data set that existed when the dialog opened), but that seems to me unlikely. In some cases, however, when the OK button is pressed in a dialog, another dialog opens, and, to work properly, the function dispatched by the OK button should wait until the second dialog closes, since it requires information supplied by the user in the second dialog. Removing tkwait.window() from the second dialog produces an error in this circumstance. I've therefore introduced an optional force.tkwait argument, which defaults to FALSE, to the Rcmdr dialogSuffix() macro; setting the argument to TRUE in a secondary dialog solves the problem that I outlined. With these changes, I think that the Rcmdr now behaves correctly on all platforms, permitting, e.g., help pages to display properly under Mac OS X and in RStudio. Thanks to everyone who addressed this problem, John -Original Message- From: r-sig-mac-boun...@r-project.org [mailto:r-sig-mac-bounces@r- project.org] On Behalf Of John Fox Sent: Wednesday, August 13, 2014 12:57 PM To: 'Prof Brian Ripley'; 'peter dalgaard' Cc: 'R-SIG-Mac' Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? Dear Brian and Peter, Thanks for picking up this issue. The behaviour that Brian reports is exactly what I observed, and the Tcl/Tk doc that he quotes is what I consulted. It's not surprising to me that the R process waits until the Tk window calling tkwait.window() is destroyed. I suppose that because the internal help browser runs under the R process, it too waits, while an external browser -- as is spawned by help.start() - - runs in an independent process. As I mentioned, I've removed the call to tkwait.window() in the Rcmdr sources (it's in a macro called by every Rcmdr modal dialog) and will test whether there are negative consequences. I've observed none so far. BTW, the same issue arises when the Rcmdr is run inside of RStudio, which directs help to its own browser. Best, John -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: Wednesday, August 13, 2014 11:08 AM To: peter dalgaard; John Fox Cc: R-SIG-Mac Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? On 13/08/2014 15:11, peter dalgaard wrote: This isn't unique to tcltk. Anything that blocks the keyboard loop blocks the help browser too. Try e.g. opening the help for ls, type Sys.sleep(15) and watch the beach ball in the help browser as you try to scroll in it. But Sys.sleep should not be blocking an event loop: from its help The intention is that this function suspends execution of R expressions but wakes the process up often enough to respond to GUI events, typically every 0.5 seconds. The mechanisms to mesh event loops which are in place for Sys.sleep are R_CheckUserInterrupt (which calls R_ProcessEvents) and R_runHandlers. Note that the help for tkwait says (on my box) While the tkwait command is waiting it processes events in the normal fashion, so the application will continue to respond to user interac- tions. If an event handler invokes tkwait again, the nested call to tkwait must complete before the outer call can complete. but as this is X11 Tk, it means X11/Unix events. You can demonstrate that, as e.g the http server still works (use help.start() first). -pd On 13 Aug 2014, at 15:14 , John Fox j...@mcmaster.ca wrote: Dear Simon, Here's a simple script that will demonstrate the problem: - snip - library(tcltk) top - tktoplevel() button - ttkbutton(top, text=help, command=function() print(help(lm))) tkgrid(button) tkwait.window(top) - snip - The problem is produced by tkwait.window(), and this call is in all Rcmdr modal dialogs. As I read the Tcl/Tk docs, it shouldn't cause problems, but obviously it's causing this problem. I'm also not certain whether calling tkwait.windows() is necessary and will look into the consequences of removing it -- I believe that it's been there for many years, from the earliest versions of the Rcmdr. With respect to changing using preferences, this is done only until the Commander() exits. If getting rid of the call to tkwait.window() proves problematic, I can ask the user for permission in a pop-up dialog. Thanks for your help, John On Wed, 13 Aug 2014 00:25:30 -0400 Simon Urbanek simon.urba...@r-project.org wrote: John, can't you address
Re: [R-SIG-Mac] bypassing the R.app help browser?
Dear Rich, On Wed, 13 Aug 2014 20:33:47 -0400 Richard M. Heiberger r...@temple.edu wrote: I have a hypothesis why R-Forge might be having trouble. This is the first time I used Rcmdr in R_3.1.1 on the Mac. It said it needed to install sem, relimp, lmtest, aplpack. It also installed the dependency matrixcalc. matrixcalc is not in the Rcmdr Suggests: list. My guess is that adding matrixcalc to the Suggests list might be the missing item that will allow building on R-Forge. No, these packages in Suggests are not new in version 2.1-0 of the Rcmdr; they are also in the current CRAN version. matrixcalc is required by sem, and that indirect dependency doesn't cause a problem. Here's what R-Forge isn't finding: 'abind' 'aplpack' 'colorspace' 'effects' 'e1071' 'Hmisc' 'knitr' 'leaps' 'lmtest' 'markdown' 'multcomp' 'relimp' 'rgl' 'rJava' 'RODBC' 'sem' . BTW, I noticed that this problem doesn't occur anymore on the Linux platform on R-Forge, just on Windows, so maybe it's being fixed. Thanks for trying to help, John Rich On Wed, Aug 13, 2014 at 3:08 PM, John Fox j...@mcmaster.ca wrote: Dear Rich, -Original Message- From: Richard M. Heiberger [mailto:r...@temple.edu] Sent: Wednesday, August 13, 2014 1:30 PM To: John Fox Cc: Prof Brian Ripley; peter dalgaard; R-SIG-Mac Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? John, I have noticed what I think is a related issue. I normally run R under emacs with ESS. help files open an emacs buffer. When I run Rcmdr on the Mac, then Rcmdr changes the help file location to something on the Mac. It restores the emacs buffer destination when I close Rcmdr. Is there, or can there be, an option to leave the help files in emacs? At the moment, help handling is in flux as a consequence of this thred. Currently in the new Rcmdr version 2.1-0 on R-Forge, there is an Rcmdr help_type option that overrides (and restores on exit) the help_type option in options(). By default, this is set to html, but you should be able to set it to whatever works with emacs -- I suppose options(Rcmdr=list(help_type=text)) would do the trick. Please try this out and let me know if it does what you want. The Rcmdr package isn't currently building on R-Forge for reasons that I don't completely understand: R-Forge complains that some package dependencies are missing, but these missing packages *are* on CRAN. So you'll have to download the Rcmdr sources via svn checkout svn://svn.r-forge.r-project.org/svnroot/rcmdr/pkg/Rcmdr-current and build the package yourself. Best, John Thanks Rich On Wed, Aug 13, 2014 at 12:56 PM, John Fox j...@mcmaster.ca wrote: Dear Brian and Peter, Thanks for picking up this issue. The behaviour that Brian reports is exactly what I observed, and the Tcl/Tk doc that he quotes is what I consulted. It's not surprising to me that the R process waits until the Tk window calling tkwait.window() is destroyed. I suppose that because the internal help browser runs under the R process, it too waits, while an external browser -- as is spawned by help.start() -- runs in an independent process. As I mentioned, I've removed the call to tkwait.window() in the Rcmdr sources (it's in a macro called by every Rcmdr modal dialog) and will test whether there are negative consequences. I've observed none so far. BTW, the same issue arises when the Rcmdr is run inside of RStudio, which directs help to its own browser. Best, John -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: Wednesday, August 13, 2014 11:08 AM To: peter dalgaard; John Fox Cc: R-SIG-Mac Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? On 13/08/2014 15:11, peter dalgaard wrote: This isn't unique to tcltk. Anything that blocks the keyboard loop blocks the help browser too. Try e.g. opening the help for ls, type Sys.sleep(15) and watch the beach ball in the help browser as you try to scroll in it. But Sys.sleep should not be blocking an event loop: from its help The intention is that this function suspends execution of R expressions but wakes the process up often enough to respond to GUI events, typically every 0.5 seconds. The mechanisms to mesh event loops which are in place for Sys.sleep are R_CheckUserInterrupt (which calls R_ProcessEvents) and R_runHandlers. Note that the help for tkwait says (on my box) While the tkwait command is waiting it processes events in the normal fashion, so the application will continue to respond to user interac- tions. If an event handler invokes tkwait again, the nested call to tkwait must complete before the outer call can complete. but as this is X11 Tk, it means
Re: [R-SIG-Mac] bypassing the R.app help browser?
Dear Rich, On Wed, 13 Aug 2014 21:11:34 -0400 Richard M. Heiberger r...@temple.edu wrote: I downloaded Rcmdr_2.1-0 and installed it on my Mac. I am using 57531778 Jul 16 23:58 R-3.1-branch-mavericks.pkg R version 3.1.1 Patched (2014-07-16 r66175) Rcmdr needs RcmdrMisc which I see is in the same svn download, so I installed it too. I don't see anything on the Tools Options that looks relevant to the help system. No, not all Rcmdr options are there. options(Rcmdr) comes up NULL. Yes, until you've set it. I tried Rcmdr - list( help_type=text) options()$Rcmdr NULL options(Rcmdr=Rcmdr) options(Rcmdr) $Rcmdr $Rcmdr$help_type [1] text and also options(help_type=text) Neither helped. Help files are sent to an X11 viewer. Looking at the current Rcmdr code on R-Forge, I actually removed the application of the Rcmdr help_type option in the last set of changes, so it's simply ignored. I apologize for the misinformation in my previous message. OTOH, the standard R help_type option should then control help, so setting options(help_type=text) should produce plain-text help. I just checked on my Windows system under the R Console, and it behaves as expected. If you're seeing the plain-text help in X-Windows, I don't know how to make it appear instead in Emacs. Sorry, John I detached Rcmdr with unload=TRUE and help files went back to an emacs buffer. Please suggest something else for me to try. Rich On Wed, Aug 13, 2014 at 8:33 PM, Richard M. Heiberger r...@temple.edu wrote: I have a hypothesis why R-Forge might be having trouble. This is the first time I used Rcmdr in R_3.1.1 on the Mac. It said it needed to install sem, relimp, lmtest, aplpack. It also installed the dependency matrixcalc. matrixcalc is not in the Rcmdr Suggests: list. My guess is that adding matrixcalc to the Suggests list might be the missing item that will allow building on R-Forge. Rich On Wed, Aug 13, 2014 at 3:08 PM, John Fox j...@mcmaster.ca wrote: Dear Rich, -Original Message- From: Richard M. Heiberger [mailto:r...@temple.edu] Sent: Wednesday, August 13, 2014 1:30 PM To: John Fox Cc: Prof Brian Ripley; peter dalgaard; R-SIG-Mac Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? John, I have noticed what I think is a related issue. I normally run R under emacs with ESS. help files open an emacs buffer. When I run Rcmdr on the Mac, then Rcmdr changes the help file location to something on the Mac. It restores the emacs buffer destination when I close Rcmdr. Is there, or can there be, an option to leave the help files in emacs? At the moment, help handling is in flux as a consequence of this thred. Currently in the new Rcmdr version 2.1-0 on R-Forge, there is an Rcmdr help_type option that overrides (and restores on exit) the help_type option in options(). By default, this is set to html, but you should be able to set it to whatever works with emacs -- I suppose options(Rcmdr=list(help_type=text)) would do the trick. Please try this out and let me know if it does what you want. The Rcmdr package isn't currently building on R-Forge for reasons that I don't completely understand: R-Forge complains that some package dependencies are missing, but these missing packages *are* on CRAN. So you'll have to download the Rcmdr sources via svn checkout svn://svn.r-forge.r-project.org/svnroot/rcmdr/pkg/Rcmdr-current and build the package yourself. Best, John Thanks Rich On Wed, Aug 13, 2014 at 12:56 PM, John Fox j...@mcmaster.ca wrote: Dear Brian and Peter, Thanks for picking up this issue. The behaviour that Brian reports is exactly what I observed, and the Tcl/Tk doc that he quotes is what I consulted. It's not surprising to me that the R process waits until the Tk window calling tkwait.window() is destroyed. I suppose that because the internal help browser runs under the R process, it too waits, while an external browser -- as is spawned by help.start() -- runs in an independent process. As I mentioned, I've removed the call to tkwait.window() in the Rcmdr sources (it's in a macro called by every Rcmdr modal dialog) and will test whether there are negative consequences. I've observed none so far. BTW, the same issue arises when the Rcmdr is run inside of RStudio, which directs help to its own browser. Best, John -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: Wednesday, August 13, 2014 11:08 AM To: peter dalgaard; John Fox Cc: R-SIG-Mac Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? On 13/08/2014 15:11, peter dalgaard wrote: This isn't unique to tcltk. Anything that blocks the keyboard loop blocks the help browser too. Try e.g. opening the help for ls, type Sys.sleep(15) and watch
Re: [R-SIG-Mac] bypassing the R.app help browser?
Dear Simon, Here's a simple script that will demonstrate the problem: - snip - library(tcltk) top - tktoplevel() button - ttkbutton(top, text=help, command=function() print(help(lm))) tkgrid(button) tkwait.window(top) - snip - The problem is produced by tkwait.window(), and this call is in all Rcmdr modal dialogs. As I read the Tcl/Tk docs, it shouldn't cause problems, but obviously it's causing this problem. I'm also not certain whether calling tkwait.windows() is necessary and will look into the consequences of removing it -- I believe that it's been there for many years, from the earliest versions of the Rcmdr. With respect to changing using preferences, this is done only until the Commander() exits. If getting rid of the call to tkwait.window() proves problematic, I can ask the user for permission in a pop-up dialog. Thanks for your help, John On Wed, 13 Aug 2014 00:25:30 -0400 Simon Urbanek simon.urba...@r-project.org wrote: 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 j...@mcmaster.ca wrote: Hi Marc, -Original Message- From: Marc Schwartz [mailto:marc_schwa...@me.com] Sent: Tuesday, August 12, 2014 5:10 PM To: John Fox Cc: r-sig-mac@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 j...@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_schwa...@me.com] Sent: Tuesday, August 12, 2014 4:04 PM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? On Aug 12, 2014, at 2:33 PM, John Fox j...@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
Re: [R-SIG-Mac] bypassing the R.app help browser?
This isn't unique to tcltk. Anything that blocks the keyboard loop blocks the help browser too. Try e.g. opening the help for ls, type Sys.sleep(15) and watch the beach ball in the help browser as you try to scroll in it. -pd On 13 Aug 2014, at 15:14 , John Fox j...@mcmaster.ca wrote: Dear Simon, Here's a simple script that will demonstrate the problem: - snip - library(tcltk) top - tktoplevel() button - ttkbutton(top, text=help, command=function() print(help(lm))) tkgrid(button) tkwait.window(top) - snip - The problem is produced by tkwait.window(), and this call is in all Rcmdr modal dialogs. As I read the Tcl/Tk docs, it shouldn't cause problems, but obviously it's causing this problem. I'm also not certain whether calling tkwait.windows() is necessary and will look into the consequences of removing it -- I believe that it's been there for many years, from the earliest versions of the Rcmdr. With respect to changing using preferences, this is done only until the Commander() exits. If getting rid of the call to tkwait.window() proves problematic, I can ask the user for permission in a pop-up dialog. Thanks for your help, John On Wed, 13 Aug 2014 00:25:30 -0400 Simon Urbanek simon.urba...@r-project.org wrote: 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 j...@mcmaster.ca wrote: Hi Marc, -Original Message- From: Marc Schwartz [mailto:marc_schwa...@me.com] Sent: Tuesday, August 12, 2014 5:10 PM To: John Fox Cc: r-sig-mac@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 j...@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_schwa...@me.com] Sent: Tuesday, August 12, 2014 4:04 PM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? On Aug 12, 2014, at 2:33 PM, John Fox j...@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
Re: [R-SIG-Mac] bypassing the R.app help browser?
On 13/08/2014 15:11, peter dalgaard wrote: This isn't unique to tcltk. Anything that blocks the keyboard loop blocks the help browser too. Try e.g. opening the help for ls, type Sys.sleep(15) and watch the beach ball in the help browser as you try to scroll in it. But Sys.sleep should not be blocking an event loop: from its help The intention is that this function suspends execution of R expressions but wakes the process up often enough to respond to GUI events, typically every 0.5 seconds. The mechanisms to mesh event loops which are in place for Sys.sleep are R_CheckUserInterrupt (which calls R_ProcessEvents) and R_runHandlers. Note that the help for tkwait says (on my box) While the tkwait command is waiting it processes events in the normal fashion, so the application will continue to respond to user interac- tions. If an event handler invokes tkwait again, the nested call to tkwait must complete before the outer call can complete. but as this is X11 Tk, it means X11/Unix events. You can demonstrate that, as e.g the http server still works (use help.start() first). -pd On 13 Aug 2014, at 15:14 , John Fox j...@mcmaster.ca wrote: Dear Simon, Here's a simple script that will demonstrate the problem: - snip - library(tcltk) top - tktoplevel() button - ttkbutton(top, text=help, command=function() print(help(lm))) tkgrid(button) tkwait.window(top) - snip - The problem is produced by tkwait.window(), and this call is in all Rcmdr modal dialogs. As I read the Tcl/Tk docs, it shouldn't cause problems, but obviously it's causing this problem. I'm also not certain whether calling tkwait.windows() is necessary and will look into the consequences of removing it -- I believe that it's been there for many years, from the earliest versions of the Rcmdr. With respect to changing using preferences, this is done only until the Commander() exits. If getting rid of the call to tkwait.window() proves problematic, I can ask the user for permission in a pop-up dialog. Thanks for your help, John On Wed, 13 Aug 2014 00:25:30 -0400 Simon Urbanek simon.urba...@r-project.org wrote: 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 j...@mcmaster.ca wrote: Hi Marc, -Original Message- From: Marc Schwartz [mailto:marc_schwa...@me.com] Sent: Tuesday, August 12, 2014 5:10 PM To: John Fox Cc: r-sig-mac@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 j...@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
Re: [R-SIG-Mac] bypassing the R.app help browser?
Dear Brian and Peter, Thanks for picking up this issue. The behaviour that Brian reports is exactly what I observed, and the Tcl/Tk doc that he quotes is what I consulted. It's not surprising to me that the R process waits until the Tk window calling tkwait.window() is destroyed. I suppose that because the internal help browser runs under the R process, it too waits, while an external browser -- as is spawned by help.start() -- runs in an independent process. As I mentioned, I've removed the call to tkwait.window() in the Rcmdr sources (it's in a macro called by every Rcmdr modal dialog) and will test whether there are negative consequences. I've observed none so far. BTW, the same issue arises when the Rcmdr is run inside of RStudio, which directs help to its own browser. Best, John -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: Wednesday, August 13, 2014 11:08 AM To: peter dalgaard; John Fox Cc: R-SIG-Mac Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? On 13/08/2014 15:11, peter dalgaard wrote: This isn't unique to tcltk. Anything that blocks the keyboard loop blocks the help browser too. Try e.g. opening the help for ls, type Sys.sleep(15) and watch the beach ball in the help browser as you try to scroll in it. But Sys.sleep should not be blocking an event loop: from its help The intention is that this function suspends execution of R expressions but wakes the process up often enough to respond to GUI events, typically every 0.5 seconds. The mechanisms to mesh event loops which are in place for Sys.sleep are R_CheckUserInterrupt (which calls R_ProcessEvents) and R_runHandlers. Note that the help for tkwait says (on my box) While the tkwait command is waiting it processes events in the normal fashion, so the application will continue to respond to user interac- tions. If an event handler invokes tkwait again, the nested call to tkwait must complete before the outer call can complete. but as this is X11 Tk, it means X11/Unix events. You can demonstrate that, as e.g the http server still works (use help.start() first). -pd On 13 Aug 2014, at 15:14 , John Fox j...@mcmaster.ca wrote: Dear Simon, Here's a simple script that will demonstrate the problem: - snip - library(tcltk) top - tktoplevel() button - ttkbutton(top, text=help, command=function() print(help(lm))) tkgrid(button) tkwait.window(top) - snip - The problem is produced by tkwait.window(), and this call is in all Rcmdr modal dialogs. As I read the Tcl/Tk docs, it shouldn't cause problems, but obviously it's causing this problem. I'm also not certain whether calling tkwait.windows() is necessary and will look into the consequences of removing it -- I believe that it's been there for many years, from the earliest versions of the Rcmdr. With respect to changing using preferences, this is done only until the Commander() exits. If getting rid of the call to tkwait.window() proves problematic, I can ask the user for permission in a pop-up dialog. Thanks for your help, John On Wed, 13 Aug 2014 00:25:30 -0400 Simon Urbanek simon.urba...@r-project.org wrote: 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 j...@mcmaster.ca wrote: Hi Marc, -Original Message- From: Marc Schwartz [mailto:marc_schwa...@me.com] Sent: Tuesday, August 12, 2014 5:10 PM To: John Fox Cc: r-sig-mac@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
Re: [R-SIG-Mac] bypassing the R.app help browser?
John, I have noticed what I think is a related issue. I normally run R under emacs with ESS. help files open an emacs buffer. When I run Rcmdr on the Mac, then Rcmdr changes the help file location to something on the Mac. It restores the emacs buffer destination when I close Rcmdr. Is there, or can there be, an option to leave the help files in emacs? Thanks Rich On Wed, Aug 13, 2014 at 12:56 PM, John Fox j...@mcmaster.ca wrote: Dear Brian and Peter, Thanks for picking up this issue. The behaviour that Brian reports is exactly what I observed, and the Tcl/Tk doc that he quotes is what I consulted. It's not surprising to me that the R process waits until the Tk window calling tkwait.window() is destroyed. I suppose that because the internal help browser runs under the R process, it too waits, while an external browser -- as is spawned by help.start() -- runs in an independent process. As I mentioned, I've removed the call to tkwait.window() in the Rcmdr sources (it's in a macro called by every Rcmdr modal dialog) and will test whether there are negative consequences. I've observed none so far. BTW, the same issue arises when the Rcmdr is run inside of RStudio, which directs help to its own browser. Best, John -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: Wednesday, August 13, 2014 11:08 AM To: peter dalgaard; John Fox Cc: R-SIG-Mac Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? On 13/08/2014 15:11, peter dalgaard wrote: This isn't unique to tcltk. Anything that blocks the keyboard loop blocks the help browser too. Try e.g. opening the help for ls, type Sys.sleep(15) and watch the beach ball in the help browser as you try to scroll in it. But Sys.sleep should not be blocking an event loop: from its help The intention is that this function suspends execution of R expressions but wakes the process up often enough to respond to GUI events, typically every 0.5 seconds. The mechanisms to mesh event loops which are in place for Sys.sleep are R_CheckUserInterrupt (which calls R_ProcessEvents) and R_runHandlers. Note that the help for tkwait says (on my box) While the tkwait command is waiting it processes events in the normal fashion, so the application will continue to respond to user interac- tions. If an event handler invokes tkwait again, the nested call to tkwait must complete before the outer call can complete. but as this is X11 Tk, it means X11/Unix events. You can demonstrate that, as e.g the http server still works (use help.start() first). -pd On 13 Aug 2014, at 15:14 , John Fox j...@mcmaster.ca wrote: Dear Simon, Here's a simple script that will demonstrate the problem: - snip - library(tcltk) top - tktoplevel() button - ttkbutton(top, text=help, command=function() print(help(lm))) tkgrid(button) tkwait.window(top) - snip - The problem is produced by tkwait.window(), and this call is in all Rcmdr modal dialogs. As I read the Tcl/Tk docs, it shouldn't cause problems, but obviously it's causing this problem. I'm also not certain whether calling tkwait.windows() is necessary and will look into the consequences of removing it -- I believe that it's been there for many years, from the earliest versions of the Rcmdr. With respect to changing using preferences, this is done only until the Commander() exits. If getting rid of the call to tkwait.window() proves problematic, I can ask the user for permission in a pop-up dialog. Thanks for your help, John On Wed, 13 Aug 2014 00:25:30 -0400 Simon Urbanek simon.urba...@r-project.org wrote: 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 j...@mcmaster.ca wrote: Hi Marc, -Original Message- From: Marc Schwartz [mailto:marc_schwa...@me.com] Sent: Tuesday, August 12, 2014 5:10 PM To: John Fox Cc: r-sig-mac@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
Re: [R-SIG-Mac] bypassing the R.app help browser?
Dear Rich, -Original Message- From: Richard M. Heiberger [mailto:r...@temple.edu] Sent: Wednesday, August 13, 2014 1:30 PM To: John Fox Cc: Prof Brian Ripley; peter dalgaard; R-SIG-Mac Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? John, I have noticed what I think is a related issue. I normally run R under emacs with ESS. help files open an emacs buffer. When I run Rcmdr on the Mac, then Rcmdr changes the help file location to something on the Mac. It restores the emacs buffer destination when I close Rcmdr. Is there, or can there be, an option to leave the help files in emacs? At the moment, help handling is in flux as a consequence of this thred. Currently in the new Rcmdr version 2.1-0 on R-Forge, there is an Rcmdr help_type option that overrides (and restores on exit) the help_type option in options(). By default, this is set to html, but you should be able to set it to whatever works with emacs -- I suppose options(Rcmdr=list(help_type=text)) would do the trick. Please try this out and let me know if it does what you want. The Rcmdr package isn't currently building on R-Forge for reasons that I don't completely understand: R-Forge complains that some package dependencies are missing, but these missing packages *are* on CRAN. So you'll have to download the Rcmdr sources via svn checkout svn://svn.r-forge.r-project.org/svnroot/rcmdr/pkg/Rcmdr-current and build the package yourself. Best, John Thanks Rich On Wed, Aug 13, 2014 at 12:56 PM, John Fox j...@mcmaster.ca wrote: Dear Brian and Peter, Thanks for picking up this issue. The behaviour that Brian reports is exactly what I observed, and the Tcl/Tk doc that he quotes is what I consulted. It's not surprising to me that the R process waits until the Tk window calling tkwait.window() is destroyed. I suppose that because the internal help browser runs under the R process, it too waits, while an external browser -- as is spawned by help.start() -- runs in an independent process. As I mentioned, I've removed the call to tkwait.window() in the Rcmdr sources (it's in a macro called by every Rcmdr modal dialog) and will test whether there are negative consequences. I've observed none so far. BTW, the same issue arises when the Rcmdr is run inside of RStudio, which directs help to its own browser. Best, John -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: Wednesday, August 13, 2014 11:08 AM To: peter dalgaard; John Fox Cc: R-SIG-Mac Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? On 13/08/2014 15:11, peter dalgaard wrote: This isn't unique to tcltk. Anything that blocks the keyboard loop blocks the help browser too. Try e.g. opening the help for ls, type Sys.sleep(15) and watch the beach ball in the help browser as you try to scroll in it. But Sys.sleep should not be blocking an event loop: from its help The intention is that this function suspends execution of R expressions but wakes the process up often enough to respond to GUI events, typically every 0.5 seconds. The mechanisms to mesh event loops which are in place for Sys.sleep are R_CheckUserInterrupt (which calls R_ProcessEvents) and R_runHandlers. Note that the help for tkwait says (on my box) While the tkwait command is waiting it processes events in the normal fashion, so the application will continue to respond to user interac- tions. If an event handler invokes tkwait again, the nested call to tkwait must complete before the outer call can complete. but as this is X11 Tk, it means X11/Unix events. You can demonstrate that, as e.g the http server still works (use help.start() first). -pd On 13 Aug 2014, at 15:14 , John Fox j...@mcmaster.ca wrote: Dear Simon, Here's a simple script that will demonstrate the problem: - snip - library(tcltk) top - tktoplevel() button - ttkbutton(top, text=help, command=function() print(help(lm))) tkgrid(button) tkwait.window(top) - snip - The problem is produced by tkwait.window(), and this call is in all Rcmdr modal dialogs. As I read the Tcl/Tk docs, it shouldn't cause problems, but obviously it's causing this problem. I'm also not certain whether calling tkwait.windows() is necessary and will look into the consequences of removing it -- I believe that it's been there for many years, from the earliest versions of the Rcmdr. With respect to changing using preferences, this is done only until the Commander() exits. If getting rid of the call to tkwait.window() proves problematic, I can ask the user for permission in a pop-up dialog. Thanks for your help, John On Wed, 13 Aug 2014 00:25:30 -0400 Simon Urbanek simon.urba...@r-project.org wrote
Re: [R-SIG-Mac] bypassing the R.app help browser?
I have a hypothesis why R-Forge might be having trouble. This is the first time I used Rcmdr in R_3.1.1 on the Mac. It said it needed to install sem, relimp, lmtest, aplpack. It also installed the dependency matrixcalc. matrixcalc is not in the Rcmdr Suggests: list. My guess is that adding matrixcalc to the Suggests list might be the missing item that will allow building on R-Forge. Rich On Wed, Aug 13, 2014 at 3:08 PM, John Fox j...@mcmaster.ca wrote: Dear Rich, -Original Message- From: Richard M. Heiberger [mailto:r...@temple.edu] Sent: Wednesday, August 13, 2014 1:30 PM To: John Fox Cc: Prof Brian Ripley; peter dalgaard; R-SIG-Mac Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? John, I have noticed what I think is a related issue. I normally run R under emacs with ESS. help files open an emacs buffer. When I run Rcmdr on the Mac, then Rcmdr changes the help file location to something on the Mac. It restores the emacs buffer destination when I close Rcmdr. Is there, or can there be, an option to leave the help files in emacs? At the moment, help handling is in flux as a consequence of this thred. Currently in the new Rcmdr version 2.1-0 on R-Forge, there is an Rcmdr help_type option that overrides (and restores on exit) the help_type option in options(). By default, this is set to html, but you should be able to set it to whatever works with emacs -- I suppose options(Rcmdr=list(help_type=text)) would do the trick. Please try this out and let me know if it does what you want. The Rcmdr package isn't currently building on R-Forge for reasons that I don't completely understand: R-Forge complains that some package dependencies are missing, but these missing packages *are* on CRAN. So you'll have to download the Rcmdr sources via svn checkout svn://svn.r-forge.r-project.org/svnroot/rcmdr/pkg/Rcmdr-current and build the package yourself. Best, John Thanks Rich On Wed, Aug 13, 2014 at 12:56 PM, John Fox j...@mcmaster.ca wrote: Dear Brian and Peter, Thanks for picking up this issue. The behaviour that Brian reports is exactly what I observed, and the Tcl/Tk doc that he quotes is what I consulted. It's not surprising to me that the R process waits until the Tk window calling tkwait.window() is destroyed. I suppose that because the internal help browser runs under the R process, it too waits, while an external browser -- as is spawned by help.start() -- runs in an independent process. As I mentioned, I've removed the call to tkwait.window() in the Rcmdr sources (it's in a macro called by every Rcmdr modal dialog) and will test whether there are negative consequences. I've observed none so far. BTW, the same issue arises when the Rcmdr is run inside of RStudio, which directs help to its own browser. Best, John -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: Wednesday, August 13, 2014 11:08 AM To: peter dalgaard; John Fox Cc: R-SIG-Mac Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? On 13/08/2014 15:11, peter dalgaard wrote: This isn't unique to tcltk. Anything that blocks the keyboard loop blocks the help browser too. Try e.g. opening the help for ls, type Sys.sleep(15) and watch the beach ball in the help browser as you try to scroll in it. But Sys.sleep should not be blocking an event loop: from its help The intention is that this function suspends execution of R expressions but wakes the process up often enough to respond to GUI events, typically every 0.5 seconds. The mechanisms to mesh event loops which are in place for Sys.sleep are R_CheckUserInterrupt (which calls R_ProcessEvents) and R_runHandlers. Note that the help for tkwait says (on my box) While the tkwait command is waiting it processes events in the normal fashion, so the application will continue to respond to user interac- tions. If an event handler invokes tkwait again, the nested call to tkwait must complete before the outer call can complete. but as this is X11 Tk, it means X11/Unix events. You can demonstrate that, as e.g the http server still works (use help.start() first). -pd On 13 Aug 2014, at 15:14 , John Fox j...@mcmaster.ca wrote: Dear Simon, Here's a simple script that will demonstrate the problem: - snip - library(tcltk) top - tktoplevel() button - ttkbutton(top, text=help, command=function() print(help(lm))) tkgrid(button) tkwait.window(top) - snip - The problem is produced by tkwait.window(), and this call is in all Rcmdr modal dialogs. As I read the Tcl/Tk docs, it shouldn't cause problems, but obviously it's causing this problem. I'm also not certain whether calling tkwait.windows() is necessary and will look
Re: [R-SIG-Mac] bypassing the R.app help browser?
I downloaded Rcmdr_2.1-0 and installed it on my Mac. I am using 57531778 Jul 16 23:58 R-3.1-branch-mavericks.pkg R version 3.1.1 Patched (2014-07-16 r66175) Rcmdr needs RcmdrMisc which I see is in the same svn download, so I installed it too. I don't see anything on the Tools Options that looks relevant to the help system. options(Rcmdr) comes up NULL. I tried Rcmdr - list( help_type=text) options()$Rcmdr NULL options(Rcmdr=Rcmdr) options(Rcmdr) $Rcmdr $Rcmdr$help_type [1] text and also options(help_type=text) Neither helped. Help files are sent to an X11 viewer. I detached Rcmdr with unload=TRUE and help files went back to an emacs buffer. Please suggest something else for me to try. Rich On Wed, Aug 13, 2014 at 8:33 PM, Richard M. Heiberger r...@temple.edu wrote: I have a hypothesis why R-Forge might be having trouble. This is the first time I used Rcmdr in R_3.1.1 on the Mac. It said it needed to install sem, relimp, lmtest, aplpack. It also installed the dependency matrixcalc. matrixcalc is not in the Rcmdr Suggests: list. My guess is that adding matrixcalc to the Suggests list might be the missing item that will allow building on R-Forge. Rich On Wed, Aug 13, 2014 at 3:08 PM, John Fox j...@mcmaster.ca wrote: Dear Rich, -Original Message- From: Richard M. Heiberger [mailto:r...@temple.edu] Sent: Wednesday, August 13, 2014 1:30 PM To: John Fox Cc: Prof Brian Ripley; peter dalgaard; R-SIG-Mac Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? John, I have noticed what I think is a related issue. I normally run R under emacs with ESS. help files open an emacs buffer. When I run Rcmdr on the Mac, then Rcmdr changes the help file location to something on the Mac. It restores the emacs buffer destination when I close Rcmdr. Is there, or can there be, an option to leave the help files in emacs? At the moment, help handling is in flux as a consequence of this thred. Currently in the new Rcmdr version 2.1-0 on R-Forge, there is an Rcmdr help_type option that overrides (and restores on exit) the help_type option in options(). By default, this is set to html, but you should be able to set it to whatever works with emacs -- I suppose options(Rcmdr=list(help_type=text)) would do the trick. Please try this out and let me know if it does what you want. The Rcmdr package isn't currently building on R-Forge for reasons that I don't completely understand: R-Forge complains that some package dependencies are missing, but these missing packages *are* on CRAN. So you'll have to download the Rcmdr sources via svn checkout svn://svn.r-forge.r-project.org/svnroot/rcmdr/pkg/Rcmdr-current and build the package yourself. Best, John Thanks Rich On Wed, Aug 13, 2014 at 12:56 PM, John Fox j...@mcmaster.ca wrote: Dear Brian and Peter, Thanks for picking up this issue. The behaviour that Brian reports is exactly what I observed, and the Tcl/Tk doc that he quotes is what I consulted. It's not surprising to me that the R process waits until the Tk window calling tkwait.window() is destroyed. I suppose that because the internal help browser runs under the R process, it too waits, while an external browser -- as is spawned by help.start() -- runs in an independent process. As I mentioned, I've removed the call to tkwait.window() in the Rcmdr sources (it's in a macro called by every Rcmdr modal dialog) and will test whether there are negative consequences. I've observed none so far. BTW, the same issue arises when the Rcmdr is run inside of RStudio, which directs help to its own browser. Best, John -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: Wednesday, August 13, 2014 11:08 AM To: peter dalgaard; John Fox Cc: R-SIG-Mac Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? On 13/08/2014 15:11, peter dalgaard wrote: This isn't unique to tcltk. Anything that blocks the keyboard loop blocks the help browser too. Try e.g. opening the help for ls, type Sys.sleep(15) and watch the beach ball in the help browser as you try to scroll in it. But Sys.sleep should not be blocking an event loop: from its help The intention is that this function suspends execution of R expressions but wakes the process up often enough to respond to GUI events, typically every 0.5 seconds. The mechanisms to mesh event loops which are in place for Sys.sleep are R_CheckUserInterrupt (which calls R_ProcessEvents) and R_runHandlers. Note that the help for tkwait says (on my box) While the tkwait command is waiting it processes events in the normal fashion, so the application will continue to respond to user interac- tions. If an event handler invokes tkwait again, the nested call to tkwait must complete before the outer call can complete
Re: [R-SIG-Mac] bypassing the R.app help browser?
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_schwa...@me.com] Sent: Tuesday, August 12, 2014 4:04 PM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? On Aug 12, 2014, at 2:33 PM, John Fox j...@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@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] bypassing the R.app help browser?
Hi Marc, -Original Message- From: Marc Schwartz [mailto:marc_schwa...@me.com] Sent: Tuesday, August 12, 2014 5:10 PM To: John Fox Cc: r-sig-mac@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 j...@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_schwa...@me.com] Sent: Tuesday, August 12, 2014 4:04 PM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? On Aug 12, 2014, at 2:33 PM, John Fox j...@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@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] bypassing the R.app help browser?
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 j...@mcmaster.ca wrote: Hi Marc, -Original Message- From: Marc Schwartz [mailto:marc_schwa...@me.com] Sent: Tuesday, August 12, 2014 5:10 PM To: John Fox Cc: r-sig-mac@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 j...@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_schwa...@me.com] Sent: Tuesday, August 12, 2014 4:04 PM To: John Fox Cc: r-sig-mac@r-project.org Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? On Aug 12, 2014, at 2:33 PM, John Fox j...@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@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
