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 <[email protected]> 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:[email protected]] >> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >> >>> >> >>>> Hi Marc, >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: Marc Schwartz [mailto:[email protected]] >> >>>>> Sent: Tuesday, August 12, 2014 5:10 PM >> >>>>> To: John Fox >> >>>>> Cc: [email protected] >> >>>>> Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? >> >>>>> >> >>>>> Hi John, >> >>>>> >> >>>>> Happy to help. I recalled seeing something previously on this, so >> a >> >>>>> search using rseek.org was fruitful. >> >>>>> >> >>>>> The potential gotcha, of course, is if for some reason the GUI >> exits in >> >>>>> a manner possibly not under your control. The setting would not >> be >> >>>>> returned to the default and the therefore, as you note, retained >> for a >> >>>>> subsequent session where the behavior may not be desired. >> >>>>> >> >>>> >> >>>> Yes, there is that possibility. >> >>>> >> >>>>> If this is for Rcmdr, perhaps this is something that could be >> added to >> >>>>> a menu, where the user can alter the behavior in either direction >> as >> >>>>> desired, if that makes sense. >> >>>>> >> >>>> >> >>>> As you guessed, this is for the Rcmdr, where the built-in R.app >> browser >> >>>> doesn't play well with dialog help buttons -- the browser is >> unresponsive >> >>>> until the dialog that called it closes -- while an external html- >> help >> >>>> browser works fine. >> >>>> >> >>>> I've now successfully implemented the approach I outlined, in >> which the >> >>>> previous setting is restored when the Commander GUI closes. As you >> point >> >>>> out, this isn't bullet-proof, but I think it is the best I can do >> for now. >> >>>> Allowing the user to apply the change would be safer, but users >> are unlikely >> >>>> to discover the option. >> >>>> >> >>>>> Simon would need to comment on the potential for alternatives. >> >>>> >> >>>> Yes, that would be welcome. I still think that a setting via >> options() would >> >>>> be better. >> >>>> >> >>>> Thanks again for your help, >> >>>> John >> >>>> >> >>>>> >> >>>>> Best regards, >> >>>>> >> >>>>> Marc >> >>>>> >> >>>>> >> >>>>> On Aug 12, 2014, at 3:46 PM, John Fox <[email protected]> wrote: >> >>>>> >> >>>>>> Hi Marc, >> >>>>>> >> >>>>>> Thanks for this. It does work, and I wasn't aware of it -- >> you've >> >>>>> obviously >> >>>>>> done a better job than I did of searching for a solution! >> >>>>>> >> >>>>>> Although this approach works, it has the disadvantage of >> permanently >> >>>>>> changing the help browser in R.app, beyond the current session, >> at >> >>>>> least >> >>>>>> until the change is explicitly undone. I think that I can work >> around >> >>>>> that >> >>>>>> by something like >> >>>>>> >> >>>>>> current <- system("defaults read org.R-project.R", >> intern=TRUE) >> >>>>>> >> >>>>>> to discover whether the use.external.help preference exists, and >> if >> >>>>> so, what >> >>>>>> its value is; to then set the preference to YES if it's NO or >> unset; >> >>>>> and >> >>>>>> finally to remove the preference on exit. >> >>>>>> >> >>>>>> Again, thanks -- I think that I can work with this, though it >> would >> >>>>> in my >> >>>>>> opinion be better if the help browser were settable for the >> current >> >>>>> session >> >>>>>> directly via options() in R, or if one could specify the browser >> in a >> >>>>> call >> >>>>>> to help(). >> >>>>>> >> >>>>>> Best (and thanks again), >> >>>>>> John >> >>>>>> >> >>>>>>> -----Original Message----- >> >>>>>>> From: Marc Schwartz [mailto:[email protected]] >> >>>>>>> Sent: Tuesday, August 12, 2014 4:04 PM >> >>>>>>> To: John Fox >> >>>>>>> Cc: [email protected] >> >>>>>>> Subject: Re: [R-SIG-Mac] bypassing the R.app help browser? >> >>>>>>> >> >>>>>>> On Aug 12, 2014, at 2:33 PM, John Fox <[email protected]> wrote: >> >>>>>>> >> >>>>>>>> Dear list members, >> >>>>>>>> >> >>>>>>>> Is there a way to bypass the R.app help browser, and to use >> instead >> >>>>>>> an alternative browser, such as the one pointed to by >> >>>>>>> getOption("browser")? >> >>>>>>>> >> >>>>>>>> I've tried a number of strategies, including setting >> .Platform$GUI >> >>>>> <- >> >>>>>>> "unknown". The only approach I tried that works is to mask the >> >>>>> help() >> >>>>>>> function with a modified version, but this produces other >> problems, >> >>>>>>> such as referencing unexported objects from utils and tools. >> >>>>>>>> >> >>>>>>>> It would be nice if the help() function had a browser >> argument, >> >>>>>>> similar to that in browseURL(), and defaulting to the current >> >>>>>>> behaviour. >> >>>>>>>> >> >>>>>>>> Any suggestions would be appreciated. >> >>>>>>>> >> >>>>>>>> John >> >>>>>>> >> >>>>>>> >> >>>>>>> John, >> >>>>>>> >> >>>>>>> I found this post from Simon that seems to work: >> >>>>>>> >> >>>>>>> https://stat.ethz.ch/pipermail/r-sig-mac/2009- >> December/006908.html >> >>>>>>> >> >>>>>>> I tried it on my Mac in the latest version of R.app, which I >> >>>>> normally >> >>>>>>> do not use and the help system does now popup a browser. >> >>>>>>> >> >>>>>>> >> >>>>>>> Regards, >> >>>>>>> >> >>>>>>> Marc Schwartz >> >>>>>> >> >>>> >> >>>> _______________________________________________ >> >>>> R-SIG-Mac mailing list >> >>>> [email protected] >> >>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac >> >>>> >> >>> >> >> >> >> _______________________________________________ >> >> R-SIG-Mac mailing list >> >> [email protected] >> >> https://stat.ethz.ch/mailman/listinfo/r-sig-mac >> > >> >> >> -- >> Brian D. Ripley, [email protected] >> Emeritus Professor of Applied Statistics, University of Oxford >> 1 South Parks Road, Oxford OX1 3TG, UK > > _______________________________________________ > R-SIG-Mac mailing list > [email protected] > https://stat.ethz.ch/mailman/listinfo/r-sig-mac _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
