On Oct 18, 2018, at 5:45 PM, Ben Tupper <btupper at bigelow.org> wrote:
You are correct that it only comes up in the text pager when I invoke R from the terminal (with or without --vanilla).
RStudio help works as expected in the sense that help content is rendered within the RStudio panes on the "Help" tab - just as you surmised.
Cheers (really!),
Ben
On Oct 18, 2018, at 5:32 PM, Marc Schwartz <marc_schwartz at me.com> wrote:
Hi Ben,
A question, because as I go back and re-read both this thread and the prior one you posted on this issue, I have been presuming that when you run R from the terminal, you can successfully get help to open in an external browser.
However, given my re-read and what you now post below, I am wondering if, in fact, when running R in the terminal, you simply get the help displaying in the text pager.
I don't use RStudio, so not sure if help comes up in their own internal browser, or if it comes up in an external browser. Albeit, looking at their website, it appears to be an internal browser that stays within the IDE, in contrast to R.app opening the internal browser in an external window.
Can you confirm that when you run R from the terminal, does help appear within the terminal window in the pager, or does it come up in whatever external browser you are using, which I am guessing is Firefox based upon the output below.
Thanks,
Marc
On Oct 18, 2018, at 5:09 PM, Ben Tupper <btupper at bigelow.org> wrote:
Hi,
In a fresh R.app session
debug(get("aqua.browser", envir = as.environment("tools:RGUI")))
help('help')
starting httpd help server ... done
debugging in: browser(if (encodeIfNeeded) URLencode(url) else url)
debug: {
x <- gsub("http://127.0.0.1", "http://localhost", x, fixed = TRUE)
.Call("aqua.custom.print", "help-files", x)
invisible(x)
}
Browse[2]> n
debug: x <- gsub("http://127.0.0.1", "http://localhost", x, fixed = TRUE)
Browse[2]> n
debug: .Call("aqua.custom.print", "help-files", x)
Browse[2]> browseURL(x)
opens the external browser http://localhost:28450/library/utils/html/help.html<http://localhost:28450/library/utils/html/help.html>
but the browser says...
"Hmm. We?re having trouble finding that site.
We can?t connect to the server at localhost.
If that address is correct, here are three other things you can try:
Try again later.
Check your network connection.
If you are connected but behind a firewall, check that Firefox has permission to access the Web."
And...
Browse[2]> c
exiting from: browser(if (encodeIfNeeded) URLencode(url) else url)
... opens the blank help window.
Finally, following up on Marc's suggestion that I invoke R without --vanilla...
ben at gale ~ $ diff R-app-options R-options
81c81
< <bytecode: 0x7fd0b1fcbbc0>
---
<bytecode: 0x7fb46a177890>
On Oct 18, 2018, at 4:49 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
On 18/10/2018 8:50 AM, Ben Tupper wrote:
I also have no firewall running on the platform. I do have anti-virus/malware and have turned it off. The help window still renders with a blank page and there is no text captured with a copy-paste.
I tried debug() as Duncan suggested and get the following in a fresh R.app session...
Okay, that wasn't as informative as I had hoped. Could you try the following:
debug(get("aqua.browser", envir = as.environment("tools:RGUI")))
then ask for help on something. You should stop in the debugger seeing something like
debugging in: browser(if (encodeIfNeeded) URLencode(url) else url)
debug: {
x <- gsub("http://127.0.0.1 <http://127.0.0.1/>", "http://localhost <http://localhost/>", x, fixed = TRUE)
.Call("aqua.custom.print", "help-files", x)
invisible(x)
}
At the prompt, type "n" (without the quotes, followed by return) twice, until you are at the .Call line. Then type
browseURL(x)
This should open your external browser. It will either show a blank page, or the help page: that will indicate whether the problem is in the internal browser or in the server.
Then go back to R.app, and type "c". This should open the same help page in the internal browser. It might show a blank page, or the regular help page: either one would tell us something.
Duncan Murdoch