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 Fox, Professor
McMaster University
Hamilton, Ontario, Canada
http://socserv.mcmaster.ca/jfox/
bypassing the R.app help browser?
16 messages · Marc Schwartz, John Fox, Simon Urbanek +3 more
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
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
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. 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. Simon would need to comment on the potential for alternatives. 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
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
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 <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
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.urbanek at 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 <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
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 <jfox at 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.urbanek at 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 <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
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com
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 <jfox at 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.urbanek at 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 <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
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Brian D. Ripley, ripley at stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford 1 South Parks Road, Oxford OX1 3TG, UK
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:ripley at 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 <jfox at 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.urbanek at 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 <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
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
-- Brian D. Ripley, ripley at stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford 1 South Parks Road, Oxford OX1 3TG, UK
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 <jfox at 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:ripley at 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 <jfox at 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.urbanek at 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 <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
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
-- Brian D. Ripley, ripley at stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford 1 South Parks Road, Oxford OX1 3TG, UK
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Dear Rich,
-----Original Message----- From: Richard M. Heiberger [mailto:rmh at 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 <jfox at 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:ripley at 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 <jfox at 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.urbanek at 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 <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
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
-- Brian D. Ripley, ripley at stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford 1 South Parks Road, Oxford OX1 3TG, UK
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
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 <jfox at mcmaster.ca> wrote:
Dear Rich,
-----Original Message----- From: Richard M. Heiberger [mailto:rmh at 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 <jfox at 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:ripley at 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 <jfox at 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.urbanek at 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 <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
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
-- Brian D. Ripley, ripley at stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford 1 South Parks Road, Oxford OX1 3TG, UK
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
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 <rmh at 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 <jfox at mcmaster.ca> wrote:
Dear Rich,
-----Original Message----- From: Richard M. Heiberger [mailto:rmh at 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 <jfox at 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:ripley at 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 <jfox at 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.urbanek at 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 <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
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
-- Brian D. Ripley, ripley at stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford 1 South Parks Road, Oxford OX1 3TG, UK
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Dear Rich, On Wed, 13 Aug 2014 20:33:47 -0400
"Richard M. Heiberger" <rmh at 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 <jfox at mcmaster.ca> wrote:
Dear Rich,
-----Original Message----- From: Richard M. Heiberger [mailto:rmh at 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 <jfox at 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:ripley at 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 <jfox at 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.urbanek at 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 <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
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
-- Brian D. Ripley, ripley at stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford 1 South Parks Road, Oxford OX1 3TG, UK
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
------------------------------------------------ John Fox, Professor McMaster University Hamilton, Ontario, Canada http://socserv.mcmaster.ca/jfox/
Dear Rich, On Wed, 13 Aug 2014 21:11:34 -0400
"Richard M. Heiberger" <rmh at 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 <rmh at 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 <jfox at mcmaster.ca> wrote:
Dear Rich,
-----Original Message----- From: Richard M. Heiberger [mailto:rmh at 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 <jfox at 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:ripley at 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 <jfox at 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.urbanek at 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 <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
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
-- Brian D. Ripley, ripley at stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford 1 South Parks Road, Oxford OX1 3TG, UK
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
------------------------------------------------ John Fox, Professor McMaster University Hamilton, Ontario, Canada http://socserv.mcmaster.ca/jfox/