[R-SIG-Mac] bypassing the R.app help browser?
Richard M. Heiberger
rmh at temple.edu
Thu Aug 14 03:11:34 CEST 2014
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
>>
More information about the R-SIG-Mac
mailing list