Disclaimer: To Simon and Stefano, this does not constitute a bug
report---I know you guys are busy and have enough on your plate w.r.t.
R (and doing a great job), let alone your Real Jobs. Its more thinking
out loud in the (apparently) rapidly growing community of OS X R
users---it seems like there have been more messages on this list in the
last two weeks than the last six months, which is great.
Ok, so after a very quick hack to add back and forward buttons and make
the current toolbar a real toolbar, it appears that the Help system is
generally broken.
The hack that grabs '?' and 'help' is seems to be the culprit (but I
see why its there, discussed below)---? is actually both a binary and a
unary operator so calls of x?y don't get snagged and valid calls to
help() erroneously bring up the HTML help (help("foo",offline=TRUE),
for example, does not work anymore). Its fine for casual use, but it
breaks for heavy users of S4 classes (e.g., Bioconductor users).
Unfortunately, there are a couple of problems that account for the
hack's existence:
1) R internal help goes through the general pager so, under normal
circumstances, we end up with non-linkable HTML files. Its possible to
improve the current pager to support underlines and such, but it seems
a waste.
2) We can force HTML help (essentially set htmlhelp=TRUE under the Aqua
platform) and add .show_help_on_topic_as_HTML to the aqua-specific
subdirectory of package:utils to route to an internal call (say,
Re_show_help) that brings it up using WebKit (or, if web kit isn't
available routes to the user's local web browser).
Sadly, this modifies the semantics of help(htmlhelp=TRUE) under OS X,
which is sort of lame. We could have an option in a preferences panel
to allow users to route to the default (or an arbitrary) HTML viewer.
However, its my best proposal at this point (and I've already
implemented a chunk of it so I can keep going if y'all would like).
Turns out Duncan is right. We really do want ?foo to be an alias for
show(help("foo")). Especially since it would be much easier to track
the path through the help system if URLs were of the form
"help://utils/foo" or something and not "http://...."
More Things Noted:
Only two-level nesting in the Workspace Browser doesn't work:
data(iris)
nested = c()
nested$someting = iris
doesn't let you drill down into "something". I'm guessing that this
wasn't intentional as editing from the browser != nested$something =
edit(nested$something) (presumably the observation below would go
towards remedying this problem)
Things that would be Fun:
dragging an element from the workspace browser to the console would
paste it. I.e. dragging "Sepal.Length" from iris would paste
iris[["Sepal.Length"]]. Even cooler would be cross-app drag-n-drop that
pastes print(iris) when you drag iris, but thats more time consuming.
;-) I may take a shot at the former since I think it would be fairly
easy (though from a quick glance at the code, it probably requires a
weak reference back link to the parent item in the former case). (My
thought is not that it would actually be in the console work
flow---more allowing drop targets in user-supplied things. Like a
simple regression who's interface was just a plot and dragging
"Sepal.Width" to the y-axis reruns the regression with "Sepal.Width" as
the response. You get the idea.)
---
Byron Ellis (ellis@stat.harvard.edu)
"Oook" -- The Librarian
Cocoa Help System Totally Busted(tm)? And Other Random Notes (Not a Bug Report!)
4 messages · Byron Ellis, Simon Urbanek, Thomas Lumley
Byron, if you read the docs and our comments, you would know that we emphasized that the "?" hack is very temporary and the only reason it was kept in the release was that a modification of R is necessary for the clean solution and it was too late to do that for the 2.0.0 release. IMHO the way to go (and I successfully tested) is to re-define the print methods for the help objects. As of htmlhelp - htmlhelp=FALSE basically doesn't make much sense in OS X. It's ok for the console version when the existence of a html browser is not guaranteed, but it make no sense in the Cocoa GUI.
On Nov 1, 2004, at 6:19 PM, Byron Ellis wrote:
Only two-level nesting in the Workspace Browser doesn't work:
The WB is pretty much pre-alpha thing and will need major re-writing. Unfortunately that is a lot of work and other managers (with less work involved) need to be finished first. I hope that I can weed out that one this week so it'll be more viable for others to put their hands on it.
dragging an element from the workspace browser to the console would paste it.
With respect to this and the WB, you may have a look at JGR - it's got both issues solved pretty well I guess. The only reason it's not implemented in R.app is the lack of programming power :P So send us the diffs and we'll be happy to include it ;) Cheers, Simon
On Nov 1, 2004, at 5:31 PM, Simon Urbanek wrote:
Byron, if you read the docs and our comments, you would know that we emphasized that the "?" hack is very temporary and the only reason it was kept in the release was that a modification of R is necessary for the clean solution and it was too late to do that for the 2.0.0 release. IMHO the way to go (and I successfully tested) is to re-define the print methods for the help objects. As of htmlhelp - htmlhelp=FALSE basically doesn't make much sense in OS X. It's ok for the console version when the existence of a html browser is not guaranteed, but it make no sense in the Cocoa GUI.
Sure, I arrived at roughly the same conclusion (and suspected that the hack was there for a good reason---though I apparently missed it in the documentation). I'd take it one step further and suggest that the help system in general Made Sense At The Time(tm) but that we have display environments rich enough that we really want to do on-the-fly calculations for a lot of these things (e.g., to eliminate the simlinks for HTML). A lot of Rd parsing stuff has been showing up in R for the quality control stuff, there's no reason it couldn't be harnessed to parse Rd files on the fly (I know the Gnome interface could to the same thing with Gtkhtml, as could Win32, though it already has the CHM system that works pretty well)---but doing that would mean a pretty major overhaul of the help system and I'm guessing there are higher priorities. (Dear Easter Bunny, Multiple evaluators/greenthreads would be "Da Bomb" ) :-)
On Nov 1, 2004, at 6:19 PM, Byron Ellis wrote:
Only two-level nesting in the Workspace Browser doesn't work:
The WB is pretty much pre-alpha thing and will need major re-writing. Unfortunately that is a lot of work and other managers (with less work involved) need to be finished first. I hope that I can weed out that one this week so it'll be more viable for others to put their hands on it.
dragging an element from the workspace browser to the console would paste it.
With respect to this and the WB, you may have a look at JGR - it's got both issues solved pretty well I guess. The only reason it's not implemented in R.app is the lack of programming power :P So send us the diffs and we'll be happy to include it ;)
I admire the look of JGR, but haven't had much time to play with it---but I see what you mean about the browser. BTW, on a positive note, I think we just set some sort of record for "shortest time to prepare a grant" and the new Cocoa GUI had a lot to do with that---begin able to get the plot "just so" and hit Save As... was a real time saver.
Cheers, Simon
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
--- Byron Ellis (ellis@stat.harvard.edu) "Oook" -- The Librarian
1 day later
IMHO the way to go (and I successfully tested) is to re-define the print methods for the help objects.
Yes, that's basically why there are print methods. -thomas