[R-SIG-Mac] bypassing the R.app help browser?

John Fox jfox at mcmaster.ca
Thu Aug 14 14:26:12 CEST 2014 

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/

More information about the R-SIG-Mac mailing list