[R-SIG-Mac] bypassing the R.app help browser?
Richard M. Heiberger
rmh at temple.edu
Wed Aug 13 19:29:45 CEST 2014
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
More information about the R-SIG-Mac
mailing list